在業(yè)務(wù)中，我們通常需要把數(shù)據(jù)庫中的數(shù)據(jù)變更同步到ES中，那么如何保證數(shù)據(jù)庫和ES的一致性呢？通常有以下幾種做法：
雙寫
在代碼中，對數(shù)據(jù)庫和ES進(jìn)行雙寫，并且先操作本地?cái)?shù)據(jù)庫，后操作ES，而且還需要把兩個(gè)操作放到一個(gè)事務(wù)中：
?在以上邏輯中，如果寫數(shù)據(jù)庫成功，寫ES失敗，那么事務(wù)會(huì)回滾。
如果寫數(shù)據(jù)庫成功，寫ES超時(shí)，實(shí)際上ES操作成功，這時(shí)候數(shù)據(jù)庫會(huì)回滾，導(dǎo)致數(shù)據(jù)不一致。這時(shí)候需要重試保證最終一致性。
這個(gè)方案的好處就是簡單，容易實(shí)現(xiàn)。并且實(shí)時(shí)性比較高。
缺點(diǎn)首先是需要改代碼，有入侵性，還有就是存在不一致的情況。并且在本地事務(wù)中發(fā)生了外調(diào)ES，大大拖長了事務(wù)，白白占用數(shù)據(jù)庫連接，影響整體的吞吐量。
MQ異步消費(fèi)
在應(yīng)用中，如果我要更新數(shù)據(jù)庫了，那么久拋出一個(gè)消息出去，然后數(shù)據(jù)庫和ES各自有一個(gè)監(jiān)聽者，監(jiān)聽消息之后自去做數(shù)據(jù)變更，如果失敗了就基于消息的重試在重新執(zhí)行。
或者像之前那個(gè)方案一樣，先操作數(shù)據(jù)庫，然后異步通知ES去更新，這時(shí)候就可以借助本地消息表的方式來保證最終一致性了。
這個(gè)方案的好處是用了MQ，起到了解耦的的作用，而且還做到了異步，提升了整體性能。
缺點(diǎn)就是MQ可能存在延遲，并且需要引入新的中間件，復(fù)雜度有所提升。
掃表定時(shí)同步
如果是ES中的數(shù)據(jù)變更的實(shí)時(shí)性要求不高，可以考慮定時(shí)任務(wù)掃表，然后批量更新ES
這個(gè)方案優(yōu)點(diǎn)沒有侵入性，數(shù)據(jù)庫的寫操作處不需要改代碼。
缺點(diǎn)是實(shí)時(shí)性很差，并且輪詢可能存在性能問題，效率問題以及給數(shù)據(jù)庫帶來壓力。
監(jiān)聽binlog同步
還有一種方案，就是可以利用數(shù)據(jù)庫變更時(shí)產(chǎn)生的binlog來更新ES。通過監(jiān)聽binlog來更新ES中的數(shù)據(jù)，也有成熟的框架可以做這樣的事情。
好處就是對業(yè)務(wù)代碼完全沒有侵入性，業(yè)務(wù)也非常解耦，不需要關(guān)系這個(gè)ES的更新操作。
缺點(diǎn)就是需要基于binlog監(jiān)聽，需要引入第三方框架。存在一定的延遲。文章來源：http://www.zghlxwxcb.cn/news/detail-861244.html
總結(jié)一下，目前業(yè)內(nèi)比較流行的方案是基于binlog監(jiān)聽的這種，首先一般業(yè)務(wù)量小的業(yè)務(wù)也不太需要用ES，所以用了ES的團(tuán)隊(duì)，一般并不太會(huì)關(guān)系引入新框架的復(fù)雜度問題，而且ES這種搜索，一般來說，毫秒級的延遲都可以接受的，所以，綜合來講，基于canal做數(shù)據(jù)同步的方案，比較合適的文章來源地址http://www.zghlxwxcb.cn/news/detail-861244.html
到了這里，關(guān)于如何保證ES和數(shù)據(jù)庫的數(shù)據(jù)一致性？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
