在剛剛過去的雙十一，淘寶怒斬 571 億交易額，成為年度的最大贏家。負責本次雙十一技術服務的螞蟻金服集團表示：雙十一的交易峰值已經達到 285 萬筆/分鐘，相比去年雙十一期間 79 萬筆/分鐘的交易峰值，今年系統的支撐能力達到了去年 3 倍以上，用戶整體支付體驗相比去年也順暢不了不少。從網友反饋的實際體驗來說，今年雙十一相比往年的確有了不小的提升，頁面打開的速度更快了，支付等待時間更短了，優惠力度更給力了……但是有沒有問題?有，而且這些問題從某種意義上講則是致命的。

　　抽風的支付寶，多次付款的迷局

　　11 月 11 日凌晨 1 點，多家電商平臺反饋稱，支付寶出現支付故障，用戶無法正常支付。這也不是雙十一第一次出現類似的故障。去年雙 11 開始后，由于訂單量瞬間激增，就曾爆發多家網銀無法通過支付寶支付的情況。今年雙 11 在手機支付寶上也一度出現癱瘓，即使在阿里巴巴的直播大廳中，也無法支付成功。

　　在筆者看來，即便是采用了云計算的全新方式，支付寶的使用弊端依然是存在的，而且這些弊端在系統架構層面一直是淘寶解決不了的死結，這就是系統架構層面的硬傷——分布式系統的數據一致性。而要解釋這個問題，還要從淘寶主張的“去 IOE”說起。

　　簡單、有效的淘寶的分布式架構

　　2008 年，從微軟亞洲技術研究院離職來到阿里巴巴任首席架構師的王堅提出“去 IOE”的技術路線，即以廉價的 PC 服務器替代小型機，以基于開源的 MySQL 自研數據庫替代 Oracle 數據庫，用低端存儲取代高端存儲設備，阿里巴巴的交易系統架構進行了重構，根據業務和對象的不同，統一集中的數據庫被拆分成了無數的耦合度較小的數據庫。顯然在這種架構下，隨著業務的發展，可以增加新的數據庫，也可以擴展已有的數據庫，系統的擴展性和整體擁有成本非常好。

　　多年來的市場表現證明，分布式架構有效解決了淘寶海量數據高并發、高增長的問題，對于淘寶這種簡單事務為主的 C2C 的業務模式來說也最適合。與此同時，在淘寶的系統架構中也秉承了擴展性高于一切、系統可用性高于一致性與適當放寬一致性約束等原則。對于絕大多數應用場景來說，這種分布式系統是合適的、高效的。如果不是出現雙十一這種前無古人、全球罕見的大規模交易，分布式系統堪稱 C2C 業務的完美形態。

　　問題正是出現在“分布式”這種特點中。按照美國著名科學家 Eric Brewer 在 2000 年提出的理論，當技術架構從集中式架構向分布式架構演進，會遇到 “CAP 定律”的瓶頸。 CAP 說明一個數據處理系統不能同時滿足一致性，可用性和分區容錯性這三個需求，最多只能同時滿足兩個。

　　一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結果，也就是在分布式環境中，多點的數據是一致的。

　　可用性(Availability)：每一個操作總是能夠在確定的時間內返回，也就是系統隨時都是可用的。

　　分區容忍性(Partition Tolerance)： 在出現網絡分區(比如斷網)的情況下，分離的系統也能正常運行。

　　正如我們剛剛提到的，淘寶在系統架構中選擇了擴展性與可用性，放棄了一致性，這依然符合 “CAP 定律”的觀點，意識到這一點的淘寶也采用基于 MySQL 的分布式架構能夠完美的解決掉高并發用戶訪問的難題。

　　分布式系統的軟肋——數據一致性

　　我們通過一個交易模型可以更好的解釋這個問題。例如，一件商品有 100 個庫存，而在同時有 130 個人在進行搶購的時候，集中式架構在完成買家付款這個業務操作時候系統需要做 6 個步驟：

