CDCR的主要組成部分

CDCR的主要組成部分

CDCR架構(gòu)中有許多關(guān)鍵特性和組件：

CDCR配置

為了配置CDCR，源數(shù)據(jù)中心需要與目標(biāo)數(shù)據(jù)中心關(guān)聯(lián)的ZooKeeper集群的主機(jī)地址。ZooKeeper主機(jī)地址是CDCR實(shí)例化與Target Solr集群通信所需的唯一信息。因此，源群集上solrconfig.xml文件的CDCR配置部分將包含一個(gè)ZooKeeper主機(jī)列表。solrconfig.xml的CDCR的配置部分還可能包含輔助/可選配置，例如CDC Replicator線程的數(shù)量，批量更新相關(guān)設(shè)置等。

CDCR初始化

CDCR支持對(duì)新的或現(xiàn)有的集合進(jìn)行增量更新。CDCR可能無法跟上極高的volume更新，特別是在數(shù)據(jù)中心之間由于“pipe”緩慢而導(dǎo)致通信延遲嚴(yán)重的情況下。某些情況下：

• 有一個(gè)語料庫的初始批量加載，然后是較低的volume增量更新。在這種情況下，可以執(zhí)行初始批量加載，然后啟用CDCR。有關(guān)更多信息，請(qǐng)參閱初始啟動(dòng)部分。
• 該索引從頭開始建立，沒有明顯的初始批量負(fù)荷。CDCR可以設(shè)置在空集合上，并從頭開始保持同步。
• 索引總是被更新的數(shù)量太高，CDCR無法不上。在源數(shù)據(jù)中心和目標(biāo)數(shù)據(jù)中心之間的連接較差的情況下，這尤其有可能。這種情況不適用于目前的CDCR格式。

數(shù)據(jù)中心間通信

CDCR REST API是管理命令的最終用戶通信的主要形式。SolrJ客戶端在內(nèi)部用于CDCR操作。SolrJ客戶端從solrconfig.xml文件中獲取配置信息。CDCR的用戶不會(huì)直接與內(nèi)部的SolrJ實(shí)現(xiàn)進(jìn)行交互，只會(huì)通過REST API與CDCR進(jìn)行交互。

更新Tracking和Pushing

CDCR通過利用更新日志將數(shù)據(jù)更新從源復(fù)制到目標(biāo)數(shù)據(jù)中心。

后臺(tái)線程定期檢查更新日志中的新條目，然后將其轉(zhuǎn)發(fā)到目標(biāo)數(shù)據(jù)中心。因此，線程需要保持一個(gè)檢查點(diǎn)的形式，指向在更新日志中成功處理的最后一個(gè)更新。目標(biāo)數(shù)據(jù)中心確認(rèn)更新已成功處理后，更新日志指針將更新以反映當(dāng)前檢查點(diǎn)。

此指針必須在所有副本之間同步。在leader失敗并選出新leader的情況下，新leader將能夠通過使用該同步指針從最后更新恢復(fù)復(fù)制。下面將解釋在副本之間同步這樣一個(gè)指針的策略。

如果由于某種原因，目標(biāo)數(shù)據(jù)中心處于離線狀態(tài)或未能處理更新，則線程將定期嘗試聯(lián)系目標(biāo)數(shù)據(jù)中心，并在緩存源群集上的更新時(shí)推送更新。其中一個(gè)含義是應(yīng)該定期監(jiān)視源更新日志目錄，因?yàn)楦聦⒗^續(xù)積累，直到與目標(biāo)數(shù)據(jù)中心的連接恢復(fù)，amd才會(huì)被清除。

更新檢查點(diǎn)的同步

碎片引導(dǎo)程序和碎片副本之間更新檢查點(diǎn)的可靠同步對(duì)于避免引入源數(shù)據(jù)中心和目標(biāo)數(shù)據(jù)中心之間的不一致至關(guān)重要。另一個(gè)重要的要求是必須以最小的網(wǎng)絡(luò)流量來執(zhí)行同步，以最大限度地提高可伸縮性。

為了實(shí)現(xiàn)這一目標(biāo)，戰(zhàn)略是：

• 唯一標(biāo)識(shí)每個(gè)更新操作。這個(gè)唯一的標(biāo)識(shí)符將作為指針。
• 依賴于兩個(gè)存儲(chǔ)器：Source shard leader上的臨時(shí)存儲(chǔ)和目標(biāo)集群上的持久存儲(chǔ)。

源集群中的分片頭將負(fù)責(zé)為每個(gè)更新操作生成唯一的標(biāo)識(shí)符，并將最后一次處理的更新的標(biāo)識(shí)符的副本保留在內(nèi)存中。標(biāo)識(shí)符將作為更新請(qǐng)求的一部分發(fā)送到目標(biāo)群集。在目標(biāo)數(shù)據(jù)中心方面，分片頭將接收更新請(qǐng)求，并將其與更新日志中的唯一標(biāo)識(shí)符一起存儲(chǔ)，并將其復(fù)制到其他碎片。

SolrCloud已經(jīng)為每個(gè)更新操作提供了一個(gè)唯一的標(biāo)識(shí)符，即“版本號(hào)”。該版本號(hào)是使用基于時(shí)間的導(dǎo)入時(shí)鐘生成的，該時(shí)鐘對(duì)于每次發(fā)送的更新操作都是遞增的。這提供了更新操作的“發(fā)生之前”排序，這將在（1）源集群上的更新檢查點(diǎn)的初始化以及（2）更新日志的維護(hù)策略中利用。

