作者 陳彩華
文章轉載交流請聯絡 caison@aliyun.com
複製程式碼
最近學習了阿里資深技術專家李運華的架構設計關於分庫分表的教程,頗有收穫,總結一下。
本文主要介紹高效能資料庫叢集分庫分表相關理論,基本架構,涉及的複雜度問題以及常見解決方案。
分庫分表概述
讀寫分離分散資料庫讀寫操作壓力,分庫分表分散儲存壓力
適用場景
類似讀寫分離,分庫分表也是確定沒有其他優化空間之後才採取的優化方案。那如果業務真的發展很快豈不是很快要進行分庫分表了?那為何不一開始就設計好呢?
按照架構設計的“三原則”(簡單原則,合適原則,演化原則),簡單分析一下:
首先,這裡的“如果”事實上發生的概率比較低,做10個業務有一個業務能活下去就很不錯了,更何況快速發展,和中彩票的概率差不多。如果我們每個業務上來就按照淘寶、微信的規模去做架構設計,不但會累死自己,還會害死業務。
其次,如果業務真的發展很快,後面進行分庫分表也不遲。因為業務發展好,相應的資源投入就會加大,可以投入更多的人和更多的錢,那業務分庫帶來的程式碼和業務複雜問題就可以通過加人來解決,成本問題也可以通過增加資金來解決。
業務分庫
業務分表
業務分表概述
帶來的問題
垂直分表
增加表操作的次數
水平分表
- 路由問題
- 資料庫操作問題
實現方法
類似讀寫分離,具體實現也是“程式程式碼封裝”和“中介軟體封裝”,但具體實現複雜一些,因為還有要判斷SQL中具體操作的表,具體操作(例如count、order by、group by等),根據具體操作做不同的處理。
參考