云計算下如何平衡擴展性和穩定性SLA

云計算環境下，企業和個人通過開啟云服務，即可以得到所需的軟件功能、計算資源、存儲空間，并按實際使用量付費。在業務量逐步上漲的過程中，用戶需要不斷提升計算和存儲資源來滿足業務需要。因此，擴展性是云原生服務非常重要的服務指標。

PolarDB的共享存儲架構帶來了最優的擴展性。當用戶計算資源不足時，可以在不影響業務的情況下，動態擴充計算節點規格和數量。新增加的節點，直接訪問共享的數據副本，不需要做任何數據拷貝，所以擴充節點的耗時可以達到1分鐘內，而與數據量無關。PolarDB同時內置Proxy能力，可以將負載均衡到各個節點，使得加減節點操作對業務透明。在存儲層，所有用戶共享一個規模巨大的存儲集群。存儲集群可以動態添加新的存儲資源，因此PolarDB理論上可以做到無限的存儲容量擴展。

除了擴展性，穩定性也是云原生服務的核心指標。穩定性由RPO、RTO等指標定義。為了保障穩定性，在靠近用戶業務的計算層，PolarDB盡量讓用戶獨享資源，用戶間進行強隔離；在網絡和存儲層，采用多租戶形式。為了達到更好的穩定性和性能，PolarDB采用了全用戶態的存儲鏈路。在存儲層，將每個用戶的數據充分打散到多個存儲節點，充分利用節點的空余資源，并保障IO訪問的延遲和帶寬。在部分存儲節點出現熱點數據、資源緊張時，PolarDB會自動遷移部分數據到其他節點。采用獨有的Parallel-Raft技術，每份數據會有三個副本，每次IO都保證至少有兩個副本落盤，保障了RPO。由于是共享存儲架構，節點間狀態接近于完全同步，當一個計算節點故障時，可以快速切換到其他節點，保障了RTO。在Proxy的協同下，甚至可以做到節點切換對應用無感知

傳統分布式架構與存儲計算分離架構對比

分布式數據庫其實已經有了不短的歷史，早期的分布式數據庫，在整體架構上可以分為share nothing和share disk兩大類。

share disk通過擴展底層的SAN來提升IOPS以及存儲容量， 但是SAN的擴展性較差，成本也非常高， 因此此類架構往往被用于解決多活的高可用問題。

share nothing的數據庫是過去分布式數據庫架構的首選，被諸多互聯網公司所采用。

share nothing架構的分布式數據庫， 每一個節點擁有獨立的計算和存儲資源，每一個節點都有各自的計算引擎和存儲引擎，計算存儲綁定。 這種類型的架構好處顯而易見， 數據Sharding的方式讓數據存取以及處理可以并行化，計算存儲本地化最大化提升了數據讀寫的帶寬以及延時。在過去網絡IO還是一大瓶頸的年代， 分布式系統設計以及優化的一大原則就是盡量使得計算存儲本地化， 避免昂貴的網絡開銷。 然而share nothing架構對于跨分片的數據訪問不是很友好， 比如事務，比如全局索引，實現起來十分復雜， 效率也要打上折扣，并且因為計算資源和存儲資源是綁定的，因此數據幾乎是在所有節點上是均勻分布，在集群擴展時，計算和存儲要一起擴展，會存在資源浪費的情況，并且share nothing架構的數據庫在存儲擴展的過程中要做數據重分配，這種記錄級別的遷移需要耗費大量的計算資源，會導致遷移過程中服務性能的顯著下降。并且因為數據無法共享，因此這樣的數據庫系統往往會形成數據的孤島，很難做一些跨庫跨應用的計算。

存儲計算分離是近年來分布式系統設計架構的潮流， 從2001年開始Google的GFS開創先河地開始使用了普通X86服務器和硬盤搭建了大規模的存儲， 雖然受限于當時網絡的傳輸速度，和機器間的帶寬，還是需要耦合計算和存儲節點的分布。 但是隨著底層硬件和網絡的不斷發展，存儲計算分離的趨勢越來越明顯，計算節點通過網絡來訪問存儲的系統瓶頸也逐漸從IO變成了CPU。 當前的數據中心已經有了25G，50G和100G的網絡， 系統瓶頸也逐漸變成了資源使用率。隨著云的概念不斷發展，公有云廠商使用基于網絡的塊存儲逐步代替了單機的本地存儲，在這樣的基礎架構下計算和存儲耦合的架構已經變得不透明不合理，此時存儲計算分離的架構的優勢體現了出來，存儲計算分離，分布式存儲系統使用高密度，低功耗的服務器來解決存儲容量的水平擴展問題， 計算集群使用高主頻，多CPU，大內存的機型解決計算能力擴展的問題，模組之間互相解耦，獨立按需擴展，提供了更好的彈性以及整體資源利用率。同時存儲計算分離架構在擴展存儲時因為不再是記錄級別的遷移，不需要過多考慮數據庫系統諸如事務完整性、一致性等問題，過程中耗費的計算資源相比share nothing架構的數據庫系統大幅下降。 可以說存儲計算分離是云時代數據庫產品的事實主流架構， 無論是OLAP還是OLTP的系統， 越來越多的系統地已經采用了此架構或者是正在向著此方向演進發展。

分布式事務與集中式事務的優劣

事務處理是數據庫保證ACID語義的核心功能，因為數據庫系統需要處理大量的并發事務，為了保證并發事務能夠盡可能高效的并發執行而又互不干擾，發展出若干種技術，比如多版本并發處理(MVCC)，樂觀并發處理(OCC)，這些技術的關鍵在于多個事務同時讀寫相同的數據記錄時，如何調度事務的執行順序（等待或是回滾）保證結果符合預期。

在事務集中在單個節點處理時，事務提交的順序是單個時鐘的順序，是很好確定的，這也是集中事務處理的好處，容易保證嚴格的外部一致性。在分布式數據庫中，同樣也可以采用這種模式，將事務集中在一個節點處理，而這限制了事務處理的擴展能力，系統能處理的事務操作的數據范圍受限于單個節點所能訪問的數據范圍，事務處理能力也受限于單個節點的處理能力。