目標(biāo)群集上的持久性存儲(chǔ)僅在選擇源群集上的新分片頭時(shí)使用。如果一個(gè)碎片leader在源群集上向下移動(dòng)并選出一個(gè)新的leader，新leader將聯(lián)系目標(biāo)集群來檢索最后的更新檢查點(diǎn)并實(shí)例化其短暫指針。在這樣的請(qǐng)求中，目標(biāo)集群將檢索在所有分片中收到的最新標(biāo)識(shí)符，并將其發(fā)送回源集群。為了檢索最新的標(biāo)識(shí)符，每個(gè)分片leader將在其更新日志中查找第一個(gè)條目的標(biāo)識(shí)符并將其發(fā)送回協(xié)調(diào)器。協(xié)調(diào)器將不得不選擇其中最高的。

這種策略不需要任何額外的網(wǎng)絡(luò)流量，并確保了可靠的指針同步。一致性主要通過利用SolrCloud來實(shí)現(xiàn)。SolrCloud的更新工作流確保每一個(gè)更新都被應(yīng)用到leader以及任何副本。如果leader不可用，就選一個(gè)新的leader。在leader選擇期間，將在新leader與其他副本之間執(zhí)行同步。這確保了新的leader與前l(fā)eader有一致的更新日志。擁有一致的更新日志意味著：

• 在源集群上，更新檢查點(diǎn)可以被新的leader重用。
• 在目標(biāo)群集上，更新檢查點(diǎn)將在先前和新的leader之間保持一致。這確保了由新選出的leader從目標(biāo)集群發(fā)送的更新檢查點(diǎn)的正確性。

維護(hù)更新日志

CDCR復(fù)制邏輯需要修改源數(shù)據(jù)中心上更新日志的維護(hù)邏輯。最初，“更新日志”用作固定大小的隊(duì)列，默認(rèn)限制為100個(gè)更新條目。在CDCR方案中，更新日志必須充當(dāng)可變大小的隊(duì)列，因?yàn)樗鼈冃枰櫮繕?biāo)數(shù)據(jù)中心的最后一次處理更新來跟蹤所有更新。更新日志中的條目只有在所有指針（每個(gè)目標(biāo)數(shù)據(jù)中心一個(gè)指針）位于其后面時(shí)才會(huì)被刪除。

如果與其中一個(gè)目標(biāo)數(shù)據(jù)中心的通信速度較慢，則源數(shù)據(jù)中心上的更新日志可能會(huì)增長(zhǎng)到相當(dāng)大的規(guī)模。在這種情況下，更新日志必須能夠根據(jù)其標(biāo)識(shí)符有效地找到給定的更新操作。鑒于其標(biāo)識(shí)符是一個(gè)增量編號(hào)，有可能實(shí)現(xiàn)一個(gè)有效的搜索策略。每個(gè)事務(wù)日志文件都包含第一個(gè)元素的版本號(hào)作為其文件名的一部分。這用于快速遍歷所有事務(wù)日志文件，并查找包含一個(gè)特定版本號(hào)的事務(wù)日志文件。

監(jiān)控

CDCR通過復(fù)制操作提供以下監(jiān)視功能：

• 通過源節(jié)點(diǎn)和目標(biāo)節(jié)點(diǎn)及其狀態(tài)等信息監(jiān)視傳出和傳入的復(fù)制
• 有關(guān)復(fù)制的統(tǒng)計(jì)信息，例如每秒的操作（添加/刪除）、隊(duì)列中的文檔數(shù)量等信息。

有關(guān)生命周期和統(tǒng)計(jì)數(shù)據(jù)的信息將由CDC Replicator線程以分片的形式提供。然后，CDCR API可以將這些信息匯總為一個(gè)集合級(jí)別。

CDC Replicator

CDC Replicator是一個(gè)后臺(tái)線程，負(fù)責(zé)將源數(shù)據(jù)中心的更新復(fù)制到一個(gè)或多個(gè)目標(biāo)數(shù)據(jù)中心。它負(fù)責(zé)在每個(gè)碎片基礎(chǔ)上提供監(jiān)測(cè)信息。由于集群中可能有大量集合和分片，因此我們將使用固定大小的CDC Replicator線程池，這些線程將在分片之間共享。

CDCR限制

目前的CDCR設(shè)計(jì)有一定的局限性。CDCR將會(huì)隨著時(shí)間的推移而不斷發(fā)展，這些限制中的許多將被解決。其中包括：

• 對(duì)于更新速率較高的批量負(fù)載情況，CDCR不太可能令人滿意，尤其是在源群集和目標(biāo)群集之間的帶寬受到限制的情況下。在這種情況下，應(yīng)執(zhí)行初始批量加載，同步源數(shù)據(jù)中心和目標(biāo)數(shù)據(jù)中心，并使用CDCR進(jìn)行增量更新。
• CDCR目前只是單向的；數(shù)據(jù)被從源集群推送到目標(biāo)集群。在這方面正在開展積極的工作來消除這一限制。
• CDCR 的工作原理與源和目標(biāo)集合中的碎片數(shù)量相同。兩個(gè)集合中的碎片可能有不同數(shù)量的副本。
• 目前不支持使用HDFS上的索引運(yùn)行CDCR，請(qǐng)參閱Solr CDCR over HDFS JIRA問題。
• 源和目標(biāo)群集之間的配置文件(solrconfig.xml, schema 等)不會(huì)自動(dòng)同步。這意味著當(dāng)源模式或solrconfig.xml文件發(fā)生更改時(shí)，必須手動(dòng)將這些更改復(fù)制到目標(biāo)群集。這包括通過Schema API或托管資源添加字段，以及手動(dòng)編輯這些文件。