1. 啟動事務，通過數據庫鎖等方式保證事務中的數據修改的一致性
2. 更改買家支付寶金額
3. 更改賣家支付寶金額
4. 修改訂單已付款狀態
5. 修改賣家貨物數量信息
6. 提交事務，保證數據全部更新

　　在集中式模型下，數據庫和中間件均采用單線程模式處理業務，因此以上 4 個步驟的修改是同步的，因此如果支付寶接收到買家的付款以后，數據庫事務處理將保證 4 個步驟的數據修改的一致性，即使該事務出現因為系統問題失敗了，系統將同步退回到執行事務以前的狀態。因此及時出現頁面提交失敗而重新刷新的時候，維護系統能夠很方便查出買家付款但沒有修改狀態的問題，通過重新執行上述流程就可更新系統狀態，因此不會出現重復付款的情況。另外在完成該數據庫事務操作中的幾毫秒中，賣家的貨物數量會暫時被鎖住，其他買家在這個時間段內無法修改賣家貨物數量信息這個字段，因此也不存在超售的情況。

　　但在分布式模型下，數據庫采用分布式的和數據庫讀寫分離，也就是買家庫、賣家庫、訂單庫、支付寶賬戶庫等均是完全物理分離的數據庫，而為了提高并發訪問的效率，每個庫都由多臺鏡像數據庫組成，同時為了消除讀寫瓶頸，每個數據庫的數據只保存一部分數據，由上層應用來進行復雜的系統調度。在執行事務中的每一個步驟都是通過異步方式來完成的。

　　隔日退款——馬云真不是為了湊成交額

　　昨天在跟幾個業內朋友吃飯的時候，有人提到本次雙十一期間，特別是從 11 日零點到 11 日 24 點這段時間內，用戶是不能得到退款的，當時便有人戲稱馬云為了突破去年的成交額“禁止退款”。但事實上，且不說馬云是不是需要通過這種方式實現成交額的激增，單看淘寶在系統架構上的設計，在如此大規模并發的請求下，退款將是一件非常困難的事情。

　　當完成銀聯支付的時候，修改訂單已付款狀態這個步驟出現了瓶頸，在理論設計需要在秒級修改的狀態在 1 個小時內都沒有更新，因此淘寶頁面就重復提示買家需要支付貨款，這樣就為整個業務引入了“臟數據”，出現的貨款與訂單的重復關聯，而這種錯誤理論上是不應該出現在正常的業務邏輯中的，因此要從系統中找回多余的付款將十分的麻煩，這也就是為什么支付寶必須在當天關閉退款申請，需要等高峰期過后通過系統維護將多余的付款退回。同時由于訂單修改狀態遲遲不更新，導致庫存在買家完成采購付款依然沒法正常扣除，從而導致“超售”的情形發生。

　　去 IOE，并不是去掉“宰牛刀”

　　記得當年淘寶大規模宣布“去 IOE”時，業內對于阿里的技術能力和 IT 視野都給予了充分的肯定。即便是到了現在，去 IOE 依然被證明是淘寶正確的舉措。以技術能力而言，淘寶具備了世界頂尖的系統開發、運營和維護能力，絲毫不遜色于國外的 Google 和永遠打不開的 Facebook。而且從業務模式來說，C2C 對于業務的安全性并沒有苛刻的要求，從成本和應用的角度考慮，小型機抑或大型機的確是“宰牛刀”。

　　但正是從淘寶開始，去 IOE 似乎成為了一種行業的趨勢，并大有蔓延之勢。想想以淘寶的技術能力尚有每年雙十一的支付困境，其他企業如何能夠真正實現系統與業務的安枕無憂?想想每到春運便被吐槽無數的 12306，想想如果是在電信、銀行這樣的關鍵系統中出現支付問題，其影響與后果都將是聳人聽聞。

　　有道是”術業有專攻“，沒有哪種架構是萬能的，分布式也不是萬能的。雙十一是一面照妖鏡，讓我們看到分布式系統的強大，也看到集中式系統的穩健。就是你有勇氣決定進行分布式的改造，風險、技術門檻、后期的運維，估計也只有像阿里才能創造這樣的神話。