22｜可观测性：如何设计实现消息轨迹功能？
许文强
你好，我是文强。
今天我们讲可观测性的第三部分：跟踪（Traces），在消息队列领域，Traces 通常被称为消息轨迹，意思是消息在系统中的运行轨迹。消息轨迹在业务消息方向是刚需，因为业务消息如果出现丢失，大概率会导致流程异常。
比如订单的快递运送流程没有正确处理一条订单号的消息，后续就会出现无法跟踪这个订单派送的问题。如果你负责过消息队列基础服务的日常值班，一定会经常接到用户反馈说消息丢了，想让平台查清楚为什么丢了。这个问题，你会怎么排查呢？
如果想排查清楚，我们首先要搞清楚有没有丢，如果丢了，还要搞清楚是哪一个环节丢的。想弄清楚这两个问题，就必须有消息轨迹的功能。那我们今天就来讲一讲消息轨迹功能怎样设计。
丢消息是怎么回事？
到底什么是“丢消息”？你的第一印象是不是服务端把我的消息弄丢了。其实在消息队列里面，丢消息没这么简单。
从广义上来讲，消息队列的丢消息是指生产了一条消息，但是预期中的消费者却没有消费到这条消息。但是这个过程，不是只有一种服务端弄丢了消息这一个场景。我们结合消息的生命周期，来看看可能有哪些情况。
生产消息失败，生产端把消息写入到服务端时失败了，这时有可能是服务端有异常，也有可能是消息的内容或格式不符合规范，比如太长了。
消息设置了延时属性，消息进入了延时队列后，没有在定义的延时时间内出队列，从而没有在特定的时间执行，错过了消息的有效处理时间，被业务抛弃。
消息在服务端存储完成后，因为服务端一致性算法（强一致、最终一致）的设定问题，或者异步刷盘、服务端重启、消息截断之类的行为，导致持久化的消息丢失了。
一般消息队列的消费模型是根据 Offset 来定位消费位点或者重置消费位置的。如果消费端设置了错误的位点，比如下一条应该消费位点 100 的消息，但消费端因为异常忽略了 100，直接从 101 开始消费。从服务端的角度，100 的消息就没有被消费过，而消费者看来，100 的消费就是没被消费到，此时从消费端的视角，消息就是丢失了。
当消费端拉到消息后，如果业务处理有异常，经过了多次处理后依旧失败，消息进入了死信队列，除非业务配置了订阅消费死信队列的消息，否则这条消息的生命周期就算结束了。此时消费端还是没有消费到消息，消息可以算丢失了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了消息轨迹功能的设计与实现，针对业务消息丢失可能导致的流程异常问题，提出了多种情况下的消息丢失原因，并讨论了消息的唯一标识生成方式。在设计消息轨迹时，强调了需要注意的三个步骤：记录、存储、查询，并对客户端轨迹数据记录和服务端轨迹数据记录进行了详细分析。此外，还就持久存储引擎的选择提出了建议，强调了在大规模集群运营中，需要在功能、性能、稳定性、成本之间取得平衡。 文章还分享了RabbitMQ消息轨迹的具体方案设计，包括存储引擎选择、客户端和服务端轨迹记录、轨迹数据存储和查询等步骤。另外，还介绍了在大规模集群中极限降低成本的实际案例，以及在不同规模集群中存储引擎选择的建议。 总结指出，消息轨迹记录了消息从生产到消费完成或消费失败的整个生命周期，对于定位消息丢失问题非常重要。在小规模集群中，常用的存储引擎是ES，而在大规模集群中，需要综合考虑功能、性能和成本，选择合适的方案。最后，提出了一个思考题，引发读者对于消息轨迹方案设计的深入思考。 整体而言，本文内容丰富，涵盖了技术实现细节和业务应用场景，对于消息轨迹功能的设计与实现提供了有益的技术指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入拆解消息队列 47 讲》，新⼈⾸单¥59
《深入拆解消息队列 47 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
fjr老师您好，kafka是如何实现消息轨迹得，现在单条消息得回溯比较麻烦，需要将生产端，broker，消费端各端得信息聚合在一起，这个业内有实现得案例可以分享么2023-09-13归属地：浙江
收起评论
