如何

实现消息同步功能

MQ实现

• 采用MQ的实现方案

联通机房的写请求写入到联通机房的MQ，然后联通机房的reship就从MCQ读，写到电信机房MQ。
电信机房collector就能从电信机房MQ读取到写请求，再写到电信机房的另一个MQ，电信机房的队列机就会从这个MQ读出写请求，然后更新缓存。

这种方案缺点：

• 流程比较长，需要多次与MQ交互，当有大量写请求时，不仅要扩容reship和collector，还需要扩容MQ以确保能够承受大量读取和写入。

更简单方案如下：

RPC调用实现

联通机房写请求会调用联通机房reship RPC=》调用电信机房collector RPC=》调用电信机房的处理机RPC，达到把联通机房写请求同步给电信机房处理机

多机房数据一致性

还要确保同步后的数据是一致的，因为同步过程各种原因都会导致各机房间数据不一致，需要确保数据一致性。

不同业务对数据一致性要求不同，金融类业务要求多机房间数据必须强一致，其它类型业务则没这么高要求，只需要能达到最终一致即可。

常见的是通过消息对账机制来保证最终一致性。

系统会给每次写请求生成一个全局唯一requestId，联通机房写请求：

1. 调用联通机房的处理机RPC修改缓存和DB
2. 调用联通机房的reship RPC，reship RPC再调用电信机房的collector RPC同步写请求，电信机房的collector RPC最后会调用电信机房的处理RPC来更新缓存。整个过程requestId始终保持向下传递，无论是处理成功或失败都记录一条包含requestId和机房标记的处理日志，并写到Elasticsearch集群。然后通过一个定时线程，每隔1分钟去扫描Elasticsearch集群上的日志，找出包含同一个requestId的不同机房的处理日志，然后验证是否在各个机房请求都处理成功了，如果有的机房某一阶段处理失败，则可以根据日志信息重试该阶段直到成功，从而保证数据的最终一致性。