在剛剛過去的雙十一，淘寶怒斬571億交易額，成為年度的最大贏家。負責(zé)本次雙十一技術(shù)服務(wù)的螞蟻金服集團表示：雙十一的交易峰值已經(jīng)達到285萬筆/分鐘，相比去年雙十一期間79萬筆/分鐘的交易峰值，今年系統(tǒng)的支撐能力達到了去年3倍以上，用戶整體支付體驗相比去年也順暢不了不少。從網(wǎng)友反饋的實際體驗來說，今年雙十一相比往年的確有了不小的提升，頁面打開的速度更快了，支付等待時間更短了，優(yōu)惠力度更給力了……但是有沒有問題?有，而且這些問題從某種意義上講則是致命的。
抽風(fēng)的支付寶，多次付款的迷局
11月11日凌晨1點，多家電商平臺反饋稱，支付寶出現(xiàn)支付故障，用戶無法正常支付。這也不是雙十一第一次出現(xiàn)類似的故障。去年雙11開始后，由于訂單量瞬間激增，就曾爆發(fā)多家網(wǎng)銀無法通過支付寶支付的情況。今年雙11在手機支付寶上也一度出現(xiàn)癱瘓，即使在阿里巴巴的直播大廳中，也無法支付成功。
在筆者看來，即便是采用了云計算的全新方式，支付寶的使用弊端依然是存在的，而且這些弊端在系統(tǒng)架構(gòu)層面一直是淘寶解決不了的死結(jié)，這就是系統(tǒng)架構(gòu)層面的硬傷——分布式系統(tǒng)的數(shù)據(jù)一致性。而要解釋這個問題，還要從淘寶主張的“去IOE”說起。
簡單、有效的淘寶的分布式架構(gòu)
2008年，從微軟亞洲技術(shù)研究院離職來到阿里巴巴任首席架構(gòu)師的王堅提出“去IOE”的技術(shù)路線，即以廉價的PC服務(wù)器替代小型機，以基于開源的MY SQL自研數(shù)據(jù)庫替代Oracle數(shù)據(jù)庫，用低端存儲取代高端存儲設(shè)備，阿里巴巴的交易系統(tǒng)架構(gòu)進行了重構(gòu)，根據(jù)業(yè)務(wù)和對象的不同，統(tǒng)一集中的數(shù)據(jù)庫被拆分成了無數(shù)的耦合度較小的數(shù)據(jù)庫。顯然在這種架構(gòu)下，隨著業(yè)務(wù)的發(fā)展，可以增加新的數(shù)據(jù)庫，也可以擴展已有的數(shù)據(jù)庫，系統(tǒng)的擴展性和整體擁有成本非常好。
多年來的市場表現(xiàn)證明，分布式架構(gòu)有效解決了淘寶海量數(shù)據(jù)高并發(fā)、高增長的問題，對于淘寶這種簡單事務(wù)為主的C2C的業(yè)務(wù)模式來說也最適合。與此同時，在淘寶的系統(tǒng)架構(gòu)中也秉承了擴展性高于一切、系統(tǒng)可用性高于一致性與適當(dāng)放寬一致性約束等原則。對于絕大多數(shù)應(yīng)用場景來說，這種分布式系統(tǒng)是合適的、高效的。如果不是出現(xiàn)雙十一這種前無古人、全球罕見的大規(guī)模交易，分布式系統(tǒng)堪稱C2C業(yè)務(wù)的完美形態(tài)。
問題正是出現(xiàn)在“分布式”這種特點中。按照美國著名科學(xué)家Eric Brewer在2000年提出的理論，當(dāng)技術(shù)架構(gòu)從集中式架構(gòu)向分布式架構(gòu)演進，會遇到 “CAP定律”的瓶頸。 CAP說明一個數(shù)據(jù)處理系統(tǒng)不能同時滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時滿足兩個。
一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結(jié)果，也就是在分布式環(huán)境中，多點的數(shù)據(jù)是一致的;
可用性(Availability)：每一個操作總是能夠在確定的時間內(nèi)返回，也就是系統(tǒng)隨時都是可用的。
分區(qū)容忍性(Partition Tolerance)： 在出現(xiàn)網(wǎng)絡(luò)分區(qū)(比如斷網(wǎng))的情況下，分離的系統(tǒng)也能正常運行。
正如我們剛剛提到的，淘寶在系統(tǒng)架構(gòu)中選擇了擴展性與可用性，放棄了一致性，這依然符合 “CAP定律”的觀點，意識到這一點的淘寶也采用基于MySQL的分布式架構(gòu)能夠完美的解決掉高并發(fā)用戶訪問的難題。
分布式系統(tǒng)的軟肋——數(shù)據(jù)一致性
我們通過一個交易模型可以更好的解釋這個問題。例如，一件商品有100個庫存，而在同時有130個人在進行搶購的時候，集中式架構(gòu)在完成買家付款這個業(yè)務(wù)操作時候系統(tǒng)需要做6個步驟：
啟動事務(wù)，通過數(shù)據(jù)庫鎖等方式保證事務(wù)中的數(shù)據(jù)修改的一致性
更改買家支付寶金額
更改賣家支付寶金額
修改訂單已付款狀態(tài)
修改賣家貨物數(shù)量信息
提交事務(wù)，保證數(shù)據(jù)全部更新
在集中式模型下，數(shù)據(jù)庫和中間件均采用單線程模式處理業(yè)務(wù)，因此以上4個步驟的修改是同步的，因此如果支付寶接收到買家的付款以后，數(shù)據(jù)庫事務(wù)處理將保證4個步驟的數(shù)據(jù)修改的一致性，即使該事務(wù)出現(xiàn)因為系統(tǒng)問題失敗了，系統(tǒng)將同步退回到執(zhí)行事務(wù)以前的狀態(tài)。因此及時出現(xiàn)頁面提交失敗而重新刷新的時候，維護系統(tǒng)能夠很方便查出買家付款但沒有修改狀態(tài)的問題，通過重新執(zhí)行上述流程就可更新系統(tǒng)狀態(tài)，因此不會出現(xiàn)重復(fù)付款的情況。另外在完成該數(shù)據(jù)庫事務(wù)操作中的幾毫秒中，賣家的貨物數(shù)量會暫時被鎖住，其他買家在這個時間段內(nèi)無法修改賣家貨物數(shù)量信息這個字段，因此也不存在超售的情況。
但在分布式模型下，數(shù)據(jù)庫采用分布式的和數(shù)據(jù)庫讀寫分離，也就是買家?guī)?、賣家?guī)臁⒂唵螏臁⒅Ц秾氋~戶庫等均是完全物理分離的數(shù)據(jù)庫，而為了提高并發(fā)訪問的效率，每個庫都由多臺鏡像數(shù)據(jù)庫組成，同時為了消除讀寫瓶頸，每個數(shù)據(jù)庫的數(shù)據(jù)只保存一部分?jǐn)?shù)據(jù)，由上層應(yīng)用來進行復(fù)雜的系統(tǒng)調(diào)度。在執(zhí)行事務(wù)中的每一個步驟都是通過異步方式來完成的。
隔日退款——馬云真不是為了湊成交額
昨天在跟幾個業(yè)內(nèi)朋友吃飯的時候，有人提到本次雙十一期間，特別是從11日零點到11日24點這段時間內(nèi)，用戶是不能得到退款的，當(dāng)時便有人戲稱馬云為了突破去年的成交額“禁止退款”。但事實上，且不說馬云是不是需要通過這種方式實現(xiàn)成交額的激增，單看淘寶在系統(tǒng)架構(gòu)上的設(shè)計，在如此大規(guī)模并發(fā)的請求下，退款將是一件非常困難的事情。
當(dāng)完成銀聯(lián)支付的時候，修改訂單已付款狀態(tài)這個步驟出現(xiàn)了瓶頸，在理論設(shè)計需要在秒級修改的狀態(tài)在1個小時內(nèi)都沒有更新，因此淘寶頁面就重復(fù)提示買家需要支付貨款，這樣就為整個業(yè)務(wù)引入了“臟數(shù)據(jù)”，出現(xiàn)的貨款與訂單的重復(fù)關(guān)聯(lián)，而這種錯誤理論上是不應(yīng)該出現(xiàn)在正常的業(yè)務(wù)邏輯中的，因此要從系統(tǒng)中找回多余的付款將十分的麻煩，這也就是為什么支付寶必須在當(dāng)天關(guān)閉退款申請，需要等高峰期過后通過系統(tǒng)維護將多余的付款退回。同時由于訂單修改狀態(tài)遲遲不更新，導(dǎo)致庫存在買家完成采購付款依然沒法正?？鄢?，從而導(dǎo)致“超售”的情形發(fā)生。
去IOE，并不是去掉“宰牛刀”
記得當(dāng)年淘寶大規(guī)模宣布“去IOE”時，業(yè)內(nèi)對于阿里的技術(shù)能力和IT視野都給予了充分的肯定。即便是到了現(xiàn)在，去IOE依然被證明是淘寶正確的舉措。以技術(shù)能力而言，淘寶具備了世界頂尖的系統(tǒng)開發(fā)、運營和維護能力，絲毫不遜色于國外的Google和永遠打不開的Facebook。而且從業(yè)務(wù)模式來說，C2C對于業(yè)務(wù)的安全性并沒有苛刻的要求，從成本和應(yīng)用的角度考慮，小型機抑或大型機的確是“宰牛刀”。
但正是從淘寶開始，去IOE似乎成為了一種行業(yè)的趨勢，并大有蔓延之勢。想想以淘寶的技術(shù)能力尚有每年雙十一的支付困境，其他企業(yè)如何能夠真正實現(xiàn)系統(tǒng)與業(yè)務(wù)的安枕無憂?想想每到春運便被吐槽無數(shù)的12306，想想如果是在電信、銀行這樣的關(guān)鍵系統(tǒng)中出現(xiàn)支付問題，其影響與后果都將是聳人聽聞。
有道是”術(shù)業(yè)有專攻“，沒有哪種架構(gòu)是萬能的，分布式也不是萬能的。雙十一是一面照妖鏡，讓我們看到分布式系統(tǒng)的強大，也看到集中式系統(tǒng)的穩(wěn)健。就是你有勇氣決定進行分布式的改造，風(fēng)險、技術(shù)門檻、后期的運維，估計也只有像阿里才能創(chuàng)造這樣的神話。
該文章轉(zhuǎn)載自http://server.it168.com/a2014/1112/1681/000001681959_all.shtml
