如何
实现消息同步功能
MQ实现
- 采用MQ的实现方案
联通机房的写请求写入到联通机房的MQ,然后联通机房的reship就从MCQ读,写到电信机房MQ。
电信机房collector就能从电信机房MQ读取到写请求,再写到电信机房的另一个MQ,电信机房的队列机就会从这个MQ读出写请求,然后更新缓存。
这种方案缺点:
- 流程比较长,需要多次与MQ交互,当有大量写请求时,不仅要扩容reship和collector,还需要扩容MQ以确保能够承受大量读取和写入。
更简单方案如下:
RPC调用实现
联通机房写请求会调用联通机房reship RPC=》调用电信机房collector RPC=》调用电信机房的处理机RPC,达到把联通机房写请求同步给电信机房处理机
多机房数据一致性
还要确保同步后的数据是一致的,因为同步过程各种原因都会导致各机房间数据不一致,需要确保数据一致性。
不同业务对数据一致性要求不同,金融类业务要求多机房间数据必须强一致,其它类型业务则没这么高要求,只需要能达到最终一致即可。
常见的是通过消息对账机制来保证最终一致性。
系统会给每次写请求生成一个全局唯一requestId,联通机房写请求:
- 调用联通机房的处理机RPC修改缓存和DB
- 调用联通机房的reship RPC,reship RPC再调用电信机房的collector RPC同步写请求,电信机房的collector RPC最后会调用电信机房的处理RPC来更新缓存。整个过程requestId始终保持向下传递,无论是处理成功或失败都记录一条包含requestId和机房标记的处理日志,并写到Elasticsearch集群。然后通过一个定时线程,每隔1分钟去扫描Elasticsearch集群上的日志,找出包含同一个requestId的不同机房的处理日志,然后验证是否在各个机房请求都处理成功了,如果有的机房某一阶段处理失败,则可以根据日志信息重试该阶段直到成功,从而保证数据的最终一致性。