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

前言

上一篇文章我们讨论了消息中间件如何保证消息不丢失。
这篇文章我们讨论一下使用消息中间件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定理

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

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

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