面試官:為什么在系統(tǒng)中不推薦雙寫?
引言
某日,阿雄跑去面試!于是有如下情形
面試官:"阿雄是吧,做做自我介紹!"
阿 雄:"我叫阿雄,來(lái)自某a國(guó)際電商公司!"
面試官:"我看你項(xiàng)目里用了elasticsearch,你是怎么同步數(shù)據(jù)的呢?"
阿 雄:"在代碼里寫入數(shù)據(jù)庫(kù)的時(shí)候,同時(shí)再寫入elasticsearch!"
面試官:"那你如何保證寫入數(shù)據(jù)庫(kù),和寫入elasticsearch原子性問(wèn)題呢?萬(wàn)一寫入數(shù)據(jù)庫(kù)成功了,寫入elasticsearch失敗了怎么處理?"
阿 雄:"我還是回去等通知吧!"
OK,以上情形純屬虛構(gòu),如有雷同,絕對(duì)巧合!
其實(shí)這篇文章所探討的數(shù)據(jù)同步策略并不限于某兩種固定的存儲(chǔ)系統(tǒng)之間,而想去探討一種通用的數(shù)據(jù)同步策略。主要分為以下三個(gè)部分
- (1)背景介紹
- (2)雙寫缺點(diǎn)
- (3)改良方案
正文
背景介紹
話說(shuō)阿雄在加入某a國(guó)際電商公司的時(shí)候,業(yè)務(wù)系統(tǒng)十分簡(jiǎn)單,一個(gè)database就能搞定一切!
可是某a國(guó)際電商公司在產(chǎn)品韓的領(lǐng)導(dǎo)下,業(yè)務(wù)增長(zhǎng)迅速,阿雄發(fā)現(xiàn)了數(shù)據(jù)庫(kù)越來(lái)越慢,于是乎阿雄加入了一些緩存,如redis來(lái)緩存一些數(shù)據(jù),提高系統(tǒng)的響應(yīng)能力。
又過(guò)了一段時(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)了,對(duì)數(shù)據(jù)庫(kù)做一些數(shù)據(jù)分析操作,性能明顯的跟不上了。于是乎阿雄將數(shù)據(jù)庫(kù)里的數(shù)據(jù),導(dǎo)入hadoop,然后進(jìn)行數(shù)據(jù)分析。
(省略一萬(wàn)字….)
最后,阿雄和產(chǎn)品韓幸福的在一起了。
OK,好,現(xiàn)在分析上面的場(chǎng)景!思考第一個(gè)問(wèn)題
1、在database,redis,elasticsearch,hadoop中的數(shù)據(jù)是有關(guān)系的,還是彼此獨(dú)立的?
顯然是有關(guān)系的,在這幾個(gè)數(shù)據(jù)源中的數(shù)據(jù)都是相關(guān)的。只是格式不一樣而已!例如,對(duì)于一條Product數(shù)據(jù),在數(shù)據(jù)庫(kù)里是
在redis里就是key為 product:pId:1,value是
- {
- "pId": "1",
- "productName": "macbook"
- }
如上所示,只是數(shù)據(jù)格式不一樣而已!
那好,現(xiàn)在思考第二個(gè)問(wèn)題
2、既然這些數(shù)據(jù)源之間數(shù)據(jù)是相關(guān)的,如何保證這幾個(gè)數(shù)據(jù)源之間數(shù)據(jù)一致性!
一種比較簡(jiǎn)單且容易想到的方案是,hardcode在程序中
例如現(xiàn)在有兩個(gè)數(shù)據(jù)源DataSouce1和DataSource2,我們往里頭寫數(shù)據(jù),代碼如下
- ProductService{
- \\省略
- public void syncData(){
- x1. writeDataSource1();
- x2. writeDataSource2();
- }
- }
這就是我們標(biāo)題中所提到的雙寫!那么,雙寫會(huì)帶來(lái)什么壞處呢?OK,繼續(xù)往下看!
雙寫缺點(diǎn)
一致性問(wèn)題
打個(gè)比方我們現(xiàn)在有兩個(gè)client,同時(shí)往兩個(gè)DataSouce寫數(shù)據(jù)。
- 一個(gè)client往里頭入X為1
- 一個(gè)client往里頭入X為5
那么會(huì)有如下情形出現(xiàn)
如圖所示,兩個(gè)DataSouce的數(shù)據(jù)就不一致了,一個(gè)為1,一個(gè)為5。除非接下來(lái)有一個(gè)新的請(qǐng)求,對(duì)x數(shù)據(jù)發(fā)生了變更,才能修正這種現(xiàn)象!否則,你可能永遠(yuǎn)都發(fā)現(xiàn)不了。
原子性問(wèn)題
因?yàn)槲覀冃枰瑫r(shí)往DataSource1和DataSource2一起寫數(shù)據(jù),你需要保證
- x1. writeDataSource1();
- x2. writeDataSource2();
這兩個(gè)操作一起成功,或者一起失?。∪绻捎秒p寫的方法,是避不開(kāi)這個(gè)問(wèn)題的!
那么有沒(méi)有通用的辦法來(lái)解決這些問(wèn)題呢?
有的,只要能按順序記錄數(shù)據(jù)的變更即可!那具體怎么做呢,我們繼續(xù)往下看!
改良方案
假設(shè),如果我們能將數(shù)據(jù)按順序記錄,寫入某個(gè)消息隊(duì)列,然后其他系統(tǒng)按消息順序恢復(fù)數(shù)據(jù),看看what happen?
此時(shí)架構(gòu)圖如下
在該架構(gòu)下,所有的數(shù)據(jù)變更寫入一個(gè)消息隊(duì)列里去。其他各數(shù)據(jù)源從消息隊(duì)列里恢復(fù)數(shù)據(jù)即可!
那么,此時(shí)還有一致性問(wèn)題,和原子性問(wèn)題么?
一致性問(wèn)題
OK,這種情況下,各個(gè)數(shù)據(jù)源之間數(shù)據(jù)肯定是一致的。因?yàn)閷懭腠樞蛞呀?jīng)在消息隊(duì)列中定義好,各數(shù)據(jù)源按照消息隊(duì)列中的消息順序,恢復(fù)數(shù)據(jù)即可,并不存在競(jìng)爭(zhēng)現(xiàn)象。因此,不會(huì)出現(xiàn)不一致的問(wèn)題!
原子性問(wèn)題
OK,這種情況下,如果寫入DataSource失敗會(huì)怎么樣?例如出現(xiàn)了網(wǎng)絡(luò)問(wèn)題,這條消息恢復(fù)失敗了。這個(gè)問(wèn)題其實(shí)好解決,一般我們?cè)陧樞蚋鶕?jù)消息恢復(fù)數(shù)據(jù)的時(shí)候,會(huì)記錄下坐標(biāo)。如果寫入失敗,停止恢復(fù)數(shù)據(jù)。下次從該坐標(biāo)處恢復(fù)數(shù)據(jù)即可。
但是在上面那張圖中,寫入DataBase是異步寫入的。這樣就不符合很多業(yè)務(wù)場(chǎng)景的"寫后即讀"的要求,因此,在實(shí)際落地中,做了一些變更!通用做法是去提取數(shù)據(jù)庫(kù)的變化!
如下圖所示
在該圖中的中間件,例如oracle中的oracle golden gate可以提取數(shù)據(jù)變化。mysql中的canal能提取數(shù)據(jù)的變化。至于消息隊(duì)列,可以選用kafka。直接提取數(shù)據(jù)變化到kafka中,其他數(shù)據(jù)源從kafka中獲取數(shù)據(jù),避免了直接雙寫從而導(dǎo)致一致性和原子性問(wèn)題。
總結(jié)
本問(wèn)討論了在項(xiàng)目中常見(jiàn)的數(shù)據(jù)同步問(wèn)題,希望大家有所收獲。