12 月 7 - 9 日，一年一度的中國大資料技術大會（BDTC 2017）在北京召開，作為國内最具影響力的大資料領域技術盛會之一，今年大會圍繞“大資料與智能”的主題，對大資料時代社會各行業的智能化程序和行業實踐展開深度分享與讨論。
在本次大會上，螞蟻金服進階研究員、OceanBase分布式關系資料庫負責人陽振坤發表了主題為《OceanBase—網際網路時代的關系資料庫實踐》的演講。本文是此次演講的精華内容集合。
陽振坤：有這麼多人在周末還來聽資料庫的講座确實令人很高興，特别感謝周傲英老師的邀請，讓我有這個機會介紹做資料庫的一點點感受。我的内容主要是三塊，先給大家介紹一下我們過去幾年開始在做資料庫時候中對原先資料庫一點點的分析，原先資料庫面臨什麼樣的困難和問題；然後是我們的方案能解決一些什麼問題；最後以現在螞蟻OceanBase中高可用的方案為例和大家做一個分享。
關系資料庫的發展現狀
關系資料庫經曆了差不多四十年的發展，與新興的網際網路相比，完全可以算得上是一個古典領域。這個行業的特别之處在于它處在一個重要底層的位置上，幾十年過去了市場和技術格局都沒有太大的變化。關系資料庫面臨的很多挑戰至今都還存在，比如作為IT三個核心之一：處理器、作業系統、資料庫，技術和産品都非常具有挑戰性，尤其是做出一個真正能用的産品。再比如關系資料庫的穩定可靠與業務使用，隻有當資料庫穩定可靠了業務系統才會使用，但是如何證明資料庫的穩定可靠呢？隻有業務系統使用了才能證明，這是一個雞生蛋蛋生雞的邏輯。
也是因為這些原因關系資料庫新陳代謝特别困難。要換一個資料庫，尤其是換做事務處理的資料庫，代價和風險都非常大，但是一般來說收益又比較小。各個資料庫的技術思路總體上是差不多的，如果說希望做一個比前人便宜十倍的資料庫，這非常非常困難。
關系資料庫之痛首要的是高成本，從使用者來說，不論是高端伺服器還是高端存儲還是資料庫軟體及服務，都非常昂貴。第二就是資料庫難以擴充。對于經曆了9年雙十一的螞蟻金服，每年都和銀行一起面臨着挑戰，系統總容量支援了雙十一那一天非常高的通路量，之後這些資源本質來講就大量閑置了，這是一個很大的成本。第三點是資料庫主庫備庫的一緻性。凡是做過金融系統服務的人都知道，銀行資料庫主庫出問題了怎麼辦？那就是恢複主庫。如果恢複不起來，就要趕緊做人工對賬，然後才用備庫把服務繼續進行下去。
熟悉資料庫的人都知道有ACID，資料庫的理論裡面我覺得這是一個遺憾，缺了一個東西就是可用性，這對于在生産中實際使用的底層基礎設施是個很可怕的事情。大家說你肯定弄錯了，資料庫是我們今天IT資訊領域可用性最高的東西之一，這句話說得沒錯，但是這種可用性不是資料庫自身帶來的。這裡更多指的是伺服器、存儲系統這些東西帶來的高可靠性，而不是資料庫系統自身。資料庫不管是理論還是實踐在這方面都存在遺憾，我們需要把資料庫依靠自身的可用性能力做好。但是反過來講這也是我今天能站在這裡的原因，如果資料庫理論研究早就做了高可用，可能今天我就沒有機會站在這裡。剛剛還提到了主庫備庫資料不一緻，有人跟我辯論過，理論上能做到，但是不是在一個你可以接受的成本的情況下做到的。
今天資料庫做資料增删改的時候，本質上原地更新，原地更新的性能，根本上是取決于磁盤的随機寫性能，大家可以通過加記憶體做很多緩解，但從根本上還是逃不掉這一點。做資料庫首先需要解決這一點，如果不解決就算把硬體成本降下來，但是性能沒有提升，最終也沒有活路。
關系資料庫這些問題其實它們一直存在，但是在網際網路比如說在雙十一購物節之前它不突出，量變沒有産生質變，但雙十一的超大規模交易一下子把這些缺陷從量變變成質變。雙十一剛開始的頭一兩年，交易并發量是從幾千到幾萬，而現在是百萬甚至千萬。網際網路把原來的關系資料庫的缺陷千萬倍地放大，放大到由量變到質變的地步。
OceanBase解決方案
有了這些分析，我們就明确了OceanBase需要解決的問題：第一，通過分布式具備彈性能力并降低成本，這有可能帶來十倍甚至更大的成本效益的優勢，并且能夠水準地擴容和縮容。這一點我們剛剛入門，也有很長的路要走。第二點是并不完全依賴于或者并不依賴于硬碟的能力做到高性能，寫事務（增删改）其實是資料庫一個硬名額，是以我們對寫來說做到了除了寫日志沒有别的硬碟操作。第三個是我們今天的重點，通過多庫多活達到高可用和強一緻。既要保證成本效益也要保證可用性。因我們給自己設定了更高目标，隻有超越前人才有機會在市場當中占領一席之地。
接下來我們看看傳統主備鏡像下主庫備庫一緻性和可用性之間的沖突：要保證備庫與主庫的資料一緻，那麼每一筆事務都需要實時從主庫同步到備庫後才能應答客戶，那麼一旦主庫備庫之間的網絡異常或者備庫異常，主庫的寫入就無法進行，即可用性失去了，這就是一個沖突，主備一緻性與服務可用性的沖突。金融行業、證券行業要求資料千萬不能丢，即使是那些能丢的行業也會産生許多麻煩，因為你會影響客戶，影響業務，是以就逼着資料庫這麼多年來一直用高可靠的硬體來減少出故障的幾率。單個硬體可以做到很高的可用性，比如五個九，但成本也會非常非常高。
OceanBase高可用的關鍵是通過事務日志的多數派。在OceanBase之前，主庫是人工指定的，我們就設定這個庫是主庫，然後它就會一直工作，直到它故障或者人工改變它。但在OceanBase裡，所有主庫都是機器自動選舉出來的。與傳統的主備鏡像是一主一備不同，OceanBase采用了一主多備，比如一主兩備共三個庫，主庫執行事務，并把事務日志同步到備庫，備庫接收事務日志并應答主庫（投票）。每一筆事務，隻有其日志同步到所有庫中超過半數的庫，這個事務才真正成功（應答客戶）。一主兩備這種情況之下，我們允許任何一台機器故障，因為每一筆送出的事務，在剩下的兩台機器中至少一台上存在，這樣保證了事務不會丢失，并且業務也不停頓。
三個庫通常部署在三個機房，其中通常有兩個機房是部署應用程式的，這也是故障恢複的需要：主機房故障後備機房的應用程式和資料庫可以繼續提供服務。備庫除了接收事務日志外，還要回放事務日志，這樣萬一主庫壞了，它可以馬上更新成主庫繼續提供服務，而且不會有任何的資料損失。檢查并且确定主庫故障需要一段時間，然後選舉出新的主庫也需要一段時間，最壞情況下總共要二十多秒，但也隻是一台機器所在的主庫會停這麼一段時間。如果是備庫出了故障，影響就更小，我們會在一定的時間之後就開始把在它上面的資料複制出去，以防萬一再壞一台。
也許有人問，PC伺服器這麼low，萬一壞了兩台怎麼辦？這真的是非常好的問題，确實也有壞兩台的，解決這個問題的辦法是采用一主四備五個庫，日志到達三個庫事務才成功。
在OceanBase的主庫選舉上起初我們也想過通過分布式鎖服務來實作，但是有一件事情阻止我們這樣做，比如支付寶内部系統用這樣一個服務，這個服務通過分布式選舉也是能夠恢複的，比如二十多秒就能恢複，但它在恢複期間對整個支付寶可用性的影響太大了。現在幾千台機器，壞一台隻是影響幾百分之一，但是分布式鎖服務停二十秒，有可能整個系統都要停二十多秒，這個對使用者有非常大的影響，權衡這個利弊我們沒有通過分布式鎖服務來選舉主備庫，解決方案是每個庫都在獨立運作和選舉的，一台機器壞了就是影響百分之一，它的影響會小的多。我們還實作了基于優先級的分布式選舉，使得正常情況下主庫在我們期望的機房，這可以提升效率并且便于管理。
分布式選舉投票協定Paxos有一個簡化的實作叫Raft，由于實作簡單，現在一些資料庫就采用了它。OceanBase 0.5在2013年底開發時也采用了類似的方法，但在OceanBase 1.0的時候，我們實作了真正的Paxos，因為我們發現了類似于Raft的協定存在的性能瓶頸：因為Raft要求嚴格按照順序對事務日志進行投票，而每一台機器都是多個線程在處理事務，網絡收發包也是多個線程，很難保證這個嚴格的順序，比如一台備機已經收到了事務四五六七八的日志，但因為沒有收到事務三的日志，是以後續的四五六七八的日志也不能投票，這就像一個流水線被打斷了。
2017年開始我們在一部分核心系統中實施三地五中心的方案，這麼多年來螞蟻金服一直在努力做到任何一個城市機房真的出故障了，我們不停業務。今天仍然沒有完全做到，重要原因是資料庫。我們現在一部分核心系統已經開始做跨城市部署。在三個城市的五個機房裡面，我們主庫可以部署在其中四個機房裡，這樣能看到我們機器使用率其實比較高，達到80%（傳統的主備鏡像隻有50%的使用率）。這樣做的好處是當真的某個城市故障了，或者整個城市交換機的出口異常了，我們的業務還能夠繼續，既不需要人工的幹預，也不會有資料上的丢失。
到這個階段系統可用性是不是就非常完善了呢，其實可能還是不夠的，有些情況下資料庫的讀請求非常多，我們需要單獨的讀庫。讀庫沒有選舉權也沒有被選舉權，它的資料有略微的延時，但是它能夠提供讀服務。在特殊情況下，讀庫可以作為應急來用。讀庫還有其他作用，比如機房搬遷或者在某個地方增加一個機房，我們可以在新機房先建一個讀庫，因為這樣整個都是自動化，會把資料、日志複制等這些事情都自動做好，完成後就可以把讀庫更新成備庫。還有一種情況作為異地的災備，比如主庫備庫都在一個城市的情況下，可以在另一個城市建立讀庫作為災備。
螞蟻金服到現在為止所有的核心系統今年雙十一之前已經全部搬到OceanBase上，以前部分系統還有商業資料庫兜底，但今年連兜底也沒有了。萬一有極端的意外導緻系統不可用怎麼辦呢？我們還有一個機制即Failover庫，它可以避免我們業務的停頓：目前系統因為某種特别的原因不可用的時候，就可以把業務的通路推送到Failover庫，這保證了業務的可用。
多庫多活可以提升伺服器使用率，比如寫五份日志需要五台機器，看起來似乎有一定的浪費。事實上，我們的機器使用率反而提高了，傳統的主庫備庫是兩個實體，它們隻有一個庫對外提供服務；OceanBase雖然有五個庫，但它們是一個實體，可以互相協調共同對外提供服務。比如三個庫的情況下，可以有三分之二機器提供服務，五個庫的情況下，則可以是80%機器提供服務。
另一個好處是通過多庫多活提升資料的壓縮倍率。資料庫今天資料量越來越大，存儲的成本也越來越高，為了降低成本，使用者希望對資料做一些壓縮，但又不希望影響性能。傳統資料庫也有資料壓縮的能力，但它是在提供服務過程中進行資料壓縮的，但在業務的高峰期，CPU可能非常緊張，能夠用來進行資料壓縮的CPU資源非常有限，無法進行複雜的資料壓縮。我們的資料壓縮是在業務的相對低谷期完成，并且在壓縮前我們會自動把主庫推走，這樣整個機器就都空閑下來了，這樣就可以進行比較複雜同時壓縮倍率更高的資料壓縮，隻要解壓縮足夠快。
當年做OceanBase這個項目的時候，最大的擔心是沒做出來之前被拍死掉，因為從頭做一個資料庫需要很多年時間來做，你沒有做出來之前被拍死的機率太高，是以我們還算運氣。我們2010年開始做，從2013年螞蟻金服決定把OceanBase用到交易系統上，2016年賬務系統正式上線，我們總共花了四年的時間把核心系統全部上線。資料庫是一個非常重要又非常複雜的系統，穩定可靠非常關鍵卻又非常困難，這樣一個複雜的系統隻能在使用中逐漸成熟，是以阿裡巴巴/螞蟻金服成千上萬的業務資料庫對OceanBase非常關鍵：這麼多的資料庫系統，我們總能夠找到一些運作OceanBase，讓OceanBase逐漸成熟起來。今天成百上千的系統一天24小時跑在OceanBase上，有了這麼多業務在驗證和幫助，是以OceanBase資料庫才能變得越來越成熟，越來越穩定。2017年我們開始向公司外面走，因為我們覺得我們應該把這些年的積累賦能給銀行等金融行業客戶，像現在浙商銀行、南京銀行都已經開始用了，這給他們非常多的成本節省。最關鍵是容量随時可以擴大和縮小。
未來優化還有很長的路要走。也感謝現場所有人對資料庫發展的支援。