最近因為專案原因一直在研究分表、分庫和讀寫分離。本來打算直接使用一款開源產品，但只開源了一部分，無奈只好自己動手豐衣足食了。
作者實現的簡單分布式資料來源:
為什麼要分表、分庫和讀寫分離？
隨著網際網路應用的廣泛普及，海量資料的儲存和訪問成為了系統設計的瓶頸問題。對於乙個大型的網際網路應用或者金融領域專案，日益增長的業務資料，無疑對資料庫造成了相當大的負載，同時對於系統的穩定性和擴充套件性提出很高的要求。隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相應地，資料操作的開銷也會越來越大；另外，無論怎樣公升級硬體資源，單台伺服器的資源（cpu、磁碟、記憶體、網路io、事務數、連線數）總是有限的，最終資料庫所能承載的資料量、資料處理能力都將遭遇瓶頸。分表、分庫和讀寫分離可以有效地減小單台資料庫的壓力。
分表、分庫常用策略：
1.平均進行分配
hash(object)%n(適用於簡單架構)。
2.按照權重進行分配且均勻輪詢。
3.按照業務進行分配。
4.按照一致性hash演算法進行分配(適用於集群架構，在集群中節點的新增和刪除不會造成資料丟失，方便資料遷移)。
分表又分為單庫分表（表名不同）和多庫分表（表名相同），不管使用哪種策略都還需要自己去實現路由。
讀寫分離的基本原理：
讓主資料庫處理事務性增、刪、改操作（insert、delete、update），而從資料庫處理select查詢操作。資料庫複製被用來把事務性操作導致的變更同步到集群中的從資料庫。
讀寫分離的基本結構：
一台主、多台從。主提供寫操作，從提供讀操作。
讀寫分離的實現：
我們只需要實現讀寫分離，主從複製資料一般由資料庫級來實現同步，當然也可以自己去實現同步，只是需要考慮的點比較多。
什麼時候用分庫、分表？什麼時候用讀寫分離？
在實際專案中可以從以下幾個維度來考慮：
1.資料實時性是否比較高？
2.查詢複雜度是否比較高？
3.讀和寫的比例即側重點是哪乙個？
作者給出的幾點建議：
1.當主鍵和分表字段為同乙個欄位時適合選用分庫、分表，因為通過主鍵進行雜湊分庫、分表時，主鍵就是唯一的獲取該條資訊的主要途徑。
2.當讀大於寫且資料量增加不明顯時適合選用讀寫分離（讀寫分離+快取）
有關Mysql分庫分表，讀寫分離資料庫水平拆分
web伺服器一般都是乙個伺服器連線乙個資料庫的架構，可是隨著系統的使用，該架構已經不能滿足需求了，這裡使用的是c3p0的資料庫水平擴容。spring核心配置 id propertyconfigurer class org.springframework.beans.factory.config.pr...
分庫分表與讀寫分離
隨著業務的發展，使用者數量與資料數量不斷增加，迫使進行分庫分表。所謂分表就是指將乙個表的資料存放到多個表，然後查詢時候按id的範圍到對應的表裡去查。因為資料太多，單個表已經不足以儲存。所謂分庫就是將資料存放到多個資料庫中，訪問時訪問其中乙個庫。社群已經黃了，基本不用了。不支援聯表，且依賴diamon...
資料庫 分區分表分庫 讀寫分離（二）
其主要目的是為突破單節點資料庫伺服器的 i o 能力限制，解決資料庫擴充套件性問題。將系統中不存在關聯關係或者需要join的表可以放在不同的資料庫不同的伺服器中。按照業務垂直劃分。比如 可以按照業務分為資金 會員 訂單三個資料庫。需要解決的問題 跨資料庫的事務 jion查詢等問題。例如，大部分的站點...