实际工作中kafka的应用和遇到的问题

应用场景

我们写接口给第三方调用，举个简单的比如批量发送短信接口，第三方一次性推送一千个号码，难道我们等发送完所有短信，才会给出接口响应吗，显然是不可能的，这个时候我们就可以用异步的思路，直接把消息推送发kafka，推送kafka成功，则直接给出接口相应

看着一个简单的表单提交，可能后面生成的数据有很多，举个简答的例子，我们申请一个支付宝账号，当我们提交成功后，可能后台会生成当前用户的基本信息之外，还需要生成蚂蚁森林，关联该用户的信誉分等等一些不是很关键的信息，如果这些一大串信息同步去生成，相应可能达到秒级，影响用户体验，这是我们就可以用到异步的思路，提交表单，我们只生成用户主信息，然后将生成的主信息id，推送到kafka，剩下的一些无关信息则通过kafka异步生成，这是用户是无感知的，页面相应毫秒级，体验也会很好

系统之间信息的交互，可以通过接口，也可以通过kafka，但是推送消息的一方要多接很对厂商，这时候用接口的方式就显得很局限了，这时候用kafka就非常合适了，因为第一kafka消息不会丢失，第二消息推送方只需要将消息推送到topic，消费者只需要连接到推送方的kafka，消费同一个topic推送的消息，这样推送方只管推，接收方只管消费，极大的降低的开发量，也起到了解耦的作用

遇到的问题
问题一：推消息可能重复推送，但是消费者并没有做重复校验
背景
状态通知这类一般都是异步通知，如果由于接口超时导致通知失败，我们会有三次的补推机制，补推机制时间间隔很短的话，就有可能同一条消息，往kafka推送多条消息
解决方案：
可以用redis的过期机制，消息推送进来，第一步就是设置一个唯一的由topic名称拼接消息消息id的redis的incr自增，设置过期时间5分钟，校验如果redis值大于1，则不消费，返回该消息正在消费，防止一条消息重复消费

问题二：kafka多分区的情况下怎么保证消息是有序的
背景
一个订单的订单状态通知给第三方，对方必须我们传状态由顺序的传递，开始状态-》中间状态-》结束状态，我们必须按照顺序通知，如果没有按照顺序则不合规
解决方案：
在生产者发送消息时，通过指定Partition Key（如用户ID），Kafka会根据Key进行哈希计算，将具有相同Key的消息分配到同一个分区中。这样，即使Topic有多个分区，具有相同Key的消息也会被放入同一个分区，从而保证了这些消息在分区内是有序的
或者人为代码控制，一个订单必须查到开始状态通知成功，才会消费通知中间状态，必须查到中间状态通知成功，才会消费通知结束状态

问题三：消息堵塞怎么处理，之前一个topic偏移量达到过200w+
背景
这个是之前写代码没过细产生的问题，定时任务查符合条件的数据，推送kafka异步通知，kafka实现类逻辑有点多，需要调用的接口也很多，本来消费的就很慢，消费完成还没有改状态，导致定时任务可以一直往kafka里推数据，推了两天kafka三个分区每个分区堵塞进70w的数据
解决方案：
刚开始把定时关了，观察kafka消费的速度发现很慢，全部消费完要很久，这样就把后面的消息全堵了，考虑到这些消息都是重复消息，比如一个相同的订单，kafka里面有几百条被堵的，都是一些垃圾数据，就些数据就不消费了，直接释放掉算了，但是运维又觉得清数据是风险操作，不敢直接把分区的消息直接清掉，后面改了下代码，监听topic的listener改成多线程，并且让他匹配不到实现类，这样堵塞的消息，10分钟就跑完了，清完消息之后就又调整回去了，真是影响深刻