网站开发实现的功能,广州网站设计建设,门网站源码,网站优化是在哪里做修改消息百分百投递架构
在《消息可靠性保证》篇章中#xff0c;我通过生产者确认机制保障了消息会发送到MQ中#xff0c;但是在生产者与MQ建立过程的时候出现了网络抖动#xff0c;连接建立失败#xff0c;生产者就感知不到MQ返回的ack/nack#xff0c;无法完全保障消息投递…
消息百分百投递架构
在《消息可靠性保证》篇章中我通过生产者确认机制保障了消息会发送到MQ中但是在生产者与MQ建立过程的时候出现了网络抖动连接建立失败生产者就感知不到MQ返回的ack/nack无法完全保障消息投递到MQ中因此这里介绍如何保障生产者百分百将消息投递到MQ。
step1首先把消息信息业务数据存储到数据库中紧接着我们再把这个消息记录也给存储到一张消息记录表中并且在消息记录表中指定一个状态字段status来记录消息的投递状态。将status设为0表示还未被投递step2发送消息给MQ Broker节点采用Confirm确认机制发送消息会有异步的返回结果step34生产者端接收MQ Broker节点返回的Confirm确认消息结果然后进行更新消息记录表中的消息状态。将status设为1表示投递成功step5但是在消息确认这个过程中可能出现网络抖动MQ Broker端异常等原因导致 返回消息失败这个时候需要生产者对消息进行可靠性投递保障消息不丢失。所以我们需要一个定时任务比如每1分钟拉取一些消息的状态信息当然这个消息也可以设置一个超时时间比如超过1分钟status0也就说明1分钟内该消息没有被投递成功那么就会被定时任务拉取出来step6接下来我们把status0的消息进行重新投递 retry sendstep7我们可以设置最大重试次数比如投递3次还是失败就可以把该消息的状态status标记为2交给人工解决或者把这些记录到一张失败表中
通过以上步骤就能保障消息的百分百投递成功
引出重复消费问题
step2 网络抖动没有投递成功并不会照成重复消费问题因为消息并没有投递到MQ中。而step3 此时MQ已经接收到该消息返回ack时出现网络抖动导致生产者接收不到MQ返回的ack就误以为没有投递成功将消息又重新投递一遍。造成消费者重复消费
解决重复消费问题
解决消息重复消费问题需要在消费端考虑消息的幂等性。 幂等性对一个接口调用一次和调用多次得到的结果是一样的 解决方案有两套
使用数据库的唯一约束使用redis的setnx
使用数据库的唯一约束保证幂等性 单体架构 分布式
使用雪花算法、Tinyid 等生成唯一ID给消息标识和指纹码消息入库时作为主键进行保存因此保证消息唯一性优点实现简单缺点1、高并发业务下游数据库有写入性能瓶颈2、需要本地ID生成服务确保外部统一生成ID服务无法使用时可以进行兜底**解决方案**数据库进行分库分表对消息ID使用算法解析路由到不同的数据库中
Redis原子性
利用redis的setnx命令天然具有幂等性从而实现不重复消费**优点**性能高AOF模式数据不丢失缺点 1. 数据同步入库需要考虑到数据库和Redis之间的原子性 2. 消息不同步入库Redis定时同步到数据库的策略需要具体设计
** **
