Q1:消息可靠性(不重不漏)
理解可靠性前。介绍消息语义,即消息传递的标准
标准 |
丢失 |
重复 |
适用场景 |
---|---|---|---|
At most once(至多一次) |
会丢失 |
不会重复 |
高并发高吞吐,允许消息丢失,如日志收集 |
At least once(至少一次) |
不会丢失 |
会重复 |
|
Exactly once(恰好一次) |
不会丢失 |
不会重复 |
1.1 如何保证消息不丢
从各个层面分析
参照:《深入理解kafka-核心设计与实践原理》第8.3章 + 自己理解
层面 |
事项 |
---|---|
生产者(客户端) |
|
Broker服务端 |
服务端需要注意的都是配置参数层面
|
消费者(客户端) |
①自动提交(enable.auto.commit参数) = false:默认为true,自动提交。不再介绍,见3.2.5节
|
1.2 如何保证消息不重
消息重复无法避免,只能在消费者消费时过滤重复消息。可能的重复原因如下:
根因 |
|
---|---|
生产者 |
①业务方代码原因:对同一份消息内容发送了多次 ②网络问题:生产端发送消息后,服务端已经收到消息了,但是假如遇到网络问题,无法获得响应,生产端就无法判断该消息是否成功提交到了 Kafka,而我们一般会配置重试次数,但这样会引发生产端重新发送同一条消息,从而造成消息重复的发送 |
Broker服务端 |
服务端不会重复存储消息,如果有重复消息也应该是由生产端重复发送造成的 |
消费者 |
分区重分配引起
|
备注:分区重分配,与再均衡(rebalance)的区别
- 重分配:作用在broker层面,是broker与partition间的分配;通常是为了管理优化集群手动触发
- 再平衡:作用在消费组层面(新增/下线消费者),Rebalance的目的是确保分区在consumer group成员之间平均分配,以便每个consumer都有分区去消费;通常是Kafka协调器自动触发的
处理思路:幂等
从对系统的影响结果来说:At least once + 幂等消费 = Exactly once。
利用数据库的唯一约束实现幂等
记录消费结果并检查操作
Q2:积压/消费能力
2.1 线上积压排查思路
是什么引起的积压:
先止损,快速定位积压的原因
上游生产流量突增
上游流量没变
不消费了:
消费者是否下线了?
某一个partition的offset卡住了?
还在消费:消费能力下降?
2.2 增加消费能力
搞清原因:什么导致【消费速率 < 生产速率】
生产速率 |
可能原因 |
解决方案 |
备注 |
---|---|---|---|
生产速率不高 |
自身业务消费链路长,导致消费慢 |
优化消费链路 |
绝大多数情况 |
生产速率高 |
①消费者实例 < partition数量。一台机器消费多个partition的情况,并且机器负载较高 |
扩集群机器,一直到【消费者:partition=1:1】 |
影响可控 |
②消费者实例:partition = 1:1,但消费速率仍小于生产速率 |
扩partition。但一未扩partition会增加服务端负载 |
||
③partition本身已很多,但生产速率实在太大 |
增加单partiton并行消费线程数目(这种方式不保证消费顺序!!!)
|
是不是该考虑架构与技术选型的问题了? |
|
④生产速率实在太大了 |
pushServer |