架构设计消息篇之保证消息顺序性

前言

上一篇文章我们讨论了消息中间件如何保证消息不丢失
这篇文章我们讨论一下使用消息中间件Kafka时,如何保证消息的顺序性。
一般情况我们不太需要保证消息的顺序性,但在某些对顺序要求极其严格的场景下,需要保证消息的顺序性。
比如,将Mysql主库中的数据通过BinLog同步到从库,如果一条Update和另一条Delete语句颠倒,那么势必导致主库和从库中的数据不一致。

问题

avatar

上图是一张简单的Kafka消息生产与消费模型图,左边是生产者,它有一个待发送的消息队列,队列中的消息同属一个Topic并且是按编号排好序的;
当Topic中的消息被发往Broker时,首先会根据消息的Key对消息进行分区,然后才将消息发送到对应的分区中,也就是图中的中间部分;
消息到达各自的分区后,我们可以发现:消息在Broker中的存储顺序和在队列中的原始顺序不一致了;
不仅分区后,会出现不一致,即使不分区即只有一个Partition的时候,也可能因为重试导致不一致。
比如,msg5和msg6,先发msg5后发msg6,结果msg6发送成功msg5发送失败,之后重试msg5成功,这样在同一个分区中msg5就排到了msg6后面。
假设,我们可以保证消息的存储顺序和原始顺序一致,也无法绝对保证消费者一定是按存储顺序消费。
比如说,一个消费者开启了多线程进行消费,那么并行地消费就会导致消费乱序。

因此,我们可以发现消息的消费顺序与如何分区、如何重试、以及是否存在多个消费者同时消费有关。

方案

上面我们已经分析了Kafka中和消息顺序性有关的几个因素,接下来我们看看如何通过配置确保消息全局有序和分区有序。

全局有序

全局有序是指消费顺序完全与消息在应用程序中的原始顺序一致。
要实现全局有序,首先我们要将Topic的分区数量配置成1即不分区,其次将这个配置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION的值设置成1,最后保证一个Group中只有一个线程在消费这个Topic。
MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION表示的是每个连接最多能缓存多少个未响应的请求,默认为5,如果要保障消息全局有序该参数需要设置成1。

分区有序

分区有序是指消费顺序与分区的存储顺序一致。实现分区一致比较简单,只需要配置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION的参数值为1即可,这样就能避免因重试导致的分区乱序。

总结

消息的顺序性和分区、重试、多线程消费有关,还有一个注意点是在生产端,如果采用多线程来发送消息,那肯定是无法保证消息顺序性的。

扩展阅读

架构设计思维篇之结构

架构设计思维篇之概念

架构设计容错篇之重试

架构设计容错篇之熔断

架构设计容错篇之限流

架构设计事务篇之Mysql事务原理

架构设计事务篇之CAP定理

架构设计事务篇之分布式事务

架构设计消息篇之消息丢失

架构设计消息篇之保证消息顺序性

推荐阅读更多精彩内容