【原创】modb 功能设计之“多级 modb 之间的同步”

原创
2014/02/24 17:13
阅读数 604

      modb 在最初设计中采用的是两级模型,但很快就遇到了多级同步的需求。解决多级同步问题首先需要引入多级路由 key ,即将原来两级模型中的单个 key 值扩展为 key 的 array ,具体变化如下:

两级使用的数据格式
{
    "src" : "172.16.80.111", 
    "keys" : "key_1",
    "app" : "A",
    "state" : "transfer"
    "sql" : "insert into users values(?,?,?)";
    "sql-args" : [1, 2, "abc"]
}
多级使用的数据格式
{
    "src" : "172.16.80.111", 
    "keys" : ["key_1","key_2"]
    "app" : "A",
    "sql" : "insert into users values(?,?,?)";
    "sql-args" : [1, 2, "abc"]
}
而在 modb 的业务逻辑处理中也需要增加相应的处理,具体如下:

      假设处理的是三级数据同步情况,分别为 modb-A 、modb-B 和 modb-C 三级平台域(分别位于三级服务域中),且 A 是 B 的上级,B 是 C 的上级。A 级平台域中某业务对数据进行了变更,然后需要将此变更信息同步到 B 和 C 级平台域。


通过数据操作入口进行数据变更后,将发送如下消息给 modb-A:
{
    "src" : "172.16.80.111", 
    "keys" : ["key_B","key_C"]
    "app" : "A",
    "sql" : "insert into users values(?,?,?)";
    "sql-args" : [1, 2, "abc"]
}
modb-A 接收到此消息后(此时 A 级平台域的数据库已经发生了变更),并根据配置将
  • 向同在 A 级的其他平台域进行消息转发;
  • 根据 key 值进行对下级的路由转发;
在进行消息转发前,modb-A 还会对消息内容做如下修改:
{
    "src" : "172.16.80.111", 
    "keys" : ["key_C"]
    "app" : "A",
    "sql" : "insert into users values(?,?,?)";
    "sql-args" : [1, 2, "abc"]
}
即从 keys 数组中移除 key_B 。

      modb-B 在接收到上述消息后,将从中提取出 sql 内容进行执行,并对 keys 数组内容进行检查,看是否还有其他 key 的存在,若有,则表明需要继续进行向下级的路由转发。        
      modb-B 重新获取到该消息后(此时 B 级平台域的数据库已经得到了更新),首先检测 keys 数组中是否还有其他 key 存在,若有,则在进行转发前会对消息内容做如下修改:
      (这里 modb-B 先后两次作为 consumer 收到 rabbitmq 消息是因为分别订阅了远端和本地的 queue 所致,好处是处理起来模型统一  
{
    "src" : "172.16.80.111", 
    "keys" : []
    "app" : "A",
    "sql" : "insert into users values(?,?,?)";
    "sql-args" : [1, 2, "abc"]
}
即从 keys 数组中移除 key_C 。

      modb-C 接收到上述消息后,将从中提取 sql 内容进行执行,并对 keys 数组内容进行检查,看是否还有其他 key 的存在,若没有,则表明已不再需要继续进行路由。
      modb-C 重新获取到该消息后(此时 C 级平台域的数据库已经得到了更新),首先检测 keys 数组中是否还有其他 key 存在,若没有,则只需要对相同服务域中的平台域进行广播,而无需进行下一级转发。

      上述模型的优点是简单,仅通过配置就可以完成多级关系的数据同步功能;缺点是存在单点,不具有动态变更上下级关系的能力,需要通过其他方式进行后续配置。

可能遇到的异常情况:
  • rabbitmq 服务器异常 -- 业务更新本地数据库成功后,将发送通知消息到 rabbitmq 服务器,需要业务端能够判断出“服务器不可用”状态,并触发重传等操作;
  • modb 进程异常 -- 业务更新本地数据库成功后,发送通知消息到 rabbitmq 服务器,若要求在 modb 进程异常的情况下消息不丢失,则需要 rabbitmq 启用对消息的持久化功能,并且最好取消掉 exclusive 和 auto_delete 等相关属性的设置,可能还需要处理当 queue 不存在时消息被 blackholed 的情况;
  • Atlas 异常 -- 若在业务尚未成功更新本地数据库前发生 Atlas 异常,则要求业务能够告之当前情况下“无法建立数据库连接”;若在业务成功更新本地数据库后发生 Atlas 异常,此时向外部 modb 同步当前更新没有问题,但无法同步外部 modb 对本地数据库的更新。(可能的一种解决办法:令 modb 支持缓存功能,当发现 Atlas 异常时则将更新消息放入缓存队列,并在每次接收到新的更新消息时触发一次针对 Atlas 是否恢复的检测。若 Atlas 已经恢复,则将缓存队列中的内容顺序执行

      上述问题并未针对“异常情况下对 数据库进行操作时可能遇到的问题” 进行深入的说明,具体问题一定会更加复杂。一点体会:若想真正的把数据库同步功能做好,最起码需要深入理解数据一致性的相关理论,若有一个成熟的框架可以使用就更加完美了。


展开阅读全文
打赏
0
6 收藏
分享
加载中
j
2014/02/27 09:21
回复
举报
摩云飞博主

引用来自“摩云菜”的评论

又“贱”了啊20

36
2014/02/24 21:18
回复
举报
又“贱”了啊20
2014/02/24 21:08
回复
举报
更多评论
打赏
3 评论
6 收藏
0
分享
返回顶部
顶部