做一家仓储用地的网站,wordpress恢复小工具,公司建设网站的优势,淘宝官网首页进入如果你的MQ消息要从Kafka切换到RocketMQ且不停机#xff0c;怎么做#xff1f;在让这个MQ消息调用第三方发奖接口#xff0c;但无幂等字段又怎么处理#xff1f;今天小傅哥就给大家分享一个关于MQ消息在这样的场景中的处理手段。
这是一种比较特例的场景#xff0c;需要保…
如果你的MQ消息要从Kafka切换到RocketMQ且不停机怎么做在让这个MQ消息调用第三方发奖接口但无幂等字段又怎么处理今天小傅哥就给大家分享一个关于MQ消息在这样的场景中的处理手段。
这是一种比较特例的场景需要保证切换的MQ消息不被两端同时消费并且还需要在一段消费失败后的MQ还可以继续重试。并且这一端消费的MQ消息也要保证自身的幂等。
我们知道一般通用场景下MQ消息都会有一个业务唯一ID值用于接收方做仿重处理。但除此之外还应该有一个MQ消息本身的ID这个ID也要全局唯一每一条消息都要有一个ID这是因为MQ是可能重复发送的发送MQ成功但获取MQ发送结果响应超时或更新库表消息状态失败则重复发送如果没有消息的唯一ID也就没法确保是哪一条消息了。
这个ID可以用于唯一标识、去重、链路追踪、幂等性、事务以及安装性等但可能有些伙伴在做MQ消息发送的时候是容易忽略而没有在MQ中添加这个ID或者随意用时间戳来当ID用这样都是不合理的。会影响一些场景的代码健壮性设计。 需求背景描述好了接下来我们看看这样的场景怎么设计。 1. 场景问题
将原本使用 Kafka 的MQ方式迁移到 RocketMQ同时部分场景的 MQ 消息调用三方接口是没有幂等字段的需要做好程序兼容处理。
2. 场景思考
首先我们要知道在分布式架构下我们每做的技术方案都要考虑顺序性和临界状态。像是MQ的生产和消费都是多套应用实例部署的那么生产端发送出来的MQ消息到不同的队列中也是有延迟和存放顺序以及拉取消费不同的情况。如生产端发送MQ为A、B、C、D但到Kafka/RocketMQ以及不同的消费端拉取时不一定是A、B、C、D的顺序那么直接做切量开关是可能导致一个A消息在Kafka队列中消费完点击切换开关一种切量哈希计算手段如消息{A}哈希值最后两位当做百分比用正好RocketMQ也会把A消费掉。这样同一个消息就被重复消费了。
3. 方案设计
在整个方案设计中我们要考虑几个非常重要的点。如图: 一个是切换的两端MQ消费是抢占式加锁避免重复消费。这是因为切量开关切换过程中两个消息队列中的MQ并不是顺序可靠的可能存在重复消费所以要加分布式锁。 一段MQ消费失败要进行重试但这个时候不能在消费失败后删分布式锁因为MQ消费都是很快的可能导致删锁后另外一端MQ进行了相同的消费。那可能有些伙伴会说那也没关系呀反正失败的这段没有消费成功。当往往失败并不一定是直接的结果失败可能是网络失败可能是超时失败等。也就是实际成功了但超时反馈了。所以不能被其他端重复消费并且要保证自己这一端消费失败后可重试。所以这块要设计可重入锁也就是 setnx 加锁的值为自身一段的 mq 类型这样自己在接收mq消息以后检查锁为自身加锁值可重试。这样也就保证了一端消费重试不会让另外一端把MQ也跟着消费掉因为setnx存在并且有加锁值判断所以不能进入。 另外MQ消息还可能存在同一个MQ发送多次的场景这个是非常正常的。比如你再发送MQ的时候超时网络抖动失败1万次会有1次那么就会补偿重发。但这个MQ已经发送过了所以会接收2条MQ消息。那么在消费的时候不能让2个MQ消息都进入消费中因为多台实例消费可能都去调用发奖了。那么这里还需要给MQ的ID进行幂等加锁。确保一个MQ消息失败后顺序轮训重试。也就保证了发奖的过程中不会出现超发奖品。大部分三方接口还是有幂等字段的有的话会更好。 另外还有2个开关一个是消费开关一个是切量开关。消费开关要在整个新的MQ改造工程工程全部上线后开启但还要被切量开关限定消费。开启后切量开关才会生效。切量是一种哈希值的百分比比对比如一个哈希值最后两位是10那么切量配置小于等于10%则这个MQ则可以被切量后消费另外一段则不消费这个MQ。 另外为了方便测试线上功能还会加入白名单。不过大部分时候这类东西会用通用组件能力解决。
这样的场景方案设计是非常值得积累的同类的思想也可以帮我们解决很多共性问题。
