交易环节消息中间件设计——去哪儿余昭辉

╰半夏微凉° 2022-04-22 03:08 158阅读 0赞

# 交易环节消息中间件 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70]

## 问题考虑 ##

**不能丢消息**  
丢消息意味着掉单，意味着支付成功但是没给人家出票，这是不能接受的。

**稳定**  
消息中间件一旦出问题，交易不能进行，也是严重的故障。

**性能**

典型的消息中间件包含 3 部分  
producer（发布者）、broker（消息中间件）、consumer（消费者），是一个比较简单的模型，下图展示了把消息发送给 consumer 的全过程。

## Producer 发布端设计 ##

一致性、容灾、性能

### 分布式事务一致性 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 1]  
上图是一个订票的订单服务，生成的新订单。  
如果订单持久化成功（上面的红框 ），消息发送失败（ 下面的红框 ）。那么用户看到下单成功，假设代理商服务订阅这个消息是否给用户出票，那么现在的情况就是票没出来，这会引起用户投诉。  
但是如果先发消息，然后再持久化订单，那可能就是订单出票了，但其实这个订单还没下呢，这就会造成公司的损失。

**解决方法一**：

多个库的操作是可以放在同一个事务里

1.  开启事务。
2.  业务操作，比如说订单进行持久化等等动作。
3.  生成消息，并持久化，这和业务操作是在同一个事务里。
4.  事务提交。

消息真正发到出去。消息如果发送成功了，会将消息表里的消息删除，而此时如果消息发送失败了，后台有一个任务会把消息表里面发送失败的消息重新进行发送，这样最终达到一致性，保证业务操作成功了，消息一定能发出去。

**缺点**  
存储成本。本来只有业务操作访问 DB，然后还要持久化消息。原来承受一个 QPS 现在可能只能承受一半了，所以对数据库操作还是略重一些

调用了 RPC。这样的动作是不能放在一个数据库事务里的，所以对于这种场景就不能满足了

**解决方法二**

1.发新的消息，直接发给 broker，这个消息发给 broker 并不立即将消息投递出去。  
做本地的操作

2.再调broker的接口，这一步真正把消息发送出去。  
如果这个时候，即使第一步操作成功，第二步发送失败了，第一步发送给 broker 的消息就是一个未决状态。

3.broker反过来询问producer，那条消息是发还是不发出去呢？这种模型就不需要一个将一个消息库放在业务库同实例了，比较灵活，成本也更低些。但是业务使用的复杂度可能要高一些，需要提供一个接口供 broker 反查。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 2]

### 容错 ###

broker 会有不同的集群，producer 发消息有一个优先级，默认消息优先发到本机房集群，本机房宕掉或者其他什么原因不可用再向别的机房进行发送。

### 隔离 ###

Broker 消息中间件设计

消息中间件要支持非常多的 subject，全公司都在使用消息中间件，各业务开发水平也参差不齐，如果有的系统弄了一个死循环，疯狂的发消息就会给系统带来不可控的压力，所以中间层需要做好隔离。其次，业务使用消息中间件可能会遇到各种各样的问题，需要辅助工具进行诊断。最后还需要全面的监控能力。

**actor** 这种模型，系统里可以跑成千上万的 actor，它肯定也有一个调度器，最后就模仿 akka 的调度器，它叫 dispatcher，实现了调度的策略。

### 可治理 ###

如果这个时候消息中间件出问题了，我们就可以根据上线时可靠级别给有的消息降级。

降级也有很多种策略，比如

1.仅仅给投递一次，如果中间件出问题，这种消息就投递一次算了，不管你是否消费成功，都不给你重发。  
2.还有重发次数，比如有的消费者那边有问题，消费不成功，比如消费格式变了，重发一天也消费不了，就可以实时的去调整消息的重发次数。  
3. 还有可以按多少比例给它发消息，比如说 50%，那么 50% 的消息就给抛弃。  
4. 日志降级

比如订单支付的消息级别是最高的，但是搜索，比如说现在有报价，代理商帮旗下所有的酒店价格变了一下，关心它的系统就要受到价格的更新，这是通过消息广播出去的。这个消息，它的变动是比较频繁，QPS 也很高，丢了一两条消息，可能又被后面的消息覆盖了，它的可靠级别就比订单的级别要低，这个时候遇到问题，为了保护订单消息，肯定首先对它进行降级。

### 辅助工具 ###

消息的发送投递轨迹**可视化**

消息回溯。  
比如消费者把消息的内容理解错了，几号到几号之间所有的消息都要进行重新发送，这样就要回溯这段时间的消息。

**消息补发**。  
漏发的消息，把消息重新补发一下，用户可以上传一个文件，将这些文件里的内容解析成消息然后发送。

显示消息的发送和消费的关系。  
系统发出了哪些 topic 的消息，系统订阅了哪些 topic 的消息，有哪些消费有哪些订阅了，这些都非常重要。

### 监控 ###

监控分为两块。  
一个是**指标监控**，比如像 QPS 监控，耗时等。可以细化到 subject、consumer 等粒度。

第二个是**链路监控、全链路跟踪**，这是另外一个产品 QTracer 做的，可以根据消息 id 来查这个消息所关联的链路，来看看这个消息的情况。

## Consumer 消费端设计 ##

## 上下线控制 ##

## 幂等 ##

## 关于顺序 ##

顺序消息的实现

一种是**状态机**。

涉及交易的系统一般都有状态机。比如订单流转，假设现在订单状态是待支付，业务收到支付成功的消息，订单就流转成支付成功，这个时候收到了订单完成或者出票成功这样的消息，这个消息不是对应的当前状态，都会进行拒绝，拒绝后消息的 server 稍后会重发。

另外一种方法是 producer 在消息里面**携带一个版本号**

Consumer收到以后会和自己当前的版本号进行比较，接到消息的版本号如果小于数据库的版本号，这个消息就不消费了，直接吞掉，这里要注意，这样的消息就不是拒绝了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70]: /images/20220422/d21445abeb0c4fc9b5b7f746310d35a8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 1]: /images/20220422/ad821aba66e44c46908739c1d21479a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01lbWVyeV9sYXN0_size_16_color_FFFFFF_t_70 2]: /images/20220422/561d0235e2244c6880d574f5db97183e.png