引言

某日，阿雄跑去面試！于是有如下情形

面試官:"阿雄是吧，做做自我介紹!"

阿  雄:"我叫阿雄，來自某a國際電商公司！"

面試官:"我看你項(xiàng)目里用了elasticsearch，你是怎么同步數(shù)據(jù)的呢?"

阿  雄:"在代碼里寫入數(shù)據(jù)庫的時(shí)候，同時(shí)再寫入elasticsearch！"

面試官:"那你如何保證寫入數(shù)據(jù)庫，和寫入elasticsearch原子性問題呢？萬一寫入數(shù)據(jù)庫成功了，寫入elasticsearch失敗了怎么處理？"

阿  雄:"我還是回去等通知吧！"

OK，以上情形純屬虛構(gòu)，如有雷同，絕對巧合！

其實(shí)這篇文章所探討的數(shù)據(jù)同步策略并不限于某兩種固定的存儲系統(tǒng)之間，而想去探討一種通用的數(shù)據(jù)同步策略。主要分為以下三個部分

•  (1)背景介紹
•  (2)雙寫缺點(diǎn)
•  (3)改良方案

正文

背景介紹

話說阿雄在加入某a國際電商公司的時(shí)候，業(yè)務(wù)系統(tǒng)十分簡單，一個database就能搞定一切！

可是某a國際電商公司在產(chǎn)品韓的領(lǐng)導(dǎo)下，業(yè)務(wù)增長迅速，阿雄發(fā)現(xiàn)了數(shù)據(jù)庫越來越慢，于是乎阿雄加入了一些緩存，如redis來緩存一些數(shù)據(jù)，提高系統(tǒng)的響應(yīng)能力。

又過了一段時(shí)間，產(chǎn)品韓發(fā)現(xiàn)搜索的速度灰常慢，讓阿雄去改。阿雄在網(wǎng)上發(fā)現(xiàn)，現(xiàn)在業(yè)內(nèi)都用一些elasticsearch做一些全文檢索的操作，于是乎阿雄將一些需要全文檢索的數(shù)據(jù)放入elasticsearch,提高了系統(tǒng)的搜索能力！

隨著數(shù)據(jù)的膨脹，阿雄慢慢的發(fā)現(xiàn)了，對數(shù)據(jù)庫做一些數(shù)據(jù)分析操作，性能明顯的跟不上了。于是乎阿雄將數(shù)據(jù)庫里的數(shù)據(jù)，導(dǎo)入hadoop，然后進(jìn)行數(shù)據(jù)分析。

(省略一萬字….)

最后，阿雄和產(chǎn)品韓幸福的在一起了。

OK，好，現(xiàn)在分析上面的場景！思考第一個問題

1、在database，redis,elasticsearch，hadoop中的數(shù)據(jù)是有關(guān)系的，還是彼此獨(dú)立的?

顯然是有關(guān)系的，在這幾個數(shù)據(jù)源中的數(shù)據(jù)都是相關(guān)的。只是格式不一樣而已！例如，對于一條Product數(shù)據(jù)，在數(shù)據(jù)庫里是

在redis里就是key為 product:pId:1，value是 

{     
    "pId": "1",  
    "productName": "macbook"  
} 

如上所示，只是數(shù)據(jù)格式不一樣而已！

那好，現(xiàn)在思考第二個問題

2、既然這些數(shù)據(jù)源之間數(shù)據(jù)是相關(guān)的，如何保證這幾個數(shù)據(jù)源之間數(shù)據(jù)一致性！

一種比較簡單且容易想到的方案是，hardcode在程序中

例如現(xiàn)在有兩個數(shù)據(jù)源DataSouce1和DataSource2，我們往里頭寫數(shù)據(jù),代碼如下 

ProductService{  
    \\省略  
    public void syncData(){  
        x1. writeDataSource1();  
        x2. writeDataSource2();  
    }  
} 

這就是我們標(biāo)題中所提到的雙寫！那么，雙寫會帶來什么壞處呢？OK，繼續(xù)往下看！

雙寫缺點(diǎn)

一致性問題

打個比方我們現(xiàn)在有兩個client，同時(shí)往兩個DataSouce寫數(shù)據(jù)。

•  一個client往里頭入X為1
•  一個client往里頭入X為5

那么會有如下情形出現(xiàn)

如圖所示，兩個DataSouce的數(shù)據(jù)就不一致了，一個為1，一個為5。除非接下來有一個新的請求，對x數(shù)據(jù)發(fā)生了變更，才能修正這種現(xiàn)象！否則，你可能永遠(yuǎn)都發(fā)現(xiàn)不了。

原子性問題

因?yàn)槲覀冃枰瑫r(shí)往DataSource1和DataSource2一起寫數(shù)據(jù)，你需要保證 

x1. writeDataSource1();  
x2. writeDataSource2(); 

這兩個操作一起成功，或者一起失??！如果采用雙寫的方法，是避不開這個問題的！

那么有沒有通用的辦法來解決這些問題呢？

有的，只要能按順序記錄數(shù)據(jù)的變更即可！那具體怎么做呢，我們繼續(xù)往下看!

改良方案

假設(shè)，如果我們能將數(shù)據(jù)按順序記錄，寫入某個消息隊(duì)列，然后其他系統(tǒng)按消息順序恢復(fù)數(shù)據(jù)，看看what happen?

此時(shí)架構(gòu)圖如下

在該架構(gòu)下，所有的數(shù)據(jù)變更寫入一個消息隊(duì)列里去。其他各數(shù)據(jù)源從消息隊(duì)列里恢復(fù)數(shù)據(jù)即可！

那么，此時(shí)還有一致性問題，和原子性問題么？

一致性問題

OK，這種情況下，各個數(shù)據(jù)源之間數(shù)據(jù)肯定是一致的。因?yàn)閷懭腠樞蛞呀?jīng)在消息隊(duì)列中定義好，各數(shù)據(jù)源按照消息隊(duì)列中的消息順序，恢復(fù)數(shù)據(jù)即可，并不存在競爭現(xiàn)象。因此，不會出現(xiàn)不一致的問題！

原子性問題

OK,這種情況下，如果寫入DataSource失敗會怎么樣？例如出現(xiàn)了網(wǎng)絡(luò)問題，這條消息恢復(fù)失敗了。這個問題其實(shí)好解決，一般我們在順序根據(jù)消息恢復(fù)數(shù)據(jù)的時(shí)候，會記錄下坐標(biāo)。如果寫入失敗，停止恢復(fù)數(shù)據(jù)。下次從該坐標(biāo)處恢復(fù)數(shù)據(jù)即可。

但是在上面那張圖中，寫入DataBase是異步寫入的。這樣就不符合很多業(yè)務(wù)場景的"寫后即讀"的要求，因此，在實(shí)際落地中，做了一些變更!通用做法是去提取數(shù)據(jù)庫的變化！

如下圖所示

在該圖中的中間件，例如oracle中的oracle golden gate可以提取數(shù)據(jù)變化。mysql中的canal能提取數(shù)據(jù)的變化。至于消息隊(duì)列，可以選用kafka。直接提取數(shù)據(jù)變化到kafka中，其他數(shù)據(jù)源從kafka中獲取數(shù)據(jù)，避免了直接雙寫從而導(dǎo)致一致性和原子性問題。

總結(jié)

本問討論了在項(xiàng)目中常見的數(shù)據(jù)同步問題，希望大家有所收獲。