引言

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

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

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

面試官:"我看你項目裏用了elasticsearch，你是怎麼同步數據的呢?"

阿  雄:"在代碼裏寫入數據庫的時候，同時再寫入elasticsearch！"

面試官:"那你如何保證寫入數據庫，和寫入elasticsearch原子性問題呢？

 萬一寫入數據庫成功了，寫入elasticsearch失敗了怎麼處理？"

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

OK，以上情形純屬虛構，如有雷同，絕對巧合！

其實這篇文章所探討的數據同步策略並不限於某兩種固定的存儲系統之間，而想去探討一種通用的數據同步策略。主要分爲以下三個部分

  • (1)背景介紹

  • (2)雙寫缺點

  • (3)改良方案

正文

背景介紹

話說阿雄在加入某a國際電商公司的時候，業務系統十分簡單，一個database就能搞定一切！

可是某a國際電商公司在產品韓的領導下，業務增長迅速，阿雄發現了數據庫越來越慢，於是乎阿雄加入了一些緩存，如redis來緩存一些數據，提高系統的響應能力。

又過了一段時間，產品韓發現搜索的速度灰常慢，讓阿雄去改。阿雄在網上發現，現在業內都用一些elasticsearch做一些全文檢索的操作，於是乎阿雄將一些需要全文檢索的數據放入elasticsearch,提高了系統的搜索能力！

隨着數據的膨脹，阿雄慢慢的發現了，對數據庫做一些數據分析操作，性能明顯的跟不上了。於是乎阿雄將數據庫裏的數據，導入hadoop，然後進行數據分析。

(省略一萬字….)

最後， 阿雄和產品韓幸福的在一起了 。

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

1、在database，redis,elasticsearch，hadoop中的數據是有關係的，還是彼此獨立的?

顯然是有關係的，在這幾個數據源中的數據都是相關的。只是格式不一樣而已！例如，對於一條Product數據，在數據庫裏是

在redis裏就是key爲 product:pId:1 ，value是 

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

如上所示，只是數據格式不一樣而已！

那好，現在思考第二個問題

2、既然這些數據源之間數據是相關的，如何保證這幾個數據源之間數據一致性！

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

例如現在有兩個數據源DataSouce1和DataSource2，我們往裏頭寫數據,代碼如下

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

這就是我們標題中所提到的雙寫！那麼，雙寫會帶來什麼壞處呢？OK，繼續往下看！

雙寫缺點

一致性問題

打個比方我們現在有兩個client，同時往兩個DataSouce寫數據。

  • 一個client往裏頭入X爲1

  • 一個client往裏頭入X爲5

那麼會有如下情形出現

如圖所示，兩個DataSouce的數據就不一致了，一個爲1，一個爲5。除非接下來有一個新的請求，對x數據發生了變更，才能修正這種現象！否則，你可能永遠都發現不了。

原子性問題

因爲我們需要同時往DataSource1和DataSource2一起寫數據，你需要保證

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

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

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

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

改良方案

假設，如果我們能將數據按順序記錄，寫入某個消息隊列，然後其他系統按消息順序恢復數據，看看what happen?

此時架構圖如下

在該架構下，所有的數據變更寫入一個消息隊列裏去。其他各數據源從消息隊列裏恢復數據即可！

那麼，此時還有一致性問題，和原子性問題麼？

一致性問題

OK，這種情況下，各個數據源之間數據肯定是一致的。因爲寫入順序已經在消息隊列中定義好，各數據源按照消息隊列中的消息順序，恢復數據即可，並不存在競爭現象。因此，不會出現不一致的問題！

原子性問題

OK,這種情況下，如果寫入DataSource失敗會怎麼樣？例如出現了網絡問題，這條消息恢復失敗了。這個問題其實好解決，一般我們在順序根據消息恢復數據的時候，會記錄下座標。如果寫入失敗，停止恢復數據。下次從該座標處恢復數據即可。

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

如下圖所示

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

總結

本問討論了在項目中常見的數據同步問題，希望大家有所收穫。

相關文章