异步消息队列实战要点回顾(kafka)

本文介绍了异步消息队列使用前提、架构设计和关键设计要点,重点探讨了Kafka作为生产者时如何处理消息发送、状态管理、错误处理和报警机制。强调了Kafka客户端的单例模式、消息ID的处理以及避免死循环的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

异步队列使用的前提条件

1. 对异步业务的实时性要求不高, 可延迟执行

2. 不想影响主线逻辑, 这就要求队列的写速度非常快

总结一下最近一段时间使用消息队列(kafka)作为生产者遇到的问题:

架构设计

1. 数据库存储业务产生的基础信息, 状态为初始化 (高并发下顺序可能会不保证, 好在我们不对外, 并发性不高)

2. 定时脚本顺序扫描, 改状态为发送中, 组装完整信息, 写入到kafka

3. 发送成功后, 在kafka回调中更改状态为已完成 

4. 因消费者觉得没必要发送ack回调, 所以消息发送生命线到此结束

注意, 这里消息状态有三个; 有些书里介绍说, 写入数据库就是发送中状态, 根据自己的业务看怎么设计状态

设计要点

1. 可以随时终止消息发送

  有一个数据库层面的配置, 每一行记录有[ topic, 环境, 是否发送 ] 等信息, 可以控制某个环境(生产, 测试), 某个topic是否发送

  要点: 如果配置为不发送, 系统可每隔10分钟发送一次报警

2. 卡住的消息, 可以自动重发

  因为系统上线部署, 环境抖动等原因导致消息处理一半, 消息卡在"发送中"的状态.

  系统自动重发: 每次发消息前会检查20分钟前写入数据库, 但是仍是"发送中"状态的数据, 如果有则报警, 并将消息状态改为初始化, 在下次重新尝试发送

  手工重发: 需要开发用户界面, 方便操作

3. 消息体重发,注意消息ID

  有的消息已经发送, 但需要再发一次, 但是每条消息都有一个唯一的消息ID, 重发时, 注意要更改此唯一的消息ID或类似作用的值

4. 只卡一种类型的消息

        生产中会有很多种消息共用一个topic的情况, 考虑到消息的顺序性, 如果一种子类型的消息卡住了,  其后的消息都不能发送; 但是不能影响其他子类型的消息发送

5. 报警方式

  最好是选择报警到钉钉群或微信群, 如果邮件的话, 会影响电脑或手机的正常使用

6. 忽略部分错误消息

  比如kafka, 作为生产者, 如果连接broker失败, 是自己可以自动重试的, 但重试成功前的那次链接失败可以不用报警(错误码是-192)

7. kafka客户端实例需要是单例模式

    kafka扩展是以回调的方式告知主程序, 消息发送成功还是失败, 因此(推测)实例是不会随着函数调用结束而释放掉的, 如果每次都new一个实例, 会占用很多网络链接和内存

8. 不要死循环去发送消息

  如果代码有变更, 就必须重启容器,

  对于PHP这种语言来说, 定时重启脚本会释放已占用的资源

  因此建议不要随机启动常驻进程(docker开机启动), 而是通过定时脚本,或第三方程序自动拉起脚本, 而且脚本内部也支持每分钟就退出一次:

class test {
    public function fu(){
        echo '执行中: '.date('Y-m-d H:i:s').PHP_EOL;
    }
}

$obj = new test;

$minute = date('i');
for ($i=0; $i < 20; $i++) {
    $minute_now = date('i');
    if ($minute != $minute_now) {
        echo '跨分钟: '. date('Y-m-d H:i:s').PHP_EOL;
        exit;
    }

    $obj->fu();

    sleep(5);
}

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值