逃不掉的雙十一 阿里可怕的分佈式架構隱患

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

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

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

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

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

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

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

▲

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

　　一致性(Consistency)：任何一個讀操做老是能讀取到以前完成的寫操做結果，也就是在分佈式環境中，多點的數據是一致的;

　　可用性(Availability)：每個操做老是可以在肯定的時間內返回，也就是系統隨時都是可用的。

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

　　正如咱們剛剛提到的，淘寶在系統架構中選擇了擴展性與可用性，放棄了一致性，這依然符合 「CAP定律」的觀點，意識到這一點的淘寶也採用基於MySQL的分佈式架構可以完美的解決掉高併發用戶訪問的難題。

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

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

　　啓動事務，經過數據庫鎖等方式保證事務中的數據修改的一致性

　　更改買家支付寶金額

　　更改賣家支付寶金額

　　修改訂單已付款狀態

　　修改賣家貨物數量信息

　　提交事務，保證數據所有更新

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

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

　　隔日退款——馬雲真不是爲了湊成交額

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

　　當完成銀聯支付的時候，修改訂單已付款狀態這個步驟出現了瓶頸，在理論設計須要在秒級修改的狀態在1個小時內都沒有更新，所以淘寶頁面就重複提示買家須要支付貨款，這樣就爲整個業務引入了「髒數據」，出現的貨款與訂單的重複關聯，而這種錯誤理論上是不該該出如今正常的業務邏輯中的，所以要從系統中找回多餘的付款將十分的麻煩，這也就是爲何支付寶必須在當天關閉退款申請，須要等高峯期事後經過系統維護將多餘的付款退回。同時因爲訂單修改狀態遲遲不更新，致使庫存在買家完成採購付款依然無法正常扣除，從而致使「超售」的情形發生。

　　去IOE，並非去掉「宰牛刀」

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

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

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