貼士：這是我的OceanBase摘錄筆記，文中都是通過百度搜索的資料，我覺得好的案例就留下了。最底下有一些鏈接來源，可以看原作者的文章。
OceanBase是阿里集團研發的可擴展關系型數據庫。2015年4月2日，螞蟻金服方面宣布，螞蟻金服及阿里巴巴自主研發的通用關系數據庫OceanBase已經開始支撐淘寶、天貓和聚劃算的所有日常交易。
開始的OceanBase是應用于淘寶收藏夾數據庫，用于存儲淘寶用戶收藏條目和具體的商品、店鋪信息，每天支持4～5千萬的更新操作。
淘寶海量數據庫之一：來自業務的挑戰
數據目標：數百TB數據量、數十萬TPS、數百萬QPS。
小貼士：TPS=服務器每秒處理的事務數；QPS=每秒的響應請求數。
淘寶收藏夾是淘寶線上應用之一，淘寶用戶在其中保存自己感興趣的寶貝(即商品，此外用戶也可以收藏感興趣的店鋪)以便下次快速訪問、對比和購買等，用戶可以展示和編輯(添加/刪除等)自己的收藏。
淘寶收藏夾數據庫包含了收藏info表(一條一條的收藏信息)和收藏item表(被收藏的寶貝和店鋪)等：
收藏info表保存收藏信息條目，數十億條
收藏item表保存收藏的寶貝和店鋪的詳細信息，數億條
熱門寶貝可能被多達數十萬買家收藏
每個用戶可以收藏千個寶貝
寶貝的價格、收藏人氣等信息隨時變化
如果用戶選擇按寶貝價格排序后展示，那么數據庫需要從收藏item表中讀取收藏的寶貝的價格等最新信息，然后進行排序處理。如果用戶的收藏條目比較多(例如1000條)，那么查詢對應的item的時間會較長：假設如果平均每條item查詢時間是5ms，則1000條的查詢時間可能達到5s，若果真如此，則用戶體驗會很差。
思路二：
參考分布式表格系統做法，比如Google Bigtable系統。
原理是大表劃分為無數子表，子表之間按照主鍵有序分布，如果某臺服務器發生故障，它上面服務的數據能夠在很短的時間內自動遷移到集群中所有的其他服務器。解決了可擴展性的問題，少量突發服務器故障或增加服務器對使用者基本透明，能夠輕松應對突發流量增長，很好解決了范圍查詢問題。
弊端與問題：無法支持事務是最大的問題。
bigtable只支持單行事務，不支持多條記錄的操作。而OceanBase希望希望能夠支持跨行跨表事務，最直接的做法是在Bigtable開源實現（HBase或Hypertable）的基礎上引入“兩階段提交”協議支持分布式事務，這種思路體現在Google的Percolator系統，然后該系統事務平均響應時間2-5秒（這是有問題的），并且Bigtable的開源實現不夠成熟，單臺服務器能支持的數據量有限，難保證單個請求的最大響應時間，機器故障等異常處理機制也有很大比較嚴重的問題。總體上看，這種做法的工作量和難度超出了項目組的承受能力。
Google關于分布式事務的文章(“Large-scale Incremental Processing Using Distributed Transactions and Notifications”)可以拜讀一下
因此，根據業務特點做了一些定制。
OceanBase是“基線數據（硬盤）”+“修改增量（內存）”的架構，如下圖所示：
雖然在線業務的數據量十分龐大（幾十億、上百億），但是最近一段時間的修改量往往不多（幾千萬、幾億條）。因此OceanBase決定采用單臺更新服務器來記錄最近一段時間的更改量-增量數據，而以前的數據，即基線數據保持不變。基線數據以類似分布式文件系統的方式存儲于多臺基線數據服務器中，每次查詢都需要把基線數據和增量數據融合后返回給客戶端。這樣，寫事務都集中在單臺更新服務器上，避免了復雜的分布式事務，高效地實現了跨行跨表事務；另外，更新服務器上的修改增量能夠定期分發到多臺基線數據服務器中，避免成為瓶頸，實現了良好的擴展性。
當然，單臺更新服務器的處理能力總是有一定的限制。因此，更新服務器的硬件配置相對較好，如內存較大、網卡及CPU較好；另外，最近一段時間的更新操作往往總是能夠存放在內存中，在軟件層面也針對這種場景做了大量的優化。
知乎“正祥(陽振坤博士)”關于OceanBase的介紹
作者：正祥
2016年12月-知乎
據博士知乎所說，OceanBase團隊潛心于研發OceanBase 1.0版本，今年終于上線。應用于支付寶的賬務等核心系統，并通過了2016年雙11交易支付洪峰的考驗，終于摘下了金融系統數據庫的皇冠上的明珠，賬務數據庫。1.0也是OceanBase架構真正確立的第一個版本，消除了之前版本的寫入瓶頸，水平線性擴展，兼容MySQL，性價比遠遠高于MySQL，機房故障時數據零丟失，業務不中斷。近期OceanBase對外有一些溝通交流，主要是彌補之前對外溝通交流不足，盡力消除外界對OceanBase的不理解和誤解等。
2016年11月-知乎
OceanBase是“基線數據（硬盤）”+“修改增量（內存）”的架構，如下圖所示：
即整個數據庫以硬盤（通常是SSD）為載體，新近的增、刪、改數據（“修改增量”）在內存，而基線數據在保存在硬盤上，因此OceanBase可以看成一個準內存數據庫。這樣的好處是：
·寫事務在內存（除事務日志必須落盤外），性能大大提升
·沒有隨機寫硬盤，硬盤隨機讀不受干擾，高峰期系統性能提升明顯；對于傳統數據庫，業務高峰期通常也是大量隨機寫盤（刷臟頁）的高峰期，大量隨機寫盤消耗了大量的IO，特別是考慮到SSD的寫入放大，對于讀寫性能都有較大的影響
·基線數據只讀，緩存（cache）簡單且效果提升
·線上OceanBase的內存配置是支撐平常兩天的修改增量（從OceanBase 1.0開始，每臺OceanBase都可以寫入，都承載著部分的修改增量），因此即使突發大流量為平日的10-20倍，也可支撐1~2個小時以上。
一個問題是：修改增量在內存，大概需要多大的內存？即使按雙11全天的支付筆數10.5億筆，假設每筆1KB，總共需要的內存大約是1TB，平均到10臺服務器，100GB/臺。
另一個問題是：在類似雙十一這種流量特別大的場景中，就像前面說到的，OceanBase內存能夠支持峰值業務寫入1~2個小時以上，之后OceanBase必須把內存中的增刪改數據（“修改增量”）盡快整合到硬盤并釋放內存，以便業務的持續寫入。整合內存中的修改增量到硬盤，OceanBase稱為每日合并，必然涉及到大量的硬盤讀寫（IO），因此可能對業務的吞吐量和事務響應時間（RT）產生影響。如何避免每日合并對業務的影響呢？OceanBase通過“輪轉合并”解決了這個問題。
眾所周知，出于高可用的考慮，OceanBase是三機群（zone）部署：
根據配置和部署的不同，業務高峰時可以一個機群（zone）、兩個機群（zone）或者三個機群（zone）提供讀寫服務。OceanBase的輪轉合并就是對每個機群（zone）輪轉地進行每日合并，在對一個機群（zone）進行每日合并之前，先把該機群（zone）上的業務讀寫流量切換到另外的一個或兩個機群（zone），然后對該機群（zone）進行全速的每日合并。因此在每日合并期間，合并進行中的機群（zone）沒有業務流量，僅僅接收事務日志并且參與Paxos投票，業務訪問OceanBase的事務響應時間完全不受每日合并的影響，僅僅是OceanBase的總吞吐量有所下降：如果先前是三個機群（zone）都提供服務則總吞吐量下降1/3，如果先前只有一個或兩個機群（zone）提供服務則總吞吐量沒有變化。
輪轉合并使得OceanBase對SSD十分友好，避免了大量隨機寫盤對SSD壽命的影響，因此OceanBase可以使用相對廉價的“讀密集型”SSD來代替傳統數據庫使用的相對昂貴的“讀寫型”SSD，而不影響性能。此外由于輪轉合并對服務器的CPU使用、硬盤IO使用以及耗時長短都不敏感（高峰期的傳統數據庫在刷臟頁的同時還要優先保證業務訪問的吞吐量和事務響應時間，刷臟頁的CPU及IO資源都非常受限），因此OceanBase在每日合并時可以采用更加高效的壓縮或者編碼算法（比如壓縮或編碼速度略慢，但壓縮率較高、解壓縮很快的算法），從而進一步降低存儲成本并提升性能。
淘寶：OceanBase分布式系統負載均衡案例分享
2013-02-28 csdn 作者：孫志東
OceanBase系統架構介紹
OceanBase是一個具有自治功能的分布式存儲系統，由中心節點RootServer、靜態數據節點ChunkServer、動態數據節點UpdateServer以及數據合并節點MergeServer四個Server構成[1]，如圖1所示。
Tablet：分片數據，最基本的存儲單元，一般會存儲多份，一個Table由多個tablet構成；
RootServer：負責集群機器的管理、Tablet定位、數據負載均衡、Schema等元數據管理等。?
UpdateServer：負責存儲動態更新數據，存儲介質為內存和SSD，對外提供寫服務；
ChunkServer：負責存儲靜態Tablet數據，存儲介質為普通磁盤或者SSD。
MergeServer：負責對查詢中涉及多個Tablet數據進行合并，對外提供讀服務；
在一個集群中，Tablet的多個副本分別存儲在不同的ChunkServer，每個ChunkServer負責一部分Tablet分片數據，MergeServer和ChunkServer一般會一起部署。
雙十一前期準備
對于淘寶的大部分應用而言，“雙十一”就是一年一度的一次線上壓測。伴隨流量不斷刷新著歷史新高，對每個系統的可擴展性提出了很大的挑戰。為了迎戰雙十一各產品線對有可能成為瓶頸部分的流量進行預估和擴容成為刻不容緩的任務。在本文要分享的案例中，應用方根據歷史數據預估讀請求的訪問峰值為7w QPS，約為平時的5-6倍，合計每天支持56億次的讀請求。當時OceanBase集群部署規模是36臺服務器，存儲總數據量為200億行記錄，每天支持24億次的讀請求。
當前集群的讀取性能遠不能滿足需求，我們首先進行了一次擴容，上線了10臺Chunkserver/Mergeserver服務器。由于OceanBase本身具有比較強的可擴展性，為集群加機器是一件非常簡單的操作。中心節點Rootserver在新機器注冊上線后，會啟動Rebalance功能以Tablet為單位對靜態數據進行數據遷移，見下圖的示意，最終達到所有ChunkServer上數據分片的均衡分布。
擴容完成后引入線上流量回放機制進行壓力測試，以驗證當前集群的性能是否可以滿足應用的雙十一需求。我們使用了10臺服務器，共2000-4000個線程并發回放線上讀流量對集群進行壓測，很快發現集群整體的QPS在達到4萬左右后，壓測客戶端出現大量超時現象，平均響應延遲已經超過閾值100ms，即使不斷調整壓力，系統的整體QPS也沒有任何增大。此時觀察整個集群機器的負載狀態發現只有極個別服務器的負載超高，是其他機器的4倍左右，其他機器基本處于空閑狀態，CPU、網絡、磁盤IO都凸現了嚴重的不均衡問題。
負載不均衡導致了整體的吞吐取決于負載最高的那臺Server，這正是前文提到的典型 “短板理論”問題。
負載不均問題跟蹤
客戶端連接到OceanBase之后一次讀請求的讀流程如下圖所示：
Client 從RootServer獲取到MergeServer 列表；
Client將請求發送到某一臺MergeServer；
MergeServer從RootServer獲取請求對應的ChunkServer位置信息；
MergeServer將請求按照Tablet拆分成多個子請求發送到對應的ChunkServer；
ChunkServer向UpdateServer請求最新的動態數據，與靜態數據進行合并；
MergeServer合并所有子請求的數據，返回給Client；
OceanBase的讀請求流程看起來如此復雜，實際上第1步和第3步中Client與RootServer以及MergeServer與RootServer的兩次交互會利用緩存機制來避免，即提高了效率，同時也極大降低了RootServer的負載。
分析以上的流程可知，在第2步客戶端選擇MergeServer時如果調度不均衡會導致某臺MergeServer機器過載；在第4步MergeServer把子請求發送到數據所在的ChunkServer時，由于每個tablet會有多個副本，選擇副本的策略如果不均衡也會造成ChunkServer機器過載。由于集群部署會在同一臺機器會同時啟動ChunkServer和MergeServer，無法簡單區分過載的模塊。通過查看OceanBase內部各模塊的提供的監控信息比如QPS、Cache命中率、磁盤IO數量等，發現負載不均問題是由第二個調度問題引發，即MergeServer對ChunkServer的訪問出現了不均衡導致了部分ChunkServer的過載。
ChunkServer是存儲靜態Tablet分片數據的節點，分析其負載不均的原因包含如下可能：
數據不均衡： ChunkServer上數據大小的分布是不均衡的，比如某些節點因為存儲Tablet分片數據量多少的差異性而造成的不均衡；
流量不均衡：數據即使是基本均衡的情況下，仍然會因為某些節點存在數據熱點等原因而造成流量是不均衡的。
通過對RootServer管理的所有tablet數據分片所在位置信息Metadata進行統計，我們發現各個ChunkServer上的tablet數據量差異不大，這同時也說明擴容加入新的Server之后，集群的Rebalance是有效的（后來我們在其他應用的集群也發現了存在數據不均衡問題，本文暫不解釋）。
盡管排除了數據不均衡問題，流量不均衡又存在如下的幾種可能性：
存在訪問熱點：比如熱銷的商品，這些熱點數據會導致ChunkServer成為訪問熱點，造成了負載不均；
請求差異性較大：系統負載和處理請求所耗費的CPU\Memory\磁盤IO資源成正比，而資源的耗費一般又和處理的數據量是成正比的，即可能是因為存在某些大用戶而導致沒有數據訪問熱點的情況下，負載仍然是不均衡的。
經過如上的分析至少已經確定ChunkServer流量不均衡問題和步驟4緊密相關的，而目前所采用的tablet副本選擇的策略是隨機法。一般而言隨機化的負載均衡策略簡單、高效、無狀態，結合業務場景的特點進行分析，熱點數據所占的比例并不會太高，把ChunkServer上的Tablet按照訪問次數進行統計也發現并沒有超乎想象的“大熱點”，基本服從正太分布。
可見熱點Tablet雖訪問頻率稍高對負載的貢獻率相對較大，但是熱點tablet的占比很低，相反所有非熱點tablet對負載的貢獻率總和還是很高的，這種情況就好比“長尾效應”[3]。
負載均衡算法設計
如果把熱點ChunkServer上非熱點Tablet的訪問調度到其他Server，是可以緩解流量不均問題的，因此我們設計了新的負載均衡算法為：以實時統計的ChunkServer上所有tablet的訪問次數為Ticket，每次對Tablet的讀請求會選擇副本中得票率最低的ChunkServer。
同時考慮到流量不均衡的第二個原因是請求的差異較大問題，ChunkServer對外提供的接口分為Get和Scan兩種，Scan是掃描一個范圍的所有行數據，Get是獲取指定一行數據，因此兩種訪問方式的次數需要劃分賦予不同的權重(α,β)參與最終Ticket的運算：
除此之外，簡單的區分兩種訪問模式還是遠遠不夠的，不同的Scan占用的資源也是存在較大差異的，引入平均響應時間（avg_time）這個重要因素也是十分必要的：
負載均衡算法要求具有自適應性和強的實時性，一方面新的訪問要實時累積參與下次的負載均衡的調度，另一方面歷史權重數據則需要根據統計周期進行非線性的衰減（y 衰減因子），減少對實時性的影響：
采用新的算法后，很好的緩解了負載不均衡的問題，整體負載提升了1倍，整體QPS吞吐提升到了8w。
小結
負載均衡問題是老生常談的問題，解決不好就會出現“短板效應”，更甚至引發分布式系統中的連鎖反應即“雪崩”，從而演化成系統的災難。負載均衡的算法也層出不窮，有的出于成本最優，有的是為了最小延遲，有的則是最大化系統吞吐，目的不同算法自然各異，不存在包治百病的良方，并不是越復雜的算法越有效[4]，要綜合考慮算法所需數據獲取的Overhead，更多的是遵循“簡單實用”的法則，根據業務場景進行分析和嘗試。
正是這種靈活性的策略，對我們的系統設計提出了新的需求，要有一定的機制來監控和驗證問題：比如可以實時獲取系統運行的各種內部狀態和數據，允許選擇不同負載均衡算法進行試驗等。
其他學習資料來源于百度搜索：
1）CSDN:http://www.csdn.net/article/2015-04-02/2824402 楊振坤博士文章
2）CSDN：http://blog.csdn.net/u010359965/article/details/49795047
3）知網空間：http://www.cnki.com.cn/Article/CJFDTotal-JSJX201610012.htm
4）知乎：https://www.zhihu.com/question/19841579
5）阿里2016年線上測試邀請：https://help.aliyun.com/noticelist/articleid/13072677.html?spm=5176.789004749.n2.12.sEHGHY
6）http://tech.it168.com/a2012/0302/1319/000001319239.shtml
7）http://blog.sina.com.cn/s/blog_3fc85e260100mwsg.html 正祥新浪博客
8）http://www.csdn.net/article/2013-02-28/2814303-sharing-OceanBase-distributed-system-load-balance-case 孫志東
