Q1：消息可靠性(不重不漏)
1.1 如何保证消息不丢
1.2 如何保证消息不重
Q2：积压/消费能力
2.1 线上积压排查思路
2.2 增加消费能力
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 |
】)
