【面试题】消息堆积解决方案

📝作者简介：
大家好，我是CBeann，CSDN博客专家，阿里云专家博主。
22届校招进入阿里广告部门从事Java开发工程师。
平时有空会帮大家解决问题，模式面试和日常答疑，并且提供免费云服务器使用。
有一起卷的可以加我的微信：CHAI956056312，大家一起学习，一起进步。

1、背景

临近双十一了，产品找到开发的同学帮忙把某些广告主的广告投放时间延长两个月并重新送审风控审核，所以开发要订正数据，直接改库并设置广告的标志为是送审风控。此时数据库有大量的送审binlog消息到kafka，从而出现了消息量剧增，下游消费延迟报警。

整个链路的demo如下图所示。

中间件监控如下图所示

2、解决方案

2.1、加机器

一开始以为偶尔出现的一波流量，加一台机器看看。所以整个链路如下图所示。机器总数小于分区总数。

观察了一段时间，发现延迟增长缓慢，说明有效果，如下图所示。但是还是延迟。

2.2、继续加机器

发现上面加机器有效果，继续加机器，如下图中的蓝色pod，此时延迟还是增长，不符合预期。此时我了解到当机器等于分区数时，再加机器没有效果。因此需要提高单台机器的消费能力。

2.3、多线程

提升单台机器的消费能力开多线程。拉取消息的时候批量拉，如下图所示，我拉三条消息，收到消息后抛到线程池（三个线程）中。此时系统消费能力提高三倍。

此时遇到不顺序消费问题，如上图所示，当我的消息需要顺序消费（同userld顺序）时，但是因为我把消息打平了，所以出现了不顺序消费的问题。

2.4、多线程-顺序消费

通过对消息中的业务key（本文中的userid）做路由，如下图中的接收线程中的hash，再路由到固定的线程，从而实现本批次的顺序消费。此处参考了Netty的Reactor模型（加分项）。

• 偏移量什么时候提交？
  本批次全部消费完提交，不论失败与成功。使用CDL。
• 消费失败怎么办？
  记录日志，人工接入。

3、案例拓展

• 大盘监控：完善的监控报警方案，早发现早治疗，别等用户反馈。老板喜欢看大盘。
• 变更通知：操作前一定要周知上下游，包括异步链路。
• 批次灰度：上一批观察一下兄弟团队反馈，没问题推下一批。
• 流量隔离：针对此方案，我们专门搭建了一个消费消费的分组或集群，能实现上述情况出现时不影响正常流量。

一起学习，共同进步👇👇👇