云能扛起IBM这家百年老店吗？

如上图所示，每个Order事件消息都将orderId作为其分片键。特定订单的每个事件都发布到同一个分片。而且该分片中的消息始终由同一个接收方实例读取，因此这样就能够保证按顺序处理这些消息。

处理重复消息

引入消息架构必须要解决的另一个挑战是处理重复消息。在理想情况下，消息代理应该只传递一次消息，但保证消息有且仅有一次的消息传递的成本通常很高。相反，很多消息组件承诺至少保证成功传递一次消息。

在正常情况下，消息组件只会传递一次消息。但是当客户端、网络或消息组件故障可能导致消息被多次传递。假设客户端在处理消息后发送确认消息前，他的数据库崩溃了，这时消息组件将再次发送未确认的消息，在数据库重新启动时向该客户端发送。

处理重复消息有以下两种不同的方法：

• 编写幂等消息处理程序
• 跟踪消息并丢弃重复项
• 编写幂等消息处理器

如果应用程序处理消息的逻辑是满足幂等的，那么重复消息就是无害的。程序的幂等性是指，即使这个应用被相同输入参数多次重复调用时，也不会产生额外的效果。例如：取消一个已经取消的订单，就是一个幂等性操作。同样，创建一个已经存在的订单操作也必是这样。满足幂等的消息处理程序可以被放心的执行多次，只要消息组件在传递消息时保持相同的消息顺序。

但是不幸的是，应用程序通常不是幂等的。或者你现在正在使用的消息组件在重新传递消息时不会保留排序。重复或无序消息可能会导致错误。在这种情况下，你需要编写跟踪消息并丢弃重复消息的消息处理程序。

跟踪消息并丢弃重复消息

考虑一个授权消费者信用卡的消息处理程序。它必须为每个订单仅执行一次信用卡授权操作。这段应用程序每次调用时都会产生不同的效果。如果重复消息导致消息处理程序多次执行该逻辑，则应用程序的行为将不正确。执行此类应用程序逻辑的消息处理程序必须通过检测和丢弃重复消息而让它成为幂等的。

一个简单的解决方案是消息接收方使用 message id 跟踪他已处理的消息并丢弃任何重复项。例如，在数据库表中存储它消费的每条消息的 message id。
 

概述

在微服务开发中我们经常会引入消息中间件实现业务解耦，执行异步操作， 现在让我们来看看使用消息中间件的好处和弊端。

首先需要肯定是使用消息组件有很多好处，其中最核心的三个是：解耦、异步、削峰。

• 解耦 ：客户端只要讲请求发送给特定的通道即可，不需要感知接收请求实例的情况。
• 异步 ：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。
• 削峰 ：消息中间件在消息被消费之前一直缓存消息，消息处理端可以按照自己处理的并发量从消息队列中慢慢处理消息，不会一瞬间压垮业务。

当然消息中间件并不是银弹，引入消息机制后也会有如下一些弊端：

• 潜在的性能瓶颈 ：消息代理可能会存在性能瓶颈。幸运的是目前主流的消息中间件都支持高度的横向扩展。
• 潜在的单点故障 ：消息代理的高可用性至关重要，否则系统整体的可靠性将受到影响，幸运的是大多数消息中间件都是高可用的。
• 额外的操作复杂性 ：消息系统是一个必须独立安装、配置和运维的系统组件，增加了运维的复杂度。

这些弊端我们借助消息中间件本身提供的扩展、高可用能力可以解决，但是要真正用好消息中间件我们还需要关注可能会遇到的一些设计难题。

处理并发和顺序消息

在生产环境中为了提高消息处理的能力以及应用程序的吞吐量，一般会将消费者部署多个实例节点。那么带来的挑战就是 如何确保每个消息只被处理一次，并且是按照他们的发送顺序来处理的。

例如：假设有3个相同的接收方实例从同一个点对点通道读取消息，发送方按顺序发布了 Order Created 、 Order Updated 和 Order Cancelled 这3个事件消息。简单的消息实现可能就会同事讲每个消息给不同的接收方。若由于网络问题导致延迟，消息可能没有按照他们发出时的顺序被处理，这将导致奇怪的行为，服务实例可能在另一个服务器处理 Order Created 消息之前处理 Order Cancelled 消息。

Kafka 使用的解决方案是使用分片(分区)通道。整体解决方案分为三个部分：

• 一个主题通道由多个分片组成，每个分片的行为类似一个通道。
• 发送方在消息头部指定分片键如orderId，Kafka使用分片键将消息分配给特定的分片。
• 将接收方的多个实例组合在一起，并将他们视为相同的逻辑接收方(消费者组)。kafka将每个分片分配给单个接收器，它在接收方启动和关闭时重新分配分片。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!