更新cms碎片的方法及裝置的制造方法
【專利摘要】本發(fā)明實施例提供一種更新CMS碎片的方法及裝置。該方法包括：建立定時CMS碎片更新檢測任務(wù)；在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異；若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本存在差異，則下載所述第二CMS碎片到所述目標路徑下以更新所述第一CMS碎片。
【專利說明】
更新CMS碎片的方法及裝置
技術(shù)領(lǐng)域
[0001]本發(fā)明涉及網(wǎng)絡(luò)技術(shù)領(lǐng)域，尤其涉及一種更新內(nèi)容管理系統(tǒng)(ContentManagement System，CMS)碎片的方法及裝置。
【背景技術(shù)】
[0002]在高性能網(wǎng)站中，一般會采用動靜態(tài)分離部署。瀏覽器會緩存頁面，如果上次請求的靜態(tài)資源和這次有重復(fù)的，瀏覽器會直接取本地緩存中的文件，而不會從服務(wù)器上重新取，除非用戶強制刷新?，F(xiàn)在大型網(wǎng)站人員分工非常細。前端有專門的開發(fā)人員，后臺有專門的開發(fā)人員。如果服務(wù)器靜態(tài)文件有更新，一般會采用增加版本號的方式，改變原來的URL地址。但是，這個版本號的改變必須讓后臺服務(wù)知道，因為這些靜態(tài)文件都是直接在后臺頁面上引用的。而且如果靜態(tài)部分頻繁增加css，jS(CSS是美化控件的代碼(層疊樣式表)，js( javascript)是一種增強表現(xiàn)力的腳本語言)文件怎么辦呢?每次前臺開發(fā)人員來找后臺開發(fā)人員要求修改靜態(tài)文件的引用，溝通成本非常高。后來大家就研發(fā)了一種叫做CMS碎片的東西。CMS就是內(nèi)容管理系統(tǒng)。將幾個css Js打包成一個模塊，前端開發(fā)人員不需要通知后臺開發(fā)人員直接在CMS上修改即可。后臺開發(fā)人員每次自己去看自己的服務(wù)上的靜態(tài)文件和CMS相比是不是最新的。
[0003]現(xiàn)有采用的方法是單獨寫一個shell腳本(與Windows/Dos下的批處理相似，也就是用各類命令預(yù)先放入到一個文件中，方便一次性執(zhí)行的一個程序文件，主要是方便管理員進行設(shè)置或者管理用的)放到服務(wù)器上，定時去取最新的CMS碎片。但是這種采用shell腳本更新的方式，是在shell腳本中執(zhí)行http請求，將要覆蓋的文件路徑寫死在腳本里，不僅無法適用下載路徑發(fā)生改變的情況，并且沒有進行下載正確性的檢查，容易出問題。不跨平臺，只適用于Linux服務(wù)器，需要單獨部署，部署和維護困難。

【發(fā)明內(nèi)容】

