摘要：最近在學(xué)習(xí)各大互聯(lián)網(wǎng)公司是如何處理數(shù)據(jù)一致性的。目前已知的有這么幾種數(shù)據(jù)庫(kù)做到情況下的強(qiáng)一致性淘寶淘寶頂級(jí)科學(xué)家陽(yáng)振坤微博號(hào)阿里正祥，發(fā)出一則消息。然后因?yàn)閿?shù)據(jù)庫(kù)是的，內(nèi)部把改動(dòng)到了北美，君就可以看到消息了。

最近在學(xué)習(xí)各大互聯(lián)網(wǎng)公司是如何處理數(shù)據(jù)一致性的。因?yàn)橹皬氖碌牟皇沁@個(gè)方向的工作，所以并非什么經(jīng)驗(yàn)之談，只是一些學(xué)習(xí)筆記。所有資料來(lái)自互聯(lián)網(wǎng)。

這個(gè)是陳詞濫調(diào)了。很多文章已經(jīng)講過(guò)什么是CAP，什么是BASE了?；ヂ?lián)網(wǎng)業(yè)務(wù)“需要”Eventual Consistency貌似已經(jīng)是共識(shí)了。Eric Bewer最近接受的一次采訪，很好的總結(jié)了現(xiàn)狀（https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containe...）

  
You allow things to be inconsistent and then you find ways to

  compensate for mistakes, versus trying to prevent mistakes altogether.

并且舉了一個(gè)金融行業(yè)的例子：ATM機(jī)與銀行是聯(lián)網(wǎng)的，當(dāng)網(wǎng)絡(luò)中斷了你去ATM上取錢，ATM仍然會(huì)吐錢給你。這就說(shuō)明了即便是銀行也選擇了availability而不是consistency。但是你取第二筆就會(huì)拒絕掉。

這是一個(gè)比前一個(gè)趨勢(shì)有趣得多的現(xiàn)象。Eventual Consistent是數(shù)據(jù)層的不負(fù)責(zé)任，把hard work上推給了應(yīng)用層的開(kāi)發(fā)：

要么設(shè)計(jì)各種規(guī)則，去compensate邊邊角角的異常情況

要么在有限一致性約束下，work around一些設(shè)計(jì)（比如只有單key的一致性的數(shù)據(jù)庫(kù)，要一致就得放到一個(gè)key下）

我覺(jué)得有一個(gè)不太被重視的研究方向是架構(gòu)的選擇與開(kāi)發(fā)者的生產(chǎn)效率的關(guān)系：

數(shù)據(jù)庫(kù)只給你一個(gè)k/v模型，業(yè)務(wù)的邏輯的需求多種多樣，無(wú)比懷念sql啊

數(shù)據(jù)庫(kù)只有eventual consistency，要設(shè)計(jì)各種對(duì)賬邏輯去compensate，無(wú)比蛋疼啊

異步I/O到處都是callback，邏輯被切成了意大利面條啊

到處鼓吹micro service，跨服務(wù)的事務(wù)你來(lái)搞??？

最近在hacker news上看到關(guān)于technical debt的文章，排第一位的不是bad code，而是unfit architecture（小孩子才分對(duì)錯(cuò)）很說(shuō)明了群眾的情緒 https://news.ycombinator.com/item?id=9963994

這篇文章（http://queue.acm.org/detail.cfm?ref=rss&id=2610533）詳細(xì)描述了Eventual Consistent的各種蛋疼之處：

本來(lái)評(píng)論的順序是：
Alice: 我把戒子丟了
Alice: 歐，在樓上找到了
Bob：真為你高興

從西海岸同步到東海岸的IDC之后，因?yàn)閬y序和到達(dá)延遲，可能就變成這樣了

Alice：我把戒子丟了
Bob：真為你高興

暈倒，Bob這是起啥哄呢？你不要以為這個(gè)例子是編出來(lái)的哦。目前主流的解決方案是把評(píng)論合到一個(gè)key內(nèi)存儲(chǔ)，每次跨idc同步是把一個(gè)key整體同步。評(píng)論歸屬于一個(gè)主idc，修改只在那個(gè)idc發(fā)生。要是評(píng)論超級(jí)長(zhǎng)呢？一個(gè)key可以存儲(chǔ)的數(shù)據(jù)量是有上限的哦。

這個(gè)例子是SNS里為數(shù)不多需要強(qiáng)一致的場(chǎng)景。student和advisor是朋友，代表了一種授權(quán)。這種權(quán)限的變更如果不是立即生效的，就會(huì)導(dǎo)致用戶隱私的泄漏。

本來(lái)的順序：
student刪除了隱私圖片
student把a(bǔ)dvisor加為好友

實(shí)際的順序：
student把a(bǔ)dvisor加為好
[期間advisor可以看到student的所有圖片，包括隱私圖片]
student刪除了隱私圖片

一種更常見(jiàn)的形式是先把另外一個(gè)人拉黑，然后發(fā)朋友圈。這就要求關(guān)系鏈的變更不能是Eventual Consistent。

alice上傳了照片
alice創(chuàng)建了一個(gè)專輯
alice把照片整理到專輯里

實(shí)際的順序：

