一、目錄
需求問題
解決方案
二、需求
現在有接近z臺分布式資料庫伺服器，m臺彙總資料庫。當前需要將z臺資料庫中的每個資料庫中的關鍵性資料同步到彙總資料庫上。彙總資料庫上的資料要求：實時，準確。
三、問題：
當前資料量比較大，資料插入更新頻繁。當前根據型別分庫，如果這一類資料出現問題，那影響的是這一類資料。
比如，當前有一億條資料，這些資料分為a類，b類，c類等等。同時，a類資料在z1資料庫上，b類在z2資料庫上，c類在z3資料庫上。這些資料都會有乙個唯一的key。
這樣每個類別的資料庫分別建立同步機制。當前選擇的同步機制是mssql發布訂閱機制：
優點：方便
缺點：實時性差(資料量大時)
穩定性差(同步資料量大時，服務會停止，需要重新初始化，千萬級別的資料就會同步半天甚至一天更多)
不夠靈活(同步掛掉的時候，要從頭開始同步，沒有標誌節點等等)
這樣根據以上的資料庫設計，如果這個庫的資料同步服務掛掉，那麼這一類資料的實時性、準確性都會受到影響。
四、解決方案
(一)資料儲存
因為資料有唯一的key。不再根據a、b、c類去分類，我們將這些資料全部打散。根據演算法存入設定的資料庫。每個資料庫400萬的資料。
唯一標識 —> 演算法—> 轉化成1~255 —>分組—>存入資料庫
1)、唯一標識演算法碼取到對應的值(1~255)
2)、我們將1~255，分位5組
index value
1 1~50
2 51~100
3 101~150
4 151~200
5 201~255
3)、資料庫和表
庫： 國家&區域 — index — 組別
d1—index—1 * d國家1區 —index — index=1的,即value1~50
表： 國家&區域 — index(組別) — data—表編號
d1—1—data—1 * d國家1區 — 組別為1 — data — table1
d1—1—data—2 * d國家1區 — 組別為1 — data — table2
庫： 國家&區域 — index — 組別
d1—index—5 * d國家1區 —index — index=5的,即value201~255
表： 國家&區域 — index(組別) — data—表編號
d1—5—data—1 *d國家1區 — 組別為1 — data — table1
d1—5—data—2 *d國家1區 — 組別為1 — data — table2
庫： 國家&區域 — index — 組別
g11—index—3 * g國家11區 —index — index=3的,即value101~150
表： 國家&區域 — index(組別) — data—表編號
g11—3—data—1 *g國家11區 — 組別為3 — data — table1
g11—3—data—2 *g國家11區 — 組別為3 — data — table2
說明：資料根據演算法得到的值(1~255)，分別存入到對應組別下的資料庫中，並且存入第乙個表。當對應的的組別下的第乙個表存滿400萬資料，立即在當前組別的資料庫下建立第二個表，以此類推。
好處：所有資料key值演算法得到的值(1~255),分散比較平均，而且值是不會變的。這樣儲存得平均而且分散，如果有新的大量資料進入，也會有很好的擴充套件性，每個表存滿後就會建立新錶。
問題：我們怎樣去查資料？
資料key—通過演算法得到value—找到對應的index組別—到對應組別資料庫下的表中查詢相關資料(多個表可以多個併發)
(二)資料同步
因為業務庫不能直連，我們採用webservice同步。將同步資料打到同步表中，有同步程式同步，同時服務端有接收程式進行處理。
分庫分表的解決方案
思路 1 完整閱讀分庫 分表策略，注意區分分庫與分表的不同，撰寫閱讀筆記。2 試驗基於ibatis spring2.0的分庫原始碼，注意思考路由的規則。3 試驗分表的原始碼實現，一般採用ibatis2.0以後的動態表名實現。以長春市教育公共服務平台管理軟體為例，在master庫中設定一張表，記錄每個...
分庫分表落地解決方案
隨著系統不斷的執行，當資料庫的資料開始超過千萬 上億時，mysql資料庫將承受更大的壓力。資料是企業生存的根本，資料庫的健康狀況將直接決了定企業的競爭力。為了更好的緩解資料庫壓力，使得系統更高效的執行，落地的解決方案有 1 分庫 也叫垂直拆分，即 每個模組對應乙個單獨的資料庫 2 分表 也叫水平拆分...
mysql分庫分表方案6 MySQL分庫分表方案
一 資料庫瓶頸 不管是io瓶頸，還是cpu瓶頸，最終都會導致資料庫的活躍連線數增加，進而逼近甚至達到資料庫可承載活躍連線數的閾值。在業務service來看就是，可用資料庫連線少甚至無連線可用。接下來就可以想象了吧 併發量 吞吐量 崩潰 1 io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放...