[0004]本發(fā)明實施例提供一種更新內(nèi)容管理系統(tǒng)(Content Management System，CMS)碎片的方法及裝置，用來解決現(xiàn)有技術(shù)中CMS碎片更新時，不僅無法適用下載路徑發(fā)生改變的情況，并且沒有進行下載正確性的檢查，容易出問題，只適用于Linux服務(wù)器等技術(shù)問題。
[0005]本發(fā)明實施例的一個方面是提供一種更新CMS碎片的方法，包括:
[0006]建立定時CMS碎片更新檢測任務(wù)；
[0007]在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異；
[0008]若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本存在差異，則下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片。
[0009]可選的，在該方法還包括:
[0010]檢測該第二CMS碎片是否為出錯頁面文件；
[0011]若檢測到該第二CMS碎片是出錯頁面文件，則不執(zhí)行所述下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片的步驟。
[0012]可選的，所述下載所述第二CMS碎片到所述目標路徑下以更新所述第一CMS碎片，具體包括:
[0013]從所述下載路徑中下載所述第二CMS碎片，并判斷下載所述第二 CMS碎片是否成功；
[0014]若判定下載成功，則用下載后的所述第二CMS碎片覆蓋所述目標路徑下的所述第一 CMS碎片。
[0015]可選的，所述定時CMS碎片更新檢測任務(wù)通過spring MVC架構(gòu)中的任務(wù)task功能來建立。
[0016]可選的，該方法還包括:
[0017]當所述CMS碎片的下載路徑變更時，改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑。本發(fā)明實施例的另一個方面是提供一種更新CMS碎片的裝置，包括:
[0018]任務(wù)模塊，用于建立定時CMS碎片更新檢測任務(wù)；
[0019]檢測模塊，用于在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異；
[0020]更新模塊，用于若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一 CMS碎片的文本存在差異，則下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片。
[0021]可選的，所述檢測模塊，還用于檢測該第二CMS碎片是否為出錯頁面文件;所述更新模塊在檢測模塊檢測到該第二 CMS碎片是出錯頁面文件時，不執(zhí)行更新。
[0022]可選的，所述更新模塊包括:
[0023]下載單元，用于從所述下載路徑中下載所述第二CMS碎片，并判斷下載所述第二CMS碎片是否成功；
[0024]覆蓋單元，用于若所述下載單元判定下載成功，則用下載后的所述第二CMS碎片覆蓋所述目標路徑下的所述第一 CMS碎片。
[°°25] 可選的，所述任務(wù)模塊通過spring MVC架構(gòu)中的任務(wù)task功能來建立定時CMS碎片更新檢測任務(wù)。
[0026]可選的，該裝置還包括:
[0027]路徑修改模塊，用于當所述CMS碎片的下載路徑變更時，改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑。
[0028]本發(fā)明實施例提供的更新CMS碎片的方法及裝置，通過采用在下載更新CMS碎片前，對第二CMS碎片是否為更新的內(nèi)容進行檢測，在確定是有更新的情況下，再下載更新的技術(shù)手段，可以解決現(xiàn)有技術(shù)中，由于直接進行下載更新導(dǎo)致的下載錯誤的技術(shù)問題，并且由于CMS碎片的更新方式不受腳本限制，所以也可實現(xiàn)適用于Linux服務(wù)器的技術(shù)效果。
【附圖說明】
[0029]圖1為本發(fā)明實施例提供的一種更新CMS碎片的方法流程圖；
[0030]圖2為本發(fā)明實施例提供的另一種更新CMS碎片的方法流程圖；
[0031]圖3為本發(fā)明實施例提供的一種更新CMS碎片的裝置的結(jié)構(gòu)示意圖。
[0032]圖4為本發(fā)明實施例提供的另一種更新CMS碎片的方法執(zhí)行后的CMS碎片更新示意圖。
【具體實施方式】
[0033]本發(fā)明實施例提供一種更新CMS碎片的方法如圖1所示，該方法適合部署在服務(wù)器上，該服務(wù)器不限于Linux服務(wù)器。該方法包括:
[0034]101，建立定時CMS碎片更新檢測任務(wù)；
[0035]該定時CMS碎片更新檢測任務(wù)可以通過spring MVC架構(gòu)中的任務(wù)task功能來建立;也可以通過做一個后臺界面，該界面上有定時更新CMS碎片的設(shè)定等方式實現(xiàn)。
[0036]102，在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測該下載路徑下存儲的第二 CMS碎片的文本與目標路徑下存儲的第一 CMS碎片的文本是否有差異;若下載路徑下存儲的第二 CMS碎片的文本與目標路徑下存儲的第一 CMS碎片的文本存在差異，則執(zhí)行103;若不存在差異，則執(zhí)行104。
[0037]可以在建立上述任務(wù)時，將系統(tǒng)中用于下載CMS碎片路徑的下載路徑設(shè)置到任務(wù)中，由于在TASK中，該寫入下載路徑的過程是可以改變的，因此，當所述CMS碎片的下載路徑變更時，可以改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑，從而避免現(xiàn)有技術(shù)中shell腳本下載路徑寫死在里面，無法更改的技術(shù)問題。
[0038]目標路徑即是下載下來的CMS碎片需要存儲路徑。
[0039]通過將第二CMS碎片的文本和第一 CMS碎片的文本進行比較，查看是否是否有差異的方式，來確定下載路徑上的第二CMS碎片是否是更新過的。若存在差異，則執(zhí)行103;若不存在差異，則執(zhí)行104.
[0040]103，下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片。
[0041 ] 104，說明是未更新的CMS碎片，則無需下載，等待下一定時檢測。
[0042]此時，可等待下次檢測周期到達時，再次按照102-104的步驟循環(huán)執(zhí)行。
[0043]本實施例提供的方法，通過采用在下載更新CMS碎片前，對第二CMS碎片是否為更新的內(nèi)容進行檢測，在確定是有更新的情況下，再下載更新的技術(shù)手段，可以解決現(xiàn)有技術(shù)中，由于直接進行下載更新導(dǎo)致的下載錯誤的技術(shù)問題，并且由于CMS碎片的更新方式不受腳步限制，所以也可實現(xiàn)適用于Linux服務(wù)器的技術(shù)效果。
[0044]本實施例以通過spring MVC架構(gòu)中的task功能來建立定時CMS碎片更新檢測任務(wù)為例，繼續(xù)提供一種更新CMS碎片的方法，如圖2所示，該方法包括:
[0045]201，在spring mvc的架構(gòu)中，可以使用spring的Task來建立定時CMS碎片更新檢測任務(wù)，定時更新CMS碎片。
[0046]例如:在spring的配置文件里，配置task的數(shù)據(jù)庫對象集合schema(下載路徑，目標路徑等)，執(zhí)行者的線程池大小設(shè)為5，調(diào)度程序的線程池大小設(shè)為10。設(shè)定更新程序間隔I小時更新一次。
[0047]202，在每次定時更新檢測任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測該下載路徑下存儲的第二 CMS碎片是否為出錯頁面文件;若是，則執(zhí)行200;否則執(zhí)行203。
[0048]出錯頁面是指502，503，504等等的出錯頁面。因為下載路徑中有可能因為部分網(wǎng)關(guān)或服務(wù)器等出現(xiàn)問題，使原本保存的CMS碎片文件變成了出錯頁面的文件，此時，若單純通過差異性檢測也可能得出錯誤的結(jié)論，即將出錯頁面文件作為CMS碎片下載下來。因此在下載前，還需確定該CMS碎片文件是否為出錯頁面文件等，以便保證更新的正確性。
[0049]該203可以在203前執(zhí)行，也可以在203執(zhí)行。
[0050]203，檢測該下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片(即當前正在使用的CMS碎片)的文本是否有差異;若下載路徑下存儲的第二 CMS碎片的文本與目標路徑下存儲的第一 CMS碎片的文本存在差異，則執(zhí)行204，否則執(zhí)行200。
[0051]204，從所述下載路徑中下載所述第二CMS碎片，并判斷下載第二CMS碎片是否成功;若判定下載成功，則執(zhí)行205，否則執(zhí)行200。
[0052]205，用下載后的所述第二 CMS碎片覆蓋所述目標路徑下的所述第一 CMS碎片。
[0053]200，等待下次定時CMS碎片檢測任務(wù)到來。
[0054]本發(fā)明實施例提供的更新CMS碎片的方法及裝置，通過采用在下載更新CMS碎片前，對第二CMS碎片是否為更新的內(nèi)容進行檢測，在確定是有更新的情況下，再下載更新的技術(shù)手段，可以解決現(xiàn)有技術(shù)中，由于直接進行下載更新導(dǎo)致的下載錯誤的技術(shù)問題，并且由于CMS碎片的更新方式不受腳步限制，所以也可實現(xiàn)適用于Linux服務(wù)器的技術(shù)效果;進一步地，由于使用spring MVC(是一種基于Java的實現(xiàn)了Web MVC設(shè)計模式的請求驅(qū)動類型的輕量級Web框架)架構(gòu)下的task將后臺定時服務(wù)嵌入到Web工程中，將腳本和web工程合二為一，所以還可解決跨平臺問題，并從細節(jié)上做優(yōu)化，極大地方便了運維和開發(fā)人員，真正有更新時覆蓋，降低程序風(fēng)險。
[0055]如圖4所示的按照本方法執(zhí)行過的CMS碎片更新后附圖。3月8日晚上前端更新過CMS碎片，但不是所有的文件都更新。
[0056]本實施例提供的方法中，由于Task里面內(nèi)置了功能強大的表達式，可靈活的配置更新時間，并且在共通方法內(nèi)做排除出錯處理。如果下載內(nèi)容有誤，就不更新碎片，繼續(xù)使用舊碎片。對碎片路徑可以放入pom文件統(tǒng)一配置，增加其可維護性。
[0057]為了便于上述方法的實現(xiàn)，本實施例繼續(xù)提供一種更新CMS碎片的裝置，如圖3所示，包括:
[0058]任務(wù)模塊31，用于建立定時CMS碎片更新檢測任務(wù)；
[0059]檢測模塊32，用于在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異；
[0060]更新模塊33，用于若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一 CMS碎片的文本存在差異，則下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片。
[0061]可選的，所述檢測模塊32，還用于檢測該第二CMS碎片是否為出錯頁面文件;相應(yīng)地，更新模塊33在檢測模塊檢測到該第二 CMS碎片是出錯頁面文件時，不執(zhí)行更新。
[0062]其中，所述更新模塊33包括:
[0063]下載單元，用于從所述下載路徑中下載所述第二CMS碎片，并判斷下載所述第二CMS碎片是否成功；
[0064]覆蓋單元，用于若所述下載單元判定下載成功，則用下載后的所述第二CMS碎片覆蓋所述目標路徑下的所述第一 CMS碎片。
[0065]可選的，所述任務(wù)模塊通過spring MVC架構(gòu)中的任務(wù)task功能來建立定時CMS碎片更新檢測任務(wù)。
[0066]可選的，還可包括:路徑修改模塊，用于當所述CMS碎片的下載路徑變更時，改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑。
[0067]本發(fā)明實施例提供的更新CMS碎片的裝置，采用在下載更新CMS碎片前，對第二CMS碎片是否為更新的內(nèi)容進行檢測，在確定是有更新的情況下，再下載更新的功能，可以解決現(xiàn)有技術(shù)中，由于直接進行下載更新導(dǎo)致的下載錯誤的技術(shù)問題，并且由于CMS碎片的更新方式不受腳步限制，所以也可實現(xiàn)適用于Linux服務(wù)器的技術(shù)效果。
[0068]在本發(fā)明所提供的幾個實施例中，應(yīng)該理解到，所揭露的裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結(jié)合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性，機械或其它的形式。
[0069]所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。
[0070]另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用硬件加軟件功能單元的形式實現(xiàn)。
[0071]上述以軟件功能單元的形式實現(xiàn)的集成的單元，可以存儲在一個計算機可讀取存儲介質(zhì)中。上述軟件功能單元存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設(shè)備(可以是個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)或處理器(processor)執(zhí)行本發(fā)明各個實施例所述方法的部分步驟。而前述的存儲介質(zhì)包括:U盤、移動硬盤、只讀存儲器(Read-Only Memory，R0M)、隨機存取存儲器(Random Access Memory，RAM)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。
[0072]本領(lǐng)域技術(shù)人員可以清楚地了解到，為描述的方便和簡潔，僅以上述各功能模塊的劃分進行舉例說明，實際應(yīng)用中，可以根據(jù)需要而將上述功能分配由不同的功能模塊完成，即將裝置的內(nèi)部結(jié)構(gòu)劃分成不同的功能模塊，以完成以上描述的全部或者部分功能。上述描述的裝置的具體工作過程，可以參考前述方法實施例中的對應(yīng)過程，在此不再贅述。
[0073]最后應(yīng)說明的是:以上各實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制;盡管參照前述各實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當理解:其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分或者全部技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的范圍。
【主權(quán)項】
1.一種更新內(nèi)容管理系統(tǒng)CMS碎片的方法，其特征在于，包括: 建立定時CMS碎片更新檢測任務(wù)； 在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異； 若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本存在差異，則下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片。2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在該方法還包括: 檢測該第二 CMS碎片是否為出錯頁面文件； 若檢測到該第二 CMS碎片是出錯頁面文件，則不執(zhí)行所述下載所述第二 CMS碎片到所述目標路徑下以更新所述第一 CMS碎片的步驟。3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述下載所述第二CMS碎片到所述目標路徑下以更新所述第一 CMS碎片，具體包括: 從所述下載路徑中下載所述第二 CMS碎片，并判斷下載所述第二 CMS碎片是否成功； 若判定下載成功，則用下載后的所述第二CMS碎片覆蓋所述目標路徑下的所述第一CMS碎片。4.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述定時CMS碎片更新檢測任務(wù)通過spring MVC架構(gòu)中的任務(wù)task功能來建立。5.根據(jù)權(quán)利要求4所述的方法，其特征在于，該方法還包括: 當所述CMS碎片的下載路徑變更時，改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑。6.一種更新內(nèi)容管理系統(tǒng)CMS碎片的裝置，其特征在于，包括: 任務(wù)模塊，用于建立定時CMS碎片更新檢測任務(wù)； 檢測模塊，用于在每次定時執(zhí)行所述任務(wù)執(zhí)行的過程中，到CMS碎片的下載路徑檢測所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本是否有差異; 更新模塊，用于若所述下載路徑下存儲的第二CMS碎片的文本與目標路徑下存儲的第一CMS碎片的文本存在差異，則下載所述第二CMS碎片到所述目標路徑下以更新所述第一CMS碎片。7.根據(jù)權(quán)利要求6所述的裝置，其特征在于， 所述檢測模塊，還用于檢測該第二 CMS碎片是否為出錯頁面文件； 所述更新模塊在檢測模塊檢測到該第二 CMS碎片是出錯頁面文件時，不執(zhí)行更新。8.根據(jù)權(quán)利要求6或7所述的裝置，其特征在于，所述更新模塊包括: 下載單元，用于從所述下載路徑中下載所述第二 CMS碎片，并判斷下載所述第二 CMS碎片是否成功； 覆蓋單元，用于若所述下載單元判定下載成功，則用下載后的所述第二 CMS碎片覆蓋所述目標路徑下的所述第一 CMS碎片。9.根據(jù)權(quán)利要求6或7所述的裝置，其特征在于，所述任務(wù)模塊通過springMVC架構(gòu)中的任務(wù)task功能來建立定時CMS碎片更新檢測任務(wù)。10.根據(jù)權(quán)利要求9所述的裝置，其特征在于，該裝置還包括: 路徑修改模塊，用于當所述CMS碎片的下載路徑變更時，改寫所述task功能建立的定時CMS碎片更新檢測任務(wù)中的所述CMS碎片的下載路徑。
【文檔編號】G06F9/445GK105893054SQ201610256888
【公開日】2016年8月24日
【申請日】2016年4月22日
【發(fā)明人】謝曉靜
【申請人】樂視控股（北京）有限公司, 樂視網(wǎng)信息技術(shù)（北京）股份有限公司