一種高效、可自動擴容、快取、永久儲存通用方案設計
離線訊息儲存方案
1 系統框架設計
1.1 名詞解釋：
|
名詞 |
解釋 |
備註 |
|
OffServer叢集 |
離線訊息伺服器叢集 |
|
|
Redis |
一個redis例項 |
用於儲存一些關鍵資訊 |
|
MysqlKeyHashServer（MKHS） |
代理整個MySql儲存伺服器叢集 |
OfflineServer向MKHS傳送“增加一條離線訊息請求”，MKHS根據“會話ID”，將其固定hash到一臺mysql伺服器上。 |
|
NotifyServer（NS） |
通知伺服器，通知各種事件 |
當由於儲存容量/儲存速度不夠時，我們增加mysql例項後，需要修改我們的hash策略，並通過NS伺服器通知到所有的MKHS和MDS；以及資料遷移完成後，再次通知所有MKHS。 |
|
MoveDataServer（MDS） |
資料遷移伺服器 |
當由於儲存容量/速度不夠時，我們添加了mysql例項，一旦接收到MKHS的hash策略變更訊息，則開始自動遷移資料，完成遷移後通知NS。 |
|
Mysql叢集 |
某一個Mysql例項 |
1.2 元件圖
1.3 mysql資料庫設計
1.3.1 表定義
1.3.2 表管理
每一個mysql，根據將會話ID離散成500（可進行自定義）張表進行儲存。
2 序列設計
2.1 儲存離線訊息
2.2 讀取離線訊息
2.3 新增mysql例項
2.3.1 第一步驟同步新Hash演算法
2.3.2 第二步驟資料遷移
1 重要演算法
1.1 MysqlKeyHash演算法描述
Topic總量在每遇到一個分支後，將離散出50%，並繼續離散，直到葉節點為止。
1.2 情形1
此時mysql1上儲存著百分之百的Topic訊息。
數學描述：
[1]
1.3 情形2
“Mysql例項1”此時上儲存著50%的Topic訊息；
“Mysql例項2”此時上儲存著50%的Topic訊息；
數學描述：
[1][1,2]
[2]
1.4 情形3
“Mysql例項1”此時上儲存著50%的Topic訊息；
“Mysql例項2”此時上儲存著25%的Topic訊息；
“Mysql例項3”此時上儲存著25%的Topic訊息；
數學描述：
[1][1,2]
[2][2,3]
[3]