网站后台管理系统很慢优化人员配置

一、哪些场景需要消息保序？

• 消息保序问题指的是，在通过消息中间件传递消息过程中，我们希望消费者收到消息的顺序，和发送者发送消息的顺序保持一致。或者说，消息中间件在传递消息时，不要改变消息之间的顺序。
• 过在工程实践中，我们面临的保序问题不一定只是局限在消息保序这一个环节，更常见的场景是，事件经过包含消息队列等多个环节的处理和传递后，在某个服务内能够按照事件发生的顺序来逐个处理这些事件，不发生乱序。比如：
  （1）、在证券、股票交易撮合场景中，对于出价相同的交易单，需要坚持按照先出价先交易的原则，下游处理订单的系统需要严格按照出价顺序来处理订单。
  （2）、在数据库变更增量同步场景中，上游源端数据库按需执行增删改操作，将 BINLOG 作为消息，通过消息队列传输到下游系统，下游系统按顺序还原消息数据，实现状态数据有序更新。
  （3）、在电商系统中，订单创建、支付、退款、物流等消息需要按照顺序处理，才能保证订单状态的正确更新。

二、如何实现消息保序？

• 有些消息队列其设计就是基于队列来实现的，比如 RabbitMQ。

• 我们知道队列的特性就是先进先出，天然就是有序的，使用这种“基于队列来实现的消息队列”传递消息，自然就可以实现消息保序。

• 但是为了实现高吞吐，更多的消息队列在设计上采用的是多分区或多队列的实现，比如 Kafka 或 RocketMQ 。这些消息队列在处理消息时，会将消息按照一定的策略分发到多个分区上并行处理，也就无法保证消息的有序性了。

  如果我们希望在多分区的消息队列上实现消息保序，可以将分区数量配置为 1，这样就可以实现和单队列消息中间件一样的保序效果了。

• 此外，为了保证在消费者端消息的有序性，消费者也只能单实例单线程来消费消息，才能保证全流程消息是严格有序的。

• 以上就是全局消息保序的实现方法，这种方法的实现思路其实就是全局串行处理。我们知道，串行处理有一个很大的弊端，那就是消息吞吐量有限，也没法通过水平扩展来提升消息吞吐量。在规模比较大的场景下就显得力不从心了。

• 我们会发现，大多数需要消息保序的场景并不需要消息“全局有序”。多数场景下，我们只需要保证有业务关系的消息之间的顺序就可以了，没有业务关系的消息之间的先后顺序，其实是无所谓的。

• 只有数据库 BINLOG 同步这个场景，因为数据库事务的存在，我们没有办法把 BINLOG 归并到数据库表上，也就无法判断 BINLOG 消息的关联性，这种情况下必须实现全局保序，才能保证数据同步的正确性。

  将保序要求从全局放宽到局部，就可以充分利用多分区消息队列的并发能力来提升消息吞吐量了。

• 实现的思路是这样的，既然我们只需要保证有关联的消息之间的顺序，那么只要把关联的消息都发送给同一个分区处理，而分区内天然就可以保证消息的处理顺序，这样就实现了消息局部保序。下面举个例子来说明。

• 比如，我们用一个 4 分区的主题来处理订单消息。可以采用哈希算法将订单消息按照订单号的后两位均匀地分配到 4 个分区上。

• 也就是，将订单尾号 00-24 的订单发给 0 号分区，25-49 尾号的订单分给 1 号分区，50-74 尾号的订单发给 2 号分区，剩余的发给 3 号分区。这样就可以保证同一个订单的消息总是分配相同的分区，也就实现了订单内消息保序。

• 多数消息中间件都内置了相应的功能来帮助我们快速实现局部消息保序。

• 以 Kafka 为例，Kafka 的 API 支持在发送消息的时候指定一个消息的 Key，并且内置了默认的哈希算法将 Key 映射到主题的分区上，保证具有相同 Key 的消息总是会被发送到同一分区，从而实现了消息局部保序。在上面例子中，可以直接使用订单号作为消息的 Key，示例代码如下：

  // 订单消息
  OrderMessage orderMessage = createOrderMessage(...);
  // 订单号，作为Key
  String orderId = orderMessage.getOrderId();