alice把照片整理到專輯里（這時(shí)既沒(méi)有照片，也沒(méi)有專輯）
alice創(chuàng)建了一個(gè)專輯
alice上傳了照片
最終照片沒(méi)有整理到專輯里

共同賬戶里本來(lái)有1000
cindy在idc1從共同賬戶里取了1000
dave同時(shí)在idc2從共同賬戶取了1000
兩個(gè)idc的數(shù)據(jù)同步之后發(fā)現(xiàn)賬戶的余額是-1000了

Google Spanner 在其paper里的這段話最能說(shuō)明這種反思的情緒：

  
We believe it is better to have application programmers deal with

  performance problems due to overuse of transactions as bottlenecks

  arise, rather than always coding around the lack of transactions

就是你可以說(shuō)一致性會(huì)導(dǎo)致延遲上升，可以說(shuō)可用性變差，但是不能直接拿走強(qiáng)一致這種選項(xiàng)。目前已知的有這么幾種數(shù)據(jù)庫(kù)做到geo replicated情況下的強(qiáng)一致性：

google spanner/f1

cockroachdb

淘寶 oceanbase 淘寶頂級(jí)科學(xué)家陽(yáng)振坤微博號(hào)@阿里正祥，發(fā)出一則消息?！皬纳现芪彘_(kāi)始，淘寶/天貓/聚劃算在支付寶上的交易，100%都在OceanBase上了。你可能沒(méi)有什么感覺(jué)?！?/p>

微信 quorum kv：http://www.infoq.com/cn/presentations/weixin-background-memory-archite...

這些數(shù)據(jù)庫(kù)是銀彈了嗎？是不是有了這種號(hào)稱全球分布的強(qiáng)一致數(shù)據(jù)庫(kù)之后就不用考慮數(shù)據(jù)是分布的事實(shí)了呢？考慮這樣一個(gè)極端情況：

  
我們寫了一個(gè)x信。A君在深圳，B君在加拿大。A君給B君發(fā)了一條消息，就是在數(shù)據(jù)庫(kù)里修改了兩條記錄。然后因?yàn)閿?shù)據(jù)庫(kù)是consistent的，內(nèi)部把改動(dòng)replicate到了北美，B君就可以看到消息了。

總感覺(jué)哪里有點(diǎn)不對(duì)。x信做為一個(gè)類似的電話公司的機(jī)構(gòu)，兩個(gè)用戶跨大洋的通信居然不是其業(yè)務(wù)層的邏輯（比如長(zhǎng)途費(fèi)啥的），而是由底層的數(shù)據(jù)庫(kù)部門來(lái)完成。這不是很奇怪的事情么？更極端的假設(shè)

  
我們寫了一個(gè)y信，可以在地球和kepler 452b之間進(jìn)行通信。A君在地球，B君在4000光年外的kepler

  452b上。A向B上發(fā)消息就是修改了兩條數(shù)據(jù)庫(kù)記錄，因?yàn)閿?shù)據(jù)庫(kù)是consistent的，B君就收到了。

這就顯然不對(duì)了。我們知道星際間的通信絕對(duì)不可能被一個(gè)consistent的假象屏蔽掉的。說(shuō)到底，數(shù)據(jù)庫(kù)怎么也是一個(gè)leaky abstraction

你可以提供一個(gè)consistent的假象，但是必須明白這背后的是至少一個(gè)跨idc的rtt的延時(shí)代價(jià)

你可以提供一個(gè)全球分布的假象，到頭來(lái)什么用戶的數(shù)據(jù)放在哪個(gè)idc是業(yè)務(wù)決定（就近訪問(wèn)降低延遲，另外也有法律規(guī)定）也不是數(shù)據(jù)庫(kù)的決定

因?yàn)楣馑俚牟豢沙?，所以大部分不要求?qiáng)一致的場(chǎng)景（比如關(guān)系鏈變更v.s.消息收發(fā)）還是要用queue的方式去做。只是這個(gè)queue一定是database的replication queue，還是業(yè)務(wù)層的event queue的區(qū)別而已。一個(gè)通信企業(yè)，其核心的跨洋通信管道是database replication queue，都不算業(yè)務(wù)邏輯，你感受一下這和當(dāng)年用Database trigger寫業(yè)務(wù)邏輯的區(qū)別

所以哪怕有spanner：

用做一種高級(jí)的容災(zāi)工具

偶爾在需要全局強(qiáng)一致的情況下，做橫跨大洋的事務(wù)

大部分的事務(wù)是在同一個(gè)zone內(nèi)的，zone間的通信仍然是業(yè)務(wù)邏輯可見(jiàn)的queue

國(guó)內(nèi)的企業(yè)已經(jīng)利用spanner類似的工具可以做到同城三園區(qū)強(qiáng)一致容災(zāi)了，跨城仍然是eventual consistent的，部分業(yè)務(wù)場(chǎng)景特殊work around

google利用spanner已經(jīng)可以做到北美東西南三片區(qū)強(qiáng)一致容災(zāi)了，猜測(cè)其真正需要跨大洋的事務(wù)用途還是很少的

最后再次強(qiáng)調(diào)一下

因?yàn)橹皬氖碌牟皇沁@個(gè)方向的工作，所以并非什么經(jīng)驗(yàn)之談，只是一些學(xué)習(xí)筆記。所有資料來(lái)自互聯(lián)網(wǎng)。