最近上線的項目中數(shù)據(jù)庫數(shù)據(jù)已經(jīng)臨近飽和，最大的一張表數(shù)據(jù)已經(jīng)接近3000W，百萬數(shù)據(jù)的表也有幾張，項目要求讀數(shù)據(jù)（select）時間不能超過0.05秒，但實際情況已經(jīng)不符合要求，explain建立索引，使用redis,ehcache緩存技術(shù)也已經(jīng)滿足不了要求，所以開始使用讀寫分離技術(shù)，可能以后數(shù)據(jù)量上億或者更多的時候，需要再去考慮分布式數(shù)據(jù)庫的部署，但目前來看，讀寫分離+緩存+索引+表分區(qū)+sql優(yōu)化+負載均衡是可以滿足億級數(shù)據(jù)量的查詢工作的，現(xiàn)在就一起來看一下親測可用的使用spring實現(xiàn)讀寫分離的步驟：
1. 背景
我們一般應用對數(shù)據(jù)庫而言都是“讀多寫少”，也就說對數(shù)據(jù)庫讀取數(shù)據(jù)的壓力比較大，有一個思路就是說采用數(shù)據(jù)庫集群的方案，
其中一個是主庫，負責寫入數(shù)據(jù)，我們稱之為：寫庫；
其它都是從庫，負責讀取數(shù)據(jù)，我們稱之為：讀庫；
那么，對我們的要求是：
1、讀庫和寫庫的數(shù)據(jù)一致；（這個是很重要的一個問題，處理業(yè)務邏輯要放在service層去處理，不要在dao或者mapper層面去處理）
2、寫數(shù)據(jù)必須寫到寫庫；
3、讀數(shù)據(jù)必須到讀庫；
2. 方案
解決讀寫分離的方案有兩種：應用層解決和中間件解決。
2.1. 應用層解決：
優(yōu)點：
1、多數(shù)據(jù)源切換方便，由程序自動完成；
2、不需要引入中間件；
3、理論上支持任何數(shù)據(jù)庫；
缺點：
1、由程序員完成，運維參與不到；
2、不能做到動態(tài)增加數(shù)據(jù)源；
