阿里分布式數據庫服務實踐
沈詢: 阿里巴巴資深技術專家,08年加入阿里巴巴，一直從事阿里分布式數據層方面的研發工作，參與了公司大部分的去IOE工作，具備較多實操經驗。目前主要負責淘寶分布式數據層(TDDL)，阿里分布式數據庫服務(DRDS)，阿里分布式消息服務(Notify,MetaQ)的開發和架構設計工作。
經過近一年的運營，阿里巴巴的分布式數據庫（DRDS）已經協助電商，電信，銀行，政府等多種類型的系統進行過業務分布式改造，在系統實施的過程中，我們碰到和解決了哪些問題？ 他們是怎么解決的？背后的思考是什么？未來在何方？ 以下來分享下精彩內容。
DRDS簡介
起源
DRDS 脫胎于 alibaba的cobra 分布式數據庫引擎，06年上線使用，在alibaba有近百應用在使用，目前已經開源，DRDS的80%的代碼出自cobra proxy（Sql解析器，執行流程，配置）。
DRDS吸收了taobao TDDL分布式數據庫引擎的大量優秀經驗和解決方案，08年上線使用，目前在使用的應用近千個，大量實際應用解決方案支持分布式join，支持分布式aggregation (group sum max min)，支持異步索引構建，支持Auto sharding ,自動擴容縮容。
從TDDL到DRDS，
DRDS專門針對外部用戶進行了配置的重新設計：簡化了配置操作規范與流程；盡可能使得應用像操作一個數據庫一樣的操作DRDS；用戶的專業化指導。
場景廣泛：互聯網應用，企業內大數據應用，政務類應用，物聯網應用。
應用場景
應用的業務需求單機已經無法滿足，一個RDS數據庫的最大實例也無法滿足用戶的需求，可能遇到容量瓶頸、事務數瓶頸、讀取瓶頸，我們就可以考慮使用分布式數據庫了。
Scale out（多機水平擴展），使用廉價數據庫陣列來滿足用戶需求—DRDS。
優勢：更輕量的使用數據庫，未來更換的成本小；一次重構，以后基本再無需擔心系統瓶頸。劣勢：重構遷移需要付出成本；分布式環境下一些查詢會被限制不允許執行；完成相同功能需要比單機擴展付出更多成本。
圖1
理想狀態就是Scale out 與scale up結合。如圖1所示，讓系統架構具備scale out的能力，盡可能提升單機利用率，但不要過早過度設計。
圖2
何時應該選擇Sharding方案？圖2中的概要圖給出了分析。
DRDS功能介紹
分布式MySQL執行引擎
具有非常高的兼容性，MySQL 5.5 的各類復雜查詢都能做到，包括復雜的join,復雜的嵌套，復雜的函數。降低了遷移時候的成本。
智能下推的功能，減少網絡傳輸，減少計算量，充分發揮下層存儲的全部能力。
智能下推有兩個典型的例子，圖3為表A 分庫分表3個的例子，圖4為全表distinct groupby的執行計劃的例子。
圖3
圖4
彈性擴展
自動擴容、縮容是另外一個重要功能。如圖5，DRDS可以做到原來一個庫，下一步變成兩個庫，依然可以擴，對一些特殊需求也可以實現自動化后臺遷移，自動擴容縮容。
圖5
小表異步廣播
圖6
如圖6的跨機join的優勢是一致性，空間比較節省。劣勢是網絡消耗和延遲增加。
圖7
圖7小表廣播join的優勢是性能高，延遲低，網絡消耗小，劣勢是最終一致性，小表更新量不能太巨大。
DRDS實踐
分布式查詢優化
最終的目標是讓所有請求可以水平擴展，要想達到這個目的，有兩個基本的原則：1盡可能讓所有查詢發生在盡可能少的下層存儲節點上，最好是只發生在一臺上。將跨網絡請求盡可能減少，減少并行查詢時的機器消耗。2選擇的shardingKey要能夠讓所有存儲節點均衡的負載讀寫請求。系統可以簡單加機器來擴展，沒有系統瓶頸。案例1如圖8所示是一個訂單的場景，應該選擇哪個列作為切分條件？按照買家ID的查詢（買家查看自己買了哪些商品）。
圖8
案例2如圖9所示的過程就是數據的切分，應該選擇哪個列作為切分條件？按照買家ID的查詢（買家查看自己買了哪些商品）；按照賣家ID的查詢（賣家查看自己賣了哪些商品。
圖9
圖10表達了異構復制，數據通過后臺自動化邏輯復制過去，建立一個新的全表索引。
圖10
案例三如圖11所示，在原來表里加了type，關聯兩個表，但這兩個表不在一臺機器上，遇到這種場景就需要如圖12所示的小表異步廣播。
圖11
圖12
事務的分布式優化
事務的分布式優化的目標是完整的事務支持，既要支持ACID，又可按需無限拓展。然而這種模型是不可能實現的。
那么我們該怎么辦呢？優化事務的最重要的手段就是從強一致到最終一致。把這種情況擬人化場景為：李雷家住長江頭，梅梅家住長江尾，日日思君不見君，送只玫瑰表心意。李雷希望（ACID）：花別丟了，送不到給我退回來（原子性,A）；花能瞬時送到梅梅家（強一致性和強隔離性,C&I）；花別在路上壞了(D)。其中瞬時就是當李雷去檢查的時候，要么花在李雷那，要么花在韓梅梅那。
實現方案一：李雷做火車到長江尾，親手交給了梅梅。方案二：李雷將花交給郵遞員，郵遞員做飛機把花送給韓梅梅，李雷電話打了一天，韓梅梅都沒接，郵遞員把花交給韓梅梅，韓梅梅接起電話，告訴李雷收到花。方案二就是強一致，它的優勢是編程模型簡單，不用考慮郵遞員運輸中的各種并發問題。它的劣勢是并發性能低，李雷一天都不用干活了。
真的遇到這種情況時，我們該采用最終一致進行優化，上述情景大體不變，更改為李雷打電話韓梅梅告訴他還沒收到，李雷就去做了其他事情。最終一致的優勢是無阻塞情況，并發性能好。劣勢是復雜度略高，需要考慮玫瑰已經發出，但對方還沒收到的情況應該如何處理。
圖13展現了單機和分布式事務情況。所以我們建議結合最終一致和強一致，單機可以使用強一致，跨機建議使用最終一致。
圖13
從單機存儲到DRDS遷移流程
遷移的目標是：保證業務線上正常運轉；平滑過渡；減少運維。
遷移的步驟有三步：SETP1：讀寫在原來的單機數據庫；數據通過“愚公數據遷移平臺”寫入云上DRDS。SETP2：驗證云上數據是否正確；驗證云上DRDS是否能夠很好的應對讀流量壓力。SETP3：夜間，停寫幾分鐘；讀寫切換到DRDS；數據通過“愚公數據遷移平臺”寫回到云下單機數據庫。
PPT下載地址：http://club.alibabatech.org/resource_detail.htm?topicId=156
好高級的樣子啊
頂
能說有錯別字嘛？？？坐還是（做）？？？