一、目标
发送消息不丢失。消费方消息不丢失,但是有可能有重复,幂等性由业务方自己处理。
二、如何保证消息不丢失
生产者端
1.发送消息接口要用带有回调方法的接口,确保发送端是成功的
2.重试机制,由于网络抖动,导致发送不成功,需要重试
broker端
1.多个副本成功接收消息,才算成功
2.要持久化到磁盘
消费者端
1.手动ACK,不要自动提交位移
三、配置中间件消息不丢失
kafka配置
生产者端
1.不要使用 producer.send(msg),而要使用 producer.send(msg, callback)。记住,一定要使用带有回调通知的 send 方法。
2.设置 acks = all。acks 是 Producer 的一个参数,代表了你对“已提交”消息的定义。如果设置成 all,则表明所有副本 Broker 都要接收到消息,该消息才算是“已提交”。这是最高等级的“已提交”定义。
3.设置 retries 为一个较大的值。这里的 retries 同样是 Producer 的参数,对应前面提到的 Producer 自动重试。当出现网络的瞬时抖动时,消息发送可能会失败,此时配置了 retries > 0 的 Producer 能够自动重试消息发送,避免消息丢失
Broker端
1.设置 unclean.leader.election.enable = false。这是 Broker 端的参数,它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多,那么它一旦成为新的 Leader,必然会造成消息的丢失。故一般都要将该参数设置成 false,即不允许这种情况的发生。
2.设置 replication.factor >= 3。这也是 Broker 端的参数。其实这里想表述的是,最好将消息多保存几份,毕竟目前防止消息丢失的主要机制就是冗余。
3.设置 min.insync.replicas > 1。这依然是 Broker 端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。
4.确保 replication.factor > min.insync.replicas。如果两者相等,那么只要有一个副本挂机,整个分区就无法正常工作了。我们不仅要改善消息的持久性,防止数据丢失,还要在不降低可用性的基础上完成。推荐设置成 replication.factor = min.insync.replicas+1。
消费者端
1.确保消息消费完成再提交。Consumer 端有个参数 enable.auto.commit,最好把它设置成 false,并采用手动提交位移的方式。
rabbitMQ配置
略
四、方案:中间件配置不丢失+本地消息表
4.1 前提:配置中间件消息不丢失
4.2 表设计
CREATE TABLE publish_message
(
id
bigint unsigned NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
message_id
varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息ID’,
routing_key
varchar(128) COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息路由键’,
exchange
varchar(128) COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息交换器’,
message
varchar(5000) COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息序列化字段’,
message_properties
varchar(512) COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息属性’,
retry_count
int DEFAULT ‘0’ COMMENT ‘消息重试次数’,
status
varchar(16) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT ‘消息发布状态:待推送to_send,已推送sent,已放弃abandoned’,
failure
varchar(2048) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘消息发布失败原因’,
create_time
datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘创建时间’,
update_time
datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘上次修改时间’,
PRIMARY KEY (id
),
UNIQUE KEY message_id_idx
(message_id
)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
offset?需要记录吗。。。
4.3 发送者端流程
4.3.1 发送消息过程
4.3.2 定时任务补偿未推送的消息
4.3.3 清理消息定时任务
定期清理过期的(14天)已发送消息
4.3.4 异常告警机制
目前采用自己配置日志告警
4.4 消费者端流程
保证手动ack,提供最佳实践文档
消息可能重复接收,幂等性由业务使用方自己考虑,文档说明
五、其它说明
消息发送失败,由定时任务进行重发,会导致之前的消息,在后面发送,因此,不能保证消息100%的顺序性,业务需要考虑这一点,数据库连接池,怎么注入