离线消息存储方案
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]