分布式開發之發布與訂閱
發布訂閱：數據實時備份同步
軟件環境：sql server2008 r2
硬件環境：視數據量和對應機器分配的任務而定
機器數量：視分割線標准而定(即數據分別存放的分割線)
作 用 ：
- 數據庫服務器出問題時我們也有其正常工作時的備份
- 一台服務器負載不起時，可以用來做負載均衡
- 數據庫服務器可以無間斷，無損失遷移
- 主服務器被攻擊或當機時另一台服務同步機可以應急
意 義：咱們可以用於兩台服務器，其中一台機器用作增刪改，另外一台機器用作查詢，為了防止讀寫分離(即發布訂閱)的信息有分差，可以做出選擇，即當前日期一周(時間視發布與訂閱的日期而定，因為訂閱是可自動設置時間的，如連續訂閱或者在某一時間段訂閱)以內的數據查詢在發布的機器上運行，當前日期一周之前的數據在訂閱機器上運行。
擴 展：
- 創建一個臨時(發布)DB與一個分機(訂閱)DB,當想數據庫中insert數據的時候，插入到臨時DB中，臨時DB發布數據，分機DB訂閱此數據(訂閱的表可個根據表中的數據量波動而定，振幅小的無需訂閱). 注：臨時DB與所有分機DB中的除某些特定的表(振幅較大，發布的表)外，其他數據(元數據，如：issuetable, actiontable…)可以確保一致，以犧牲分機機器硬盤空間換取運行時的內存空間與效率.
- 以分機DB的ticket達到幾百萬或者發布訂閱一年為分割線(分割線可根據具體情況而定),創建分機DB1。當分機DB1達到分割線時，創建分機DB2；當分機DB2達到分割線時，創建分機DB3……(若后續發現分機DB2分機DB1或者某幾個機器的數據訪問量並不大時，可將這些DB合多為1).當創建DB2時，可以將臨時DB中與DB1中相同的數據刪除(刪除臨時DB中被發布且已經被分機DB訂閱的數據。注：若執行此方案，首先需要驗證被刪除的數據是否已經全部被訂閱成功，其次發布訂閱的實時性，在刪除臨時DB數據時，分機DB的數據是否也被刪除，需要檢查是否需要在執行該操作時，暫時取消發布訂閱機制)
- 在數據庫訪問層進行配置數據庫與表的對應關系，即在數據庫訪問層中根據需要操作的表的分割線決定數據在那個分機DB，而配置對應的連接字符串。
其 他：數據庫分布式開發還有分庫分表(Sharding)，Sharding的基本思想就要把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的性能問題。對於海量數據的數據庫，可以使用垂直切分，即把關系緊密（比如同一模塊）的表切分出來放在一個server上。如果每張表的數據非常多，這時候適合水平切分，即把表的數據按某種規則（比如按ID散列）切分到多個數據庫(server)上。
總 結：發布訂閱相比Sharding，發布訂閱是以犧牲物理存儲空間來換取查詢的執行速度，而且相比較而言，對於發布訂閱可能維護的難度會更大。比如各個分機DB中的Metadata是重復的，若其中某一個表(IssueType)的某條數據的Name發生了改變，我們需要寫腳本對所有的分機DB的name執行update(這里不對分機DB使用發布訂閱來保證分機DB的metadata的統一，是因為如果分機DB過多沒有辦法保證它們的實時性。)。Sharding是根據某些表之間的關聯進行分表分庫，對於Metadata不會出現重復，各個庫之間都是獨立的數據，只是在查詢的時候可能會join到多個數據庫或者多個server，從而大大的降低了查詢的效率。
|
|
發布與訂閱 |
分庫分表(Sharding) |
| 原理 |
犧牲物理存儲空間來換取查詢的執行速度 |
把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的性能問題 |
| Metadata |
重復 |
不重復 |
| 維護難度 |
大 |
小 |
| 查詢效率 |
高 |
低 |
| Server之間的聯系 |
小(各個機器上的數據是分開獨立的) |
大 |
| 需要更改proc |
No |
Yes |
| 查詢是否需要多台機器join |
|
|
if您看了這篇博客。對您有所幫助，請不要吝嗇您的“推薦”，您的推薦將是我最大的動力。有問題的話可以評論交流。
本博客為原創博客，轉載請注入出處