雲上的資料庫怎麼做？淺析AWS上Aurora的設計理念
本文來自個人微信公眾號：奔跑中的蝸牛
要提升個人能力，研究大型網際網路公司的架構是相當有必要的，今天給大家分享一篇論文。Amazon在SIGMOD 2017發表了論文《Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Relational Databases》，裡面包含的內容很多，建議每一個關注分散式系統的技術人員都應該仔細讀一遍。
Aurora是什麼？
Aurora是AWS上的分散式關係型資料庫，早在2014年，在AWS re:Invent大會上，AWS就宣佈推出Amazon Aurora。這是一個面向亞馬遜關係資料庫服務（RDS）的相容MySQL的資料庫引擎，Aurora完美契合了企業級資料庫系統對高可用性、效能和擴充套件性、雲服務託管的需求。目前的Aurora可跨3個可用區的6-路複製、30秒內便可完成故障轉移、同時具備快速的crash recovery能力。在效能方面，Aurora現在比RDS MySQL 5.6和5.7版本快5倍。
Aurora整體的架構設計
Aurora的架構並不是類似於Google Spanner的NewSQL資料庫，而是一種基於mysql實現的資料庫，複用了很多mysql的功能，因此mysql的使用者可以完美的切換到Aurora。相對於NewSQL資料庫，Aurora顯得並沒有那麼驚豔，但是卻非常實用。
Aurora的設計理念是“日誌就是資料庫”，不只是在Aurora的設計理念中，在很多分散式系統中，日誌代表的意義都非同一般，可以說，日誌就是一切，Aurora的設計者認為，當前海量資料處理的主要瓶頸已經從計算、儲存IO轉移到了網路IO，在分散式場景下，只要網路IO足夠，很多分散式系統的架構設計都可以重新考慮，為了解決網路IO的問題，Aurora將計算和儲存分離，也就是說資料庫把所有的日誌和儲存從mysql中剝離出來，放到S3上，通過將重做日誌記錄寫入儲存層，系統可以將網路的IOPS減少一個數據量級。查詢處理、事務、快取等資料庫的核心功能都還是在計算層的mysql例項中處理，但是持久化、備份恢復等能力都已經移到了S3上。
降低寫次數
我們都知道傳統資料庫有寫放大問題，也就是本來一條記錄，到資料庫層面，要寫各種日誌（redolog、undolog、binlog），資料要寫4分，至少要進行4次網路IO，並且有3次是序列的，這就是效能差的原因。Aurora的整個方案可以理解為CQRS模式，也就是寫的時候只要寫入佇列即返回，讀的時候走快取。
如圖所示，它涉及以下步驟：
（1）接收日誌記錄並新增到記憶體中佇列，
（2）持久化記錄，並給客戶端返回，
（3）歸類日誌，並確認有哪些丟失了，
（4）通過GOSSIP協議與其他節點互動，
（5）將日誌記錄合併到新資料頁，
（6）定期將日誌和新頁儲存到S3，
（7）定期垃圾收集舊版本，
（8）定期驗證頁面上的CRC碼。 只有1、2步需要序列，後面都是非同步的。
怎麼實現擴充套件性及高可用
如圖所示，Aurora由3個跨AZ（可以理解為同城的資料中心）的例項組成，一個主例項和多個副本例項（可以擴充套件到15個），寫只能通過主例項，讀則可以通過任何例項進行，主例項與副本例項或者儲存節點間只傳遞redo日誌和元資訊。每個AZ儲存兩個副本，主例項併發向6個儲存節點和副本例項傳送日誌，當4/6的儲存節點應答後，則認為日誌已經持久化，不必等待6個節點全部返回。注意，Aurora提供了6副本能力，但是並沒有分片。 去年Aurora釋出了multi-master，允許多節點寫入，但是並沒有相關的設計描述放出來。
Aurora的設計目標是要滿足以下場景，
1、如果三個AZ中有一個AZ掛掉還可以寫
2、如果三個AZ中有一個AZ掛掉，另外兩個沒有掛掉的AZ中有一個例項掛掉了，不影響讀，且不會丟失資料
很明顯，根據Quorum協議，是滿足要求的，W=4，R=3，N=6，滿足W+R>N，且滿足2W>N,是為了解決寫衝突，兩次寫入必須有交集，這樣才能在寫的過程中解決寫衝突。
仔細研究發現，如果在三個AZ儲存5份資料，寫3份，讀3份，實際上也能滿足以上要求，並且節點數更少，通訊的壓力也更小，那麼為什麼要6節點呢？就是為了滿足上面第2個要求，“如果三個AZ中有一個AZ掛掉，另外兩個沒有掛掉的AZ中有一個例項掛掉了，不影響讀”，另外，當某個節點出現故障的時候，Aurora能夠快速恢復，在10Gbps網路下（有錢任性），一個10G的分片可以在10s內恢復，也就是說當一個AZ出現了問題，另外兩個沒有掛掉的AZ中有一個例項掛掉了，對寫的影響只有10s。
本文由筆者根據論文總結，不免有疏漏之處，僅供參考，論文中還有很多有意思的點，讀者可以自行研究。
論文地址：https://www.allthingsdistributed.com/files/p1041-verbitski.pdf