丢消息

消息队列的丢消息是指生产了一条消息，但是预期中的消费者却没有消费到这条消息。

消息的唯一标识

一般是指消息的唯一 ID，和 OpenTelemetry Traces 中的 Trace ID 是同一个东西。

业界主流消息队列对消息 ID 的实现有两种形式。一种是明确有消息 ID 概念的，一条消息一定会有一个对应的消息 ID，比如 RocketMQ。

另一种没有明确消息 ID 概念的，会用另外的形式来标识这是一条消息。

消息 ID 的生成一般是在客户端 SDK 自动生成或者业务手动生成指定的。

唯一 ID 的生成方式，业界主要有四种。

1. 最简单的就是 UUID，通过各个语言的 UUID 库生成一个唯一的字符串。
2. 集中式的 ID 生成方案，通过某个中央引擎，比如 MySQL 自增列、Redis 自增值、ZooKeeper 自增值等机制保证全局唯一。
3. SnowFlake 算法，通过 Twitter 开源的 SnowFlake 算法生成唯一 ID。
4. 自定义算法：通过自定义的算法生成唯一的 ID。

消息轨迹的设计应该注意什么？

消息轨迹的设计分为三步：记录、存储、查询。记录指在合适的地方记录轨迹信息，比如生产端消息发出的时间。存储指将这些轨迹信息存储到某个引擎中。查询指要能支持消息查询。

消息轨迹的实现方案设计

完整的消息轨迹包含客户端和服务端两个部分。

客户端的轨迹记录一般有两种实现形式。一种是客户端将轨迹数据写入到本地文件，通过第三方组件采集到轨迹系统；另一种是客户端将轨迹数据通过 Broker 提供的 TCP/HTTP 接口，或者通过内置主题的方式，写入到集群中的某个主题中。一般会选择第二种方案，在 SDK 中内置轨迹上报的逻辑，记录轨迹信息并发送到服务端。

正常情况下服务端保存轨迹数据，有四种形式：本地文件、内置 Topic、第三方服务、单机维度的存储引擎。

在小规模集群的运营过程中，将 ES 当做存储引擎是比较常用的方案。在数据非常少的场景中，有时候 MySQL 也可以当作存储引擎。业界的 ClickHouse、HBase 也可以作为存储引擎的备选方案。

此文章为11月Day22学习笔记，内容来源于极客时间《深入拆解消息队列 47 讲》