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

Posted 2023-04-26

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

上图是一张简单的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定理

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

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

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

如何保证消息的顺序性

1、面试官心里分析

其实这个也是用MQ的时候必问的话题，第一看看你了解不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这个生产系统中常见的问题。

2、面试题剖析

我举个例子，我们以前做过一个mysql binlog同步的系统，压力还是非常大的，日同步数据要达到上亿。mysql -> mysql，常见的一点在于说大数据team，就需要同步一个mysql库过来，对公司的业务系统的数据做各种复杂的操作。

你在mysql里增删改一条数据，对应出来了增删改3条binlog，接着这三条binlog发送到MQ里面，到消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。

本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。

先看看顺序会错乱的俩场景：

（1）rabbitmq：一个queue，多个consumer，这不明显乱了

 图解：

（2）kafka：一个topic，一个partition，一个consumer，内部多线程，这不也明显乱了

那如何保证消息的顺序性呢？简单简单：

（1）rabbitmq：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。

（2）kafka：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可