作者：王濤（改天）
一、雙十一資料庫回顧
阿裡雙11期間成交額4982億，高峰訂單58.3萬筆/秒，資料庫高峰TPS1.4億/秒。核心資料庫，比如手機淘寶上看到的交易、購物車、商品、商品詳情優惠等，都來自于我們團隊資料庫，核心鍊路采用雲資料庫專屬叢集（MyBase）模式，基于雲原生資料庫建構上萬個節點RPO=0。全面采用雲原生管控形态，交易單元核心鍊路實作100% PaaS雲化，擴容效率提升10倍，與此前相比，擴容時間由30分鐘縮短至3分鐘。
二、資料庫應用場景介紹
1）阿裡業務特性介紹—RDS高可用版
一種是RDS的高可用版， RDS的高可用版是我們平時标準的一種資料庫形式，采用是一組多備的模式。大家可以看到上圖，一個Master，一個Slave，拖了多個RO節點，這個RO節點就是隻讀節點，它有個缺點，無法真正做到RPO=0。
MySQL基于半同步來做，但是半同步有一個問題，如果當Slave挂掉，半同步會自動降級。MySQL最主要核心還是為了保證主庫的高可用，而不是資料一緻的高可用，像Oracle等其他商業資料庫，當備庫被挂掉的情況下，如果你設定合理，備庫會摘主庫寫的操作，但是MySQL不會，是以說無法真正做到RPO=0。
2）阿裡業務特性介紹—RDS三節點企業版（一）
使用RDS三節點企業版的目标：解決RPO=0的問題。
RDS三節點企業版理論依據：第一點是基于CAP原則 or BASE理論，CAP原理指一緻性(Consistency)，可用性(Availability)，分區容忍性(Partition)。一般來說，CAP原理隻能滿足CA或CP，很難保證三個都滿足，最後還是做了取舍，滿足一緻性和可用性為主。
第二個是BASE理論，BASE理論表示最終一緻性，中間允許有一定的不一緻，但是作為資料庫OLTP系統來說沒法使用BASE理論。是以還是要遵循CAP原則。
MySQL不丢資料的實作方式：
- MySQL半同步，問題是半同步一定要等備庫傳回才會執行，如果在備庫挂的情況下，MySQL不等備庫，會造成MySQL半同步降級，主庫寫了備庫沒有接收到日志，是以沒辦法用。
- MySQL Group Replication
第一點，它的性能不是很好；第二點，“Group Replication”中所謂的Group，至少要三個節點以上，三個節點表示有三份資料，成本開銷巨大。
- RDS自研
RDS自研，是目前使用的方式。
實作協定
- Paxos協定 or Raft協定？
目前業界主流的分布式協定主要是兩個，一個是Paxos協定，一個是基于Raft協定，我們最終選擇使用的是Raft協定。
3）阿裡業務特性介紹—RDS三節點企業版（二）
上圖, P代表Prepare，Prepare表示事務準備送出，A代表Accept，Accept表示一定接受。
第一點，P3.1準備送出，如果A3.1還沒送出，大家沒有達成一緻的情況下，又發起P4.5送出，這時候可以發起 P4.5動作，但如果是Raft協定，一定要P3.1全部送出，A3.1全部确認完以後，它才能啟動P4.5。
第二點，A3.1和A4.5，他們同時進行送出，隻要達到多數派我們就能送出。Paxos協定和Raft的協定最大的差別就在于Paxos協定可以亂序，隻要最終一緻就可以；Raft的協定是有序的，如果有一個日志沒有進行下去，那麼下一個沒辦法開始，而 Paxos可以。
Paxos有三個角色，Propose，發起者；Accept，接收者；Learn，觀察者。
RDS三節點企業版，我們進行針對MySQL的應用場景，進行重新的角色設計：
Propose – Leader
Accept – Follower/Logger
Learn – Learner
Leader是資料庫的主節點，主要針對資料庫的讀和寫，主要是寫，Follower有全量資料，有資格成為Leader。Logger節點主要是存放資料，保證三節點的投票和協定能夠進行下去。Learner有全量資料，但是沒有投票權。
重新設計角色可以更好地滿足Paxos協定，同時性能更好，節省成本。Leader和Follower可以有全量的資料；Logger隻有日志，沒有資料，但是有投票權，不過它不能成為Leader；Learner有全量資料，但沒有投票權。這就是目前使用的RDS三節點企業版。
4）阿裡業務特性介紹—RDS異地多寫
由于阿裡的業務比較複雜，是以是異地多寫的。見上圖左半部分，我們有多套環境，環境一對應一組應用，有交易、購物車、商品等，然後寫到中心資料庫：Store或者Wright。Store主要的作用是從資料庫裡面脫下日志，Wright主要是将Store上的日志應用到對應單元去，又通過Store，然後Wright反寫回去。ThreadId保證了資料辨別及事務表做記錄，異地多寫的過程不會産生循環複制。
5）阿裡業務特性介紹—業務異地多活
異地多活主要解決以下幾個問題：
- 具備Region級别逃逸能力
- 使用者可以在任意單元進行交易
上圖表示，使用者按照一定的規則分流，可能寫在中心，也可能寫在單元。單元是自封閉的，然後呈星狀複制。
異地多活意義：
- 水準擴充能力
- 異地容災能力
6）阿裡業務特性介紹—RDS異地隻讀
異地隻讀意義：
- Learner全量資料
- Learner不影響Paxos協定
- 每個Learner都有災備節點
- 基于資料庫原生複制一緻性高
三、資料庫上雲方案選擇
1）上雲方案選擇—資料上雲方案選擇
資料上雲方式對比
上雲的方案選擇，原來阿裡巴巴都是全部在自建IDC，方案選擇上一是邏輯遷移，MySQL和DTS都認為是邏輯牽引；二是實體遷移。
如何選擇通過以下幾點對比總結：
效率上，MySQL dump效率沒有直傳恢複效率高，直傳恢複可以實作一個t一個小時，如果使用MySQL dump，從導出到導入一個t大約需要2-3個小時。
遷移性上，資料對象的平滑遷移，如阿裡巴巴的資料庫可能比較簡單，隻有table，但是有的業務資料庫還有其他類型資料，就不太适合使用MySQL dump。
資料的一緻性，備庫用資料直傳恢複比較好，使用者自定義的權限很容易丢，如果使用直傳恢複就很少會發生，是以使用直傳恢複XtraBackup來做。
RDS産品支援實體遷移對比
RDS産品支援實體遷移對比，現有兩個産品，RDS的版本它是不支援的，但是RDS的MyBase版本是支援的， MyBase資料庫主機支援 extra backup實體直傳上雲。
2）上雲方案選擇—網絡特性調研
網絡特性對比
網絡特性方面，剛開始使用ALB。現在RDS基本上都使用ALB和NGLB，ALB方案成熟，但有個問題，每一條資料的讀和寫都會經過ALB，會多一層，達不到極緻性能要求；NGLB解決了每一條讀和寫都會經過的問題，隻要首包經過，但是例如在雙十一0點資料爆發的時候，性能壓力會比較大，這種情況不一定适合使用NGLB；ENI彈性網卡，彈性網卡是标準的雲産品，目前的亞馬遜等其他雲廠商都在使用，程式彈性網卡不支援實體機，ECS的綁卡限制，資訊安全組，都是它的一些限制，但是ENI+MyBase可以解決這個問題。
總結來說：應用和資料庫在同一網絡平面上，然後中間沒有代理層，沒有NGLB或者ALB這一層，效率會比較高，管控和使用者在兩個IP上面，管控有IP，使用者應用又是一個IP，需要管控這邊進行實作。
思考+結論
基于上面有兩個思考，就是資料要雙向流動又能出，還有性能的考慮，是以使用是彈性網卡+MyBase的方案。
3）上雲方案選擇—網絡拓撲圖
如上圖所示是網絡拓撲圖，最上層是資料庫控制面，資料庫管控，需要去建立RDS執行個體等，RDS部署在一個VPC環境，RDS售賣區的VPC是中心的VPC， 每個ECS上可以部署多個資料庫，這裡換了n多個POd，一個POd就代表一個資料庫，對應的是一個彈性網卡， ECS上面飄了一個彈性網卡，連到了使用者的VPC，使用者之間的VPC是互相打通的，這裡用的是 CEN阿裡巴巴雲企業網，保證使用者 VPC和VPC之間相通，上面部分ECS和ECS之間的彈性網卡也就通了，因為資料庫通路到對應的使用者VPC，使用者之間通過雲企業網直接打通。使用者自建網絡和VPC相通是通過拉專線。
4）上雲方案選擇—邏輯金屬伺服器介紹（一）
如上圖所示是阿裡雲的邏輯金屬伺服器，最底層是阿裡雲X-Dragon晶片，上面跑着容器第三方虛拟化等；X-Dragon雲伺服器，上面跑着Doctor、 Container、 Punch等一些容器。
5）上雲方案選擇--邏輯金屬伺服器介紹（二）
邏輯金屬伺服器分為以下幾塊：
綠色部分的MOC卡主要是一個獨立的小型計算機，作用是聯通VPC\SLB，EBS雲盤。邏輯金屬伺服器上還有一個獨立的CPU和記憶體，如果是在機器上硬體本地的，想要通路這個ECS的雲盤等就是通過下面的MOC卡，然後再錄過去。
使用邏輯金屬伺服器是因為幾個特性：
- 分鐘級傳遞， 資源彈性
- 相容 VPC/SLB/RDS 等
- 雲盤啟動雲盤挂載（系統盤和資料盤，使用的都是雲盤）
- 相容虛拟機鏡像
- 實體機的性能 + 隔離性
- 虛拟機VNC/控 制台/OpenAPI 體驗
- 當機遷移恢複
- 免人肉自動運維
6）上雲方案選擇—機器選擇
如上圖綜合對比，從運維自動化、計算、存儲、網絡、ecs等多角度，邏輯金屬伺服器是最優的。
7）上雲方案選擇—存儲選擇
還有一個存儲的選擇。目前本地盤最大的規格支援6t，而雲盤的規格最大支援16t，從資料的擴充角度來說，雲盤最好。雲盤的快照能力，雲盤具有很強的擴張能力，可以支援分鐘級的備份，如果本地盤全量備份一次，用XtraBackup，是一個t一個小時，和資料量成正比，而雲盤不會這麼慢。
分鐘級的克隆。RDS界面可以支援資料克隆，如果基于雲盤快照來做克隆，會更快。跨Region的克隆，雲盤是支援，如果資料在是本地盤，想看備份，那本地的資料傳到異地，過程就會非常漫長，克隆的恢複時間也是巨大的。
雲盤支援線上擴容，本地盤不支援，如果本地盤買的是500M執行個體，要擴到510G可能還有空間，可以很快地進行擴容；如果500g要突然間擴成6個T，機器上沒有這麼多空間的情況下，那是沒辦法做線上擴容，這時候要挪資料，在運維視窗中切換等，時間又是一個非常慢的過程。
磁盤IOPS可配置性。雲盤上可以選PL1到PL3，可以選磁盤的性能等級，但本地盤是沒有可選項的。
MySQL原子寫。通過雲盤可以保證原子寫，而本地盤MySQL有double right的寫，主要保證寫的原始性，MySQL一個頁的大小是16k， Linux最大的一個頁寫入就是4k，雲盤沒有這個問題，隻要一次寫就可以了，本地盤要寫兩遍。
可靠性方面，雲盤的可靠性會比本地盤高，本地盤做的是LVM，但是雲盤有三副本。
8）上雲方案選擇 – 充分利用MyBase特性
傳統的RDS是随機打散的，客戶買了一個4c4g的實力或者8c8g的實力，不知道部署在哪裡，更多買的是一個MySQL服務，如果我們使用MyBase特性，有幾個特點，親和性等，可以排程MyBase執行個體，執行個體上面跑的是購物車或者商品，其他的東西都是可以自己去指定的。
如上圖所示，Leader和Follower交叉部署，可以保證一個性能最大化，50%是A業務的組，50%是B業務的組，這樣的效率是最高的，彈性、隔離、超慢都可以自己實作，每個機器上挂的是分布式存儲，可以快速的彈性，從a節點快速彈到b節點。
9）上雲方案選擇 – 異地隻讀(GDN)
異地隻讀是在阿裡雲官網買的執行個體就是各Region獨立。在這個項目裡面，上雲的時候，使用了GDN方案(Global Database Network)，如上圖所示，是上海三節點，上海的APP通過Mark scale進行了讀和寫，都在上海本地，如果深圳的APP通過Mark scale進行讀寫分離，然後把讀的流量路由到上海中心，寫的流量在深圳本地，這樣就可以做到了讀寫分離的作用，而目前隻是在阿裡内部使用。
四、未來展望
2020雙11，MySQL資料使用的是MyBase産品形态，客戶可以自己選擇親和性隔離等，經過了上遊評估、網絡評估、機器評估、資料庫本身的形态評估還有異地隻讀，保證了2020年雙11的平滑。
整個RDS經過了幾個過程：
- 實體機形态，實體機形态就是最早的RDS；
- 存計分離形态，存計分離形态就是的雲盤闆形态；
- MyBase形态，多樣性方面已在灰階；
- 智能化，通過RDS控制台可以看到大緻的頁面，已經在做智能化方向，後面智能調參，SQL優化、SQL診斷，性能診斷等都是要做的方向。