设计消息中间件时我关心什么?(解密电商数据一致性与完整性实现,(3)

辅助工具

消息的发送投递轨迹可视化,消息回溯、消息补发等等.发一条消息过来,这条消息什么时候接收到?什么时候进行投递,投递到哪些消费者是要有可视化,这样便于用户查找问题.

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

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

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

监控

监控分为两块.一个是指标监控,比如像 QPS 监控,耗时等.可以细化到 subject、consumer 等粒度.第二个是链路监控、全链路跟踪,这是另外一个产品 QTracer 做的,可以根据消息 id 来查这个消息所关联的链路,来看看这个消息的情况.

Consumer 消费端设计

上下线控制

上下线的策略,如果消费端应用还没有启动成功的时候,消息就已经过来,这是不能接受的.我们使用了一个和 nginx 差不多的方法,利用一个 healthcheck.html,如果有这个文件,就把消费者上线.发布系统将应用发布之后,会检查应用是否 ready,ready 之后就会 touch 一下这个文件,然后 consumer 就上线了.另外就是可以手动屏蔽消费端,比如一个消费组有多台机器,可以屏蔽其中几台.

幂等

幂等分两种实现.有的业务是可以处理幂等的,借助消息里的业务字段然后根据业务场景.但有的业务可能不太好实现幂等,我们的客户单默认提供了幂等的措施,比如基于 Redis、MySQL 等.

关于顺序

消息中间件是不严格保证顺序的,只是尽量保证有序,一般情况下先发送的消息先到,但并不做出这种承诺.要保证顺序对实现方式和成本都是不小的挑战.

使用方一般怎么来保证顺序呢?

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

另外一种方法是 producer 在消息里面携带一个版本号.Consumer 收到以后会和自己当前的版本号进行比较,接到消息的版本号如果小于数据库的版本号,这个消息就不消费了,直接吞掉,这里要注意,这样的消息就不是拒绝了.

Q & A

Q：消息入库本地库,后台应用扫描数据库重发消息,会不会导致消息重发?

余昭辉：有几层保证.首先,消息一旦发送成功,就把消息给删除了.而后台应用扫描也是扫描指定时间之前的消息,但这可能还是不能完全杜绝重发,比如在删除之前,被扫描到了,就会导致这个问题.我们在 server 端会根据消息的 id 进行一个去重,不过去重也是有个限制的,也就是只保证多长时间内的消息不重复,而不是永久.如果有的业务觉得这还不够,就要自己去实现幂等了.

Q：看你们实现了跨机房,如果中间件在两个机房,其中一个机房出问题,会不会有影响,机房做容灾?

余昭辉：这个是没做的,如果一个机房出现不可恢复的故障,需要人工进行恢复.消息收到之后,首先落本地库,还会保存一份到 HBase.你刚才说机房宕掉的,那些存储把消息恢复回来,没有做自动容灾.

Q：幂等需要业务上做本地支持?

余昭辉：对.如果业务完全不能接受重复消息,就必须实现幂等.

Q：消息队列是基于 Kafka 吗?如果自研底层是怎么样实现的

余昭辉：这块是自己研发实现的,消息存储直接用 MySQL,开发语言用 Java,去哪儿网主流的语言就是 Java,公司里其他语言很少.关于存储的分区,因为模型非常简单,分区就是用消息的 id,hash 进行分区.

Q：broker 做服务中心,如果 broker 重启,消息持久化的情况怎么处理??

余昭辉：brocker 进行重启,先参看最开始的那个模型.消息发到 broker,broker 如果回成功了,说明消息一定落地了,只有落地成功了,broker 才会回成功.返回成功,producer 就可以把本地消息删除掉.如果你发一条消息正好碰到服务重启,存储没落地,broker 肯定不会回消息,消息就在本地库里面,稍后,后台应用又会把消息扫出来重发.

Q：从第一版到现在有没有对架构方面的考量或者重新调整设计??

余昭辉：架构上面变动不多,主要是里面细节在不断调整.比如说最初的时候,网络这一块直接用的是一个 RPC 框架,没有自己实现网络传输.在 2013 年,碰到一些问题,因此又把网络这块完全重写了.比如上文提到队列隔离调度的地方,也是重新设计了.

本文相关 PPT 链接如下

http://pan.baidu.com/s/1eRMW4zK

文章出处：高可用架构

（编辑：ASP站长网）