异步队列使用的前提条件
1. 对异步业务的实时性要求不高, 可延迟执行
2. 不想影响主线逻辑, 这就要求队列的写速度非常快
总结一下最近一段时间使用消息队列(kafka)作为生产者遇到的问题:
架构设计
1. 数据库存储业务产生的基础信息, 状态为初始化 (高并发下顺序可能会不保证, 好在我们不对外, 并发性不高)
2. 定时脚本顺序扫描, 改状态为发送中, 组装完整信息, 写入到kafka
3. 发送成功后, 在kafka回调中更改状态为已完成
4. 因消费者觉得没必要发送ack回调, 所以消息发送生命线到此结束
注意, 这里消息状态有三个; 有些书里介绍说, 写入数据库就是发送中状态, 根据自己的业务看怎么设计状态
设计要点
1. 可以随时终止消息发送
有一个数据库层面的配置, 每一行记录有[ topic, 环境, 是否发送 ] 等信息, 可以控制某个环境(生产, 测试), 某个topic是否发送
要点: 如果配置为不发送, 系统可每隔10分钟发送一次报警
2. 卡住的消息, 可以自动重发
因为系统上线部署, 环境抖动等原因导致消息处理一半, 消息卡在"发送中"的状态.
系统自动重发: 每次发消息前会检查20分钟前写入数据库, 但是仍是"发送中"状态的数据, 如果有则报警, 并将消息状态改为初始化, 在下次重新尝试发送
手工重发: 需要开发用户界面, 方便操作
3. 消息体重发,注意消息ID
有的消息已经发送, 但需要再发一次, 但是每条消息都有一个唯一的消息ID, 重发时, 注意要更改此唯一的消息ID或类似作用的值
4. 只卡一种类型的消息
生产中会有很多种消息共用一个topic的情况, 考虑到消息的顺序性, 如果一种子类