Kafka顺序消费以及消息积压问题_kafka 消费积压

一：顺序消费

什么场景下需要顺序消费？
比如说：订单有很多状态，比如：下单（未支付）、完成（已支付）、撤销等，不可能下单的消息都没读取到，就先读取支付或撤销的消息吧，要保证消息顺序消费

如何保证顺序消费？
kafka的topic是无序的，但是一个topic包含多个partition，每个partition内部是有序的

只要保证生产者写消息时，按照一定的规则写到同一个partition，不同的消费者读不同的partition的消息，就能保证生产和消费者消息的顺序。

路由字段的选择：首先考虑消息消费依赖的字段，订单有很多状态，消费消息是根据不同订单状态来做消费逻辑的，可以以订单ID为路由字段，这样同一个订单就会路由到同一个topic的partition下，这个partition内的消息是有序的，每个partion再由一个消费者消费 。

2. 消息积压

导致消息积压的可能情况是很多的，要根据具体的业务来看，大致思路如下：

• 首先看一下topic下积压的情况，是全部partion积压？还是某几个partion积压，如果单个partion积压，那是不是消费该partion的消费者挂了，或者说是不是路由的字段不合理，导致都路由到这个分区了，那如果路由合理消费者也正常，是不是该分区的零时积压，零时积压消费端可以开更多的线程加快处理。

• 如果是全部partion都积压，那是不是消息体太大了，优化消息体只保留必要的字段，如果消费者这边需要用到其他更加详细的消息可以提供接口来查询；如果消息体设计合理但是全部partion都积压了，以订单来说，是不是上游服务批量的更新了字段导致下游服务收到了大量的消息，造成了所有partition的消息积压 ，直接加节点肯定是不行的，因为kafka允许一个消费者消费多个partion，但是不允许一个partion被多个消费者消费，这样做也是为了避免资源的浪费，这种情况下，可以对消费者开更多的线程处理，这种情况需要和其他的下游服务做沟通协调，因为可能自身会用到下游服务，比如说消费消息的逻辑里面包括查询下游接口信息，协调是避免对下游服务造成冲击，让下游服务提前加服务节点。