現在，最新的 1.0版實現了每一個節點都可以做查詢、更新，處于一個完全對等的狀態。這樣的設計是為了增強系統的水平擴展能力。而在高可用方面，的數據通常是至少擁有3個副本，并處于不同的機房。
最大的集群規模數已經達到了上百個節點，支撐的是在線交易型的數據，一套集群可以服務很多個業務。甚至在上了公有云服務之后，可以支撐成百上千個租戶。為此，開發人員將租戶機制放進了數據庫集群里面，這樣的好處顯而易見，那就是成本得到極大的降低。
在線交易中，每一筆交易都是非常少量數據的更新或者查詢操作。但是要查大量數據，比如用戶的詳單、歷史數據狀態時，如果資源調度能力不強，那將是非常危險的。可以在租戶級別將資源的使用控制在安全的水位，從而避免了如雙11中出現大查詢而導致網絡堵塞的情況。
對于數據庫來說，水平擴展其實是非常簡單的。比如要增加一個節點，新購置一臺服務器讓oracle跑得更快2：基于海量數據的數據庫設計與優化，剩下的數據庫自己就能夠解決，包括數據重新的分布等。
節點故障，硬件損壞，系統升級等，這些情況非常常見，如何做到持續可用呢？提供了一種服務，在中間設置了一層，主要是表分區信息、位置信息等。當要做某一個查詢的時候，根據查詢條件會自動化地將請求分發到集群的特定節點上，這樣就保證了路由是最短的，因此獲得的性能也是最好的。
與傳統的數據庫不一樣，從誕生開始就沒有準備采用磁盤，而是在SSD上，包括讀寫分離、批量回刷都基于此。另外，還充分利用內存計算的能力來提升性能。當然，數據不可能一直放在內存，為此，技術團隊設計了一些特別的機制，比如把內存里的數據回寫到SSD，而且都是在系統運行低谷期進行這樣的操作。
如果性能不提升，即便是擴展性非常好，也沒有價值，因為那只意味成本的不斷增加。為此，技術團隊針對內存做了大量的性能優化工作。比如通常的應用場景有兩種，一種是獲取單條的記錄，另一種是獲取一批記錄。在內存里面維持兩套索引，一個是Hash索引，一個是Btree索引，分別對應處理這兩種不同的請求。同時，內存數據結構都是設計成無鎖的，所以擴展性非常好。
這里對比一下MySQL。大家都認為MySQL的性能很好，路徑很簡單，但是測試數據顯示，其單核的TPS能夠達到1萬，但是32核幾乎難以做到10萬的TPS。的單核TPS是8000或16000，而10核的TPS則達到8萬或16萬，正因為如此，即便是跑在普通的服務器上，也不會產生并發瓶頸。
的發展
現在支撐了支付寶的所有核心業務，如支付、交易、賬務、花唄等讓oracle跑得更快2：基于海量數據的數據庫設計與優化，還有網商銀行以及淘寶的很多交易業務也都基于。
在研發之初，技術團隊在存儲方面做了較多的工作，所以SQL能力不是特別強，因此也制約了一些拓展業務的能力。但近年來，技術團隊投入很大的精力提升的SQL能力，兼容并超越MySQL，甚至逐步具備的核心能力。這樣，未來業務的遷移會變得平滑順暢，且不需做改動。
項目始于2010年。
在2011年開始做第一個業務，還是一個KV系統。
2012年，開始做SQL支持，也明確了其目的——為了支持更高要求的金融級的業務需求。
2014年，發布了非常重要的0.5版本，通過架構的一些改進，已經可以做到持續可用且數據0丟失。在這一年，也首次支撐了支付寶的核心業務，2014年雙11，支付寶交易有一部分流量是跑在上的。
2015年3月，支付寶所有的交易都切換到了上，真正意義上徹底和說再見。
而很快，就可以提供云數據庫服務。
掃碼關注，獲取更多技術干貨。
