微服务信息同步方案(数据依赖一致性问题)

2,355 阅读4分钟

背景

微服务场景下需要同步信息的场景。

还是前文的栗子: 如下微服务

  • 支付服务:负责完成支付操作,其中有支付流水数据。
  • 账单服务:指定时间生成账单给用户,其中有账单流水数据。

此时产品上有个需求,在支付管理端根据是否出账搜索支付流水,而出账是账单服务的功能。所以这里涉及到信息的同步,那么,我们怎么保证同步一定能成功呢(最终一致性)。

消费者

保证在队列中的消息,一定会被消费。用白话来讲,就是不停消费直到成功。

方式比较简单: 消息队列都使用手动提交。处理完了,再保证提交。 尽量遵循触发-查询机制,提供可重入性,即消息队列只传递id这种非实质信息,收到之后再通过rpc查询拉取完整数据来更新。

生产者

主要是发送消息到队列这步的可靠性考量

方案一:浅尝辄止

以递增的时间间隔重试5次。如果失败了,上报到日志和告警,人工介入。 同时,具体业务准备好重试的脚本。根据实时的情况进行处理。 优点:

  • 简单,能解决瞬间的网络抖动造成的失败。

缺点:

  • 可靠性低。在消息队列故障30分钟这种场景下,无法自动恢复,同时从日志捞取信息,也不是特别方便。

方案二:内有波澜

失败之后,内存维护一个重试队列,先由5,10,20, 40, 80, 160, 320s的间隔重试。 之后以5分钟一次的间隔请求。同时,也要打入日志系统,告警通知。

优点:可靠性会比一高很多,在消息队列故障30分钟这种场景下,也能自动恢复。可以做成package的方式,方便接入。

缺点:

  • 服务重启或者机器挂了,消息就丢了。

限制:

  • 消息处理需要遵循触发-查询机制

方案三:内有波澜plus

失败之后,内存维护一个重试队列,先由5,10,20, 40, 80,160, 320s的间隔重试。然后append到本地文件,同时以5分钟一次的频率做重试。重试完成之后,从磁盘中删除对应信息。当服务重启,从磁盘把数据导入内存即可。

优点:

  • 可靠性会比一高很多,在消息队列故障30分钟这种场景下,也能自动恢复,可以做成包的方式。
  • 具有比较强的通用型

缺点:

  • 增加了和磁盘打交道的逻辑,引入了文件io。

限制:

  • 消息处理需要遵循触发-查询机制

方案四:有备无患

实现任务重试微服务,该服务通过维护一张任务表,重试任务直到成功。相当于是消息队列这个可靠中间件有问题,就丢给这个重试服务这个自己实现的“中间件”。

优点:

  • 可靠性会比一高很多,在消息队列故障30分钟这种场景下,也能自动恢复。
  • 具有比较强的通用性。

缺点:

  • 成本变高,需要额外服务。同时,如果服务也挂了,还是得依赖上报。(当然,上报也可能挂了)

限制:

  • 消息处理需要遵循触发-查询机制

以上方案中,三,四基本能解决重试阶段写入消息队列的可靠性问题。 但针对另一个场景:正想写本身服务就没了的情况(比如oom导致服务被系统kill了) 还是不行。

方案五:先入为主

要做变更之前,先写入到消息同步微服务,告诉他要做什么事(把什么消息放入消息队列),和流程最长执行时间,以及发给谁。该服务维护一张任务表,任务初始处于未激活状态。

等业务做完要同步的时候,再rpc请求触发激活。

任务管理微服务如果发现一个任务,超过最长执行时间没有激活。就说明激活rpc失败了,或者是服务崩溃,本身就没做变更。此时,自动激活即可。

优点:完全可靠(事务可能还是会失败,可靠指数据一定最终一致)。

缺点:

  • 开发成本比较大,同时会增加消息调用。
  • 增加一个节点,事务失败得可能性更高。

限制:

  • 消息处理需要遵循触发-查询机制

总结

推荐:方案三

推荐理由: 成本不高,可靠性较强。可靠度99.99%。(此处不论代码本身bug)