摘要：最近在學習各大互聯網公司是如何處理數據一致性的。目前已知的有這么幾種數據庫做到情況下的強一致性淘寶淘寶頂級科學家陽振坤微博號阿里正祥，發出一則消息。然后因為數據庫是的，內部把改動到了北美，君就可以看到消息了。

最近在學習各大互聯網公司是如何處理數據一致性的。因為之前從事的不是這個方向的工作，所以并非什么經驗之談，只是一些學習筆記。所有資料來自互聯網。

這個是陳詞濫調了。很多文章已經講過什么是CAP，什么是BASE了?；ヂ摼W業務“需要”Eventual Consistency貌似已經是共識了。Eric Bewer最近接受的一次采訪，很好的總結了現狀（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.

并且舉了一個金融行業的例子：ATM機與銀行是聯網的，當網絡中斷了你去ATM上取錢，ATM仍然會吐錢給你。這就說明了即便是銀行也選擇了availability而不是consistency。但是你取第二筆就會拒絕掉。

這是一個比前一個趨勢有趣得多的現象。Eventual Consistent是數據層的不負責任，把hard work上推給了應用層的開發：

要么設計各種規則，去compensate邊邊角角的異常情況

要么在有限一致性約束下，work around一些設計（比如只有單key的一致性的數據庫，要一致就得放到一個key下）

我覺得有一個不太被重視的研究方向是架構的選擇與開發者的生產效率的關系：

數據庫只給你一個k/v模型，業務的邏輯的需求多種多樣，無比懷念sql啊

數據庫只有eventual consistency，要設計各種對賬邏輯去compensate，無比蛋疼啊

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

到處鼓吹micro service，跨服務的事務你來搞??？

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

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

本來評論的順序是：
Alice: 我把戒子丟了
Alice: 歐，在樓上找到了
Bob：真為你高興

從西海岸同步到東海岸的IDC之后，因為亂序和到達延遲，可能就變成這樣了

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

暈倒，Bob這是起啥哄呢？你不要以為這個例子是編出來的哦。目前主流的解決方案是把評論合到一個key內存儲，每次跨idc同步是把一個key整體同步。評論歸屬于一個主idc，修改只在那個idc發生。要是評論超級長呢？一個key可以存儲的數據量是有上限的哦。

這個例子是SNS里為數不多需要強一致的場景。student和advisor是朋友，代表了一種授權。這種權限的變更如果不是立即生效的，就會導致用戶隱私的泄漏。

本來的順序：
student刪除了隱私圖片
student把advisor加為好友

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

一種更常見的形式是先把另外一個人拉黑，然后發朋友圈。這就要求關系鏈的變更不能是Eventual Consistent。

alice上傳了照片
alice創建了一個專輯
alice把照片整理到專輯里

實際的順序：

alice把照片整理到專輯里（這時既沒有照片，也沒有專輯）
alice創建了一個專輯
alice上傳了照片
最終照片沒有整理到專輯里

共同賬戶里本來有1000
cindy在idc1從共同賬戶里取了1000
dave同時在idc2從共同賬戶取了1000
兩個idc的數據同步之后發現賬戶的余額是-1000了

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

  
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

就是你可以說一致性會導致延遲上升，可以說可用性變差，但是不能直接拿走強一致這種選項。目前已知的有這么幾種數據庫做到geo replicated情況下的強一致性：

google spanner/f1

cockroachdb

淘寶 oceanbase 淘寶頂級科學家陽振坤微博號@阿里正祥，發出一則消息?！皬纳现芪彘_始，淘寶/天貓/聚劃算在支付寶上的交易，100%都在OceanBase上了。你可能沒有什么感覺?！?/p>

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

這些數據庫是銀彈了嗎？是不是有了這種號稱全球分布的強一致數據庫之后就不用考慮數據是分布的事實了呢？考慮這樣一個極端情況：

  
我們寫了一個x信。A君在深圳，B君在加拿大。A君給B君發了一條消息，就是在數據庫里修改了兩條記錄。然后因為數據庫是consistent的，內部把改動replicate到了北美，B君就可以看到消息了。

總感覺哪里有點不對。x信做為一個類似的電話公司的機構，兩個用戶跨大洋的通信居然不是其業務層的邏輯（比如長途費啥的），而是由底層的數據庫部門來完成。這不是很奇怪的事情么？更極端的假設

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

  452b上。A向B上發消息就是修改了兩條數據庫記錄，因為數據庫是consistent的，B君就收到了。

這就顯然不對了。我們知道星際間的通信絕對不可能被一個consistent的假象屏蔽掉的。說到底，數據庫怎么也是一個leaky abstraction

你可以提供一個consistent的假象，但是必須明白這背后的是至少一個跨idc的rtt的延時代價

你可以提供一個全球分布的假象，到頭來什么用戶的數據放在哪個idc是業務決定（就近訪問降低延遲，另外也有法律規定）也不是數據庫的決定

因為光速的不可超越，所以大部分不要求強一致的場景（比如關系鏈變更v.s.消息收發）還是要用queue的方式去做。只是這個queue一定是database的replication queue，還是業務層的event queue的區別而已。一個通信企業，其核心的跨洋通信管道是database replication queue，都不算業務邏輯，你感受一下這和當年用Database trigger寫業務邏輯的區別

所以哪怕有spanner：

用做一種高級的容災工具

偶爾在需要全局強一致的情況下，做橫跨大洋的事務

大部分的事務是在同一個zone內的，zone間的通信仍然是業務邏輯可見的queue

國內的企業已經利用spanner類似的工具可以做到同城三園區強一致容災了，跨城仍然是eventual consistent的，部分業務場景特殊work around

google利用spanner已經可以做到北美東西南三片區強一致容災了，猜測其真正需要跨大洋的事務用途還是很少的

最后再次強調一下

因為之前從事的不是這個方向的工作，所以并非什么經驗之談，只是一些學習筆記。所有資料來自互聯網。