TongHTP集群部署及总结

peach桃

于 2024-06-05 14:57:44 发布

阅读量688

点赞数 30

分类专栏：消息中间件文章标签：国产化消息队列MQ TongHTP

本文链接：https://blog.csdn.net/peach_garden/article/details/139471805

版权

消息中间件专栏收录该内容

2 篇文章 0 订阅

订阅专栏

之前在项目中因为国产化要求适配，适配国产消息中间件TongHTP，在过程中学习了其一些设计和术语，适配完成后，进行简单的总结了一些需要关注的东西，在有需要的时候可以查阅，包括了多种安装部署，角色交互等

一：概述

TongHTP V2.0是面向分布式应用的高速传输平台，主要功能是在应用程序之间进行实时、高效和可靠地传递消息，使得消息可以在不同的网络协议、不同的计算机系统和不同的应用软件之间进行网络传输。系统支持IPV4协议，TCP协议以及UDP协议。

TongHTP应用程序可灵活地运行在多平台的多节点上。当应用程序之间要传送消息时，应用程序只需将消息目的地、消息的属性和内容以及消息的控制信息通过API接口传递给TongHTP，TongHTP会根据应用提供的信息对消息进行处理，并且利用TongHTP节点组成的虚拟网，将消息传送到消息接收者所在的节点上，最后提交给消息的接收者。

TongHTP V2.0具有如下优点：

1. 提供亿级消息堆积能力

2. 提供低时延的接入传输服务

3. 提供百万级业务并发传输能力

4. 保证数据传输的高可靠性

5. 多种安全防护策略保证业务数据的安全性

6. 支持灵活多变的网络部署模式，方便用户在不同的业务场景下使用

二：整体架构

TongHTP整体架构由客户端（client）、服务端、管理控制台（web）三部分组成，服务端又分为管理节点（namesvr）和工作节点（broker）。产品整体架构如下图所示：

说明：

⚫ 客户端 C 接口提供动态库支持，JAVA 接口提供 jar 包支持。

⚫ TongHTP 的 JAVA 客户端由纯 JAVA 语言编制而成，可以直接跟服务端通信，暂不支持 JMS 规范。

⚫ TongHTP 目前只支持本地存储，工作节点接收到消息存放在本地文件系统，如使用网盘设备进行消息的持久保存，可靠性相对较低，目前暂无计划支持。

⚫ 使用 JAVA 客户端要求 JDK 8 及以上版本。

三：基本概念

3.1 管理节点（Nameserver）

管理节点提供服务注册、服务发现、对集群中各工作节点的运行状态和负载情况的监控、集中存储集群状态信息、统一管理集群工作节点配置、服务负载均衡以及连接安全、日志和本地进程监控(以下简称namesvr)。

管理节点的功能设计包括监控管理子系统、安全保障子系统、数据存储子系统、名字服务管理子系统、集群调度子系统、远程管理子系统。

3.2 工作节点（Broker）

工作节点提供消息传输和转发、消息存储、消息消费、消息事件生成、发送队列管理、节点运行信息上报管理节点以及动态配置更新、日志和本地进程监控(以下简称Broker)。

工作节点的功能设计包括数据传输子系统、数据存储子系统、消息处理子系统、监控管理子系统。

3.3 客户端节点（Client）

TongHTP客户端提供对多种开发工具和开发环境的支持，提供C、Java方式的接口，方便应用程序的开发。

应用程序可以通过调用这些接口实现消息的传递、系统管理等功能，应用程序只需要关心业务处理逻辑，而不必关心复杂的底层网络传输。应用程序可以和TongHTP服务端工作节点、管理节点部署在同一台机器上，也可以部署在不同的机器上。

3.4 通信域（Domain）

TongHTP客户端采用通信域+主题模式来唯一确定某一业务标识。通信域用作资源隔离，同一通信域下，主题是唯一的；同一主题下，通信域不是唯一，可以是多个并且通信域可以为空。在同一通信域下，主题不能重名；不同通信域的主题可以重名,但互不影响。通信域与主题的具体设置是由客户自己规划与设置(以下简称Domain)。

3.5 主题（Topic）

TongHTP客户端是采用围绕主题模式来进行业务区分和开展通讯的，各个通信模块可以配置相应的主题进行发布，订阅者可以根据主题进行订阅。

3.6 消息（Message）

“消息”是在应用进程之间或一个应用的不同部分之间交换的数据单位，应用可分布在多台相同或不同的平台上，也可分布在一台计算机上。消息可非常简单，例如只包含文本字符串；也可更复杂，包含嵌入对象或者一个文件。

TongHTP的消息分为两部分：

⚫ 应用数据：应用数据的内容和结构由用户程序来定义。

⚫ 消息描述：消息描述给出消息的特定属性，包含消息类型、优先级、持久性、延迟性等。

3.7 生产者（Producer）

消息的提供者。生产者通过指定管理节点IP地址和端口服务、客户端标识、通信域属性、主题这些要素，组织要传递的消息内容，把该消息发送到生产者要传送的目的地。

3.8 消费者（Consumer）

消息的消费者。消费者通过指定管理节点IP地址和端口服务、客户端标识、通信域属性、主题这些要素进行消息消费。

3.9 发布订阅（Pub-Sub）

发布订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者）。而是将发布的消息分为不同的类别，无需了解哪些订阅者可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者存在。

发布者/订阅者应用模式支持向一个特定的消息主题生产消息。多个订阅者可能对接收来自特定消息主题的消息感兴趣。每条消息可以有多个订阅者；订阅者只有订阅后才能接收到消息。

1. 消息发布者数据流向：发布者携带主题消息发布到TongHTP集群节点

2. 消息订阅者数据流向：订阅者向TongHTP集群节点订阅已发布的主题消息

3.10 本地发布

消息发布者可以指定本地发布模式，当指定发布模式为本地发布模式后，根据主题获取的broker节点只会返回一个broker节点，发布者会把消息推送到这个节点上。

3.11 本地订阅

消费者在订阅主题消息时可以指定本地订阅，当消费者指定本地订阅模式后，主题对应的broker节点只会返回本地节点，消费者只会从本地节点订阅消息。

3.12 消息回溯

对于已经消费成功的消息或者消费失败的消息，需要支持该信息在一定的时间段内的存储，等待某一时间内该消息会被重新消费的可能。

基于偏移量回溯消息：对于已经消费成功或者消费失败的消息可以根据消息具体的偏移量进行消息的重新消费。

3.13 偏移量回溯

消息发布到broker中同一个topic下对应的队列的序号(从0开始)。

3.14 点对点消息传输(Point-To-Point)

客户端到工作节点的消息传输通过队列交互。客户端生产者负责将消息通过队列名传送给工作节点，工作节点经发送连接发送消息到已建立连接的工作节点的队列，客户端消费者负责从工作节点通过队列名去消费消息。

四：系统部署模式

4.1 单机模式

多个客户端与一个服务端之间进行消息传输，服务端由一个管理节点和一个工作节点组成，客户端一般为信息源，采集业务数据后发送到主题或队列，进行单工作节点的发布订阅和本地队列操作。

4.2 集群模式

集群模式解决了单工作节点在大压力下无法满足消息高效处理的需求。通过服务端工作节点集群（一个管理节点，多个工作节点），将消息处理压力均衡到多个工作节点上，由多个工作节点共同完成。

4.3 跨集群传输模式

跨集群传输模式可以解决两个不同集群之间的消息传输。适用于如下场景：

⚫ 例如企业应用中，分公司之间、或者子公司与母公司之间进行数据交换；

⚫ 例如政府项目中，不同部委之间的数据交换；

⚫ 例如银行项目中，商业银行与人民银行之间的数据交换。

五：基本功能

5.1 消息生产消费模式

5.1.1 单消费

一个消费者从一个主题或队列中消费数据。

5.1.2 消费者组

消费者组，其实就是一组消费者的集合，这些消费者共用一个ID，即Group ID（字符串，长度为32字节）。

一个主题可以被多个消费者组消费，每个消费者组消费的数据互不干扰，每个消费组消费的都是完整的数据。

一个队列可以被多个消费者组消费，所有消费者组消费的数据都是均分队列里的数据。

5.1.3 消费记录

消费历史记录，分为主题消费历史记录和队列消费历史记录。

主题消费历史记录以客户端组ID（Group ID）为单位，用于标记消费者组的已消费索引的偏移。正常情况下，一条消息只能被同一个消费者组的一个消费者消费一次，当然，你可以指定消息的偏移位置（offset）重复消费消息。

队列消费历史记录以队列为单位，用于标记已消费索引的偏移。所有消费者轮询获取队列的消息，不能指定消息的偏移位置（offset）重复消费消息。

5.1.4 消费位移

消费者消费消息提供以下4种消费位移方式：

1. 每次消费最新的消息（offset设置为-2）；

2. 开启按服务端历史记录消费消息，从第一条消息开始（offset设置为-1）；

3. 开启按服务端历史记录消费消息，从最新的消息开始（offset设置为-3）；

4. 按消费者指定偏移量消费消息（offset设置为>=0，0代表第一条消息，以此类推）消费者消费消息默认是按消费者指定偏移量消费，消费者需要自己记录消息的偏移量，每收到一条消息将偏移量的编号进行累加。

注意：主题消费默认offset为-1（第二种方式），队列操作只能采用第二种方式。

5.1.5 消费位移确认

消费者消费位移确认有自动确认与手动确认提交两种策略。

1. 自动确认。在创建一个消费者时，默认是自动确认偏移量，当然我们也可以显示设置为自动

2. 手动确认。在有些场景我们可能对消费偏移量有更精确的管理，以保证消息不被重复消费以及消息不被丢失。假设我们对拉取到的消息需要进行写入数据库处理，或者用于其他网络访问请求等等复杂的业务处理，在这种场景下，所有的业务处理完成后才认为消息被成功消费，这种场景下，我们必须手动控制偏移量的提交。

6.1.6 消息回溯

消息回溯：对于已经消费成功的消息或者消费失败的消息，需要支持该信息在一定的时间段内的存储，等待某一时间内该消息会被重新消费的可能。

注意：主题文件消息支持回溯，队列文件消息不支持回溯。

基于消费位移回溯消息：对于已经消费成功或者消费失败的消息可以根据消息具体的偏移量进行消息的重新消费。

5.2应用模式

5.2.1点对点模式

点对点通信模式Point-to-Point是基于队列（Queue）的，一个队列可以有多个生产者（Producer）和多个消费者（Consumer）。消息服务器按照收到消息的先后顺序，将消息放到队列中。队列中的每一条消息，只能由一个消费者进行消费，消费之后就会从队列中移除。

点对点通信提供两种实现模式，一种是队列模式，另一种是主题消费者组模式。

⚫ 队列模式：

队列模式不区分消费者实例是否属于同一个消费者组（Group ID）。

队列的消费进度存储在broker上，Consumer自身是不存储消费进度的。消息进度存储在broker上的好处在于，当消费者（Consumer）个数扩大或者缩小时，由于消费进度统一在broker上，消息不会被重复消费。

⚫ 主题消费者组模式

点对点模式下使用主题消费者组消费时，消费者实例必须属于同一个消费者组（Group ID）。

使用主题消费者组消费时消费者（Consumer）的消费进度是按消费者组Group ID存储在工作节点上，消费者（Consumer）自身是不存储消费进度的。消费进度存储在broker上的好处在于，当消费者组成员扩大或者缩小时，由于消费者组消费进度统一在broker上，消息不会被重复消费。

5.2.2 发布订阅模式

发布订阅Pub-Sub模式中，生产者将消息发布到一个主题(Topic)中，订阅了该Topic的所有下游消费者，都可以接收到这条消息。如下图所示：

与组消费不同的是，发布订阅模式中消费者（Consumer）的消费进度存储在各个消费者（Consumer）实例上，容易造成消费重复。另外需要注意的是，在消费者（Consumer）端进行消费逻辑处理时，需要额外关注消费失败的情况。

六：集群

TongHTP集群由一个管理节点和若干个工作节点组成，统一对外提供消息接收和处理功能，且集群内的各个节点对于应用是透明的。当单个工作节点无法满足大负载的消息处理要求，可以使用集群功能将负载分配到多个工作节点上，提高系统的处理能力和可扩展性。集群内工作节点的数量可以根据需要动态调整，管理节点在运行时，管理员可以通过命令行工具动态增扩工作节点。该机制有效解决了管理节点在启动后预先配置的公共空间不足时，毋须重启管理节点，即可在运行时动态增加工作节点，扩充处理能力。

介绍以下3种集群搭建模式：

⚫ 多工作节点模式

⚫ 异步主备模式

⚫ 强一致主备模式

6.1 多工作节点模式

集群中只配置一台工作节点的风险较大，一旦工作节点重启或者宕机时，会导致整个服务不可用。所以在线上环境中应配置多台工作节点，例如2个或者3个工作节点。这种模式的优缺点如下：

⚫ 优点：配置简单，单个工作节点宕机或重启对应用无影响。在磁盘配置为机械硬盘时，即使机器宕机不可恢复情况下，由于机械硬盘磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；

⚫ 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

6.2 异步主备模式

为防止单点故障，工作节点通常需要配置成主备模式，其中一台服务器作为主设备工作，另一台服务器是备用设备，只有主设备出现故障或人为切换，备用设备才会工作。

集群中有多个工作节点，每个主工作节点都配置一个备用工作节点，有多对主备工作节点。工作节点异步主备模式集群如下图所示：

目前TongHTP的异步主备模式采用异步复制方式，主备设备会有短暂消息延迟（毫秒级），这种模式的优缺点如下：

优点：

1. 即使磁盘损坏，消息丢失的也非常少，且消息实时性也不会受影响；

2. 一旦主设备宕机后，消费者仍然可以从备用设备消费，且此过程对应用透明，性能同“多工作节点模式”几乎一样。

缺点：

1. 主备功能节点角色分两种，主节点为Leader，备份节点为Follower。Follower节点定时备份Leader节点的主题、队列消息和消费历史纪录。异常情况下，Follower备份的消息与Leader可能存在一定误差。

2. 当主设备宕机后，需要手动切换备用设备为主设备。

当主设备节点失效时，可将备用设备节点切换为主设备节点，步骤为：

1) 停止备工作节点；

2) 将备工作节点配置修改为主工作节点配置；

3) 启动备工作节点，启动后自动转换为主工作节点。

6.3 强一致主备模式

强一致主备模式是HTP工作节点的一种高可用模式。HTP集群中有至少3个（必须为奇数个）工作节点组成raft集群，组成raft集群的节点间互相通信，raft算法里>=3个奇数节点启动后进行投票选举，获得票数最多的节点成为主节点，其它节点成为从节点，主节点连接管理节点。当主节点宕机时，从节点检测连接断开，剩下的从节点重新投票选举出新的主节点，一个raft集群中的节点最大数为19个。HTP集群可以包含1个或多个raft集群。如下图所示：

强一致主备模式集群支持发布订阅BUFF消息，不支持收发队列及文件消息。这种模式的优缺点如下：

优点：

1. 实现了消息的强一致性，消息至少在集群中的半数节点上有备份；

2. raft集群高可用，raft集群内的工作节点自动选举出集群主节点，无需人工干预。

缺点：

1. 当前版本初始化raft集群时还需手工配置；

2. 多节点占用资源较多；

3. 实现高可用的同时，TPS性能相比单节点降低。

6.4 负载均衡

6.4.1 管理节点负载

为了提高集群下工作节点资源的吞吐量和加强网络数据处理能力，提高应用系统的灵活性和可用性，TongHTP根据生产者的ProducerId、topicName和DomainName等三个因素来决定资源分配的结果。不同的生产者使用相同的主题或者通信域进行生产过程，可以被分配到不同的工作节点上，保证资源调度的合理性，降低单个服务节点的负载压力。

集群的工作节点支持动态扩容或者缩容，采用一致性哈希的算法保证节点改变的最小迁移率，当工作节点增加的时候需要将其余节点的负载压力分担到这台新增的机器上，保证整个集群的负载均衡；当工作节点离线或者因为其他原因拆除后需要把原节点的资源重新分配到其他的服务节点上，保证服务的持续性。

6.4.2 客户端负载

启用客户端负载均衡后，客户端在向管理节点注册时，将获取所有可用的工作节点broker列表，客户端与列表中的broker都将建立连接。例如下图中5个主题或队列分别属于5个broker，可以部署在一台机器上，也可以分别部署在5台不同的机器上。生产者将通过轮询连接的方式发送消息，每个broker接收平均的消息量。通过增加机器，可以水平扩展队列容量。

七：消息格式及属性

7.1 消息格式

TongHTP支持字符流和文件两种消息格式，用户可根据应用系统的需要选择任何一种方式。用户使用字符流消息格式时，需要将消息的内容、标识、长度等信息传递给TongHTP，最大支持4M；用户使用文件消息格式时，则只需要将文件名（包含路径）告知TongHTP即可，TongHTP将根据用户提交的文件名对文件内容进行处理和传输，最终交付给用户指定的目的地。

7.2 消息持久性

当工作节点为普通节点时，TongHTP提供消息持久性，每条消息都可以指定持久性，持久消息不论是由于系统停止、硬件断电、硬件异常、非正常关机，还是网络异常等情况，都保证消息不丢失、内容完整，保证顺序。

7.3 消息优先级

当工作节点为普通节点时，TongHTP提供消息优先级控制功能，每条消息都可以设置不同的优先级，根据消息的紧急程度，在发送前可以为其设置10个不同级别的优先级(0-9)。发送和接收消息时按以下优先级规则处理：

1. 每个队列都支持10个优先级，即0-9。高优先级的消息被处理的速度比低优先级快，发送队列中相同优先级的消息先进先出。

2. 优先级9为独占优先级，当队列中有优先级为9的消息时，其他消息没有机会发送。

3. 优先级0为等待优先级，当队列中有优先级大于0的消息存在时，此优先级的消息没有机会发送，即只有其他优先级的消息发送完毕后才有机会发送。

4. 对于优先级8到1，相同机会发送，发送速度由快到慢。

5. 应用进程从本地队列中接收消息时，高优先级的消息先被接收，只要有高优先级的消息，低优先级的消息就没有机会处理。

7.4 消息有序性

同一工作节点通过消息偏移量进行存储，保证发送和拉取消息的一致性。

7.5 消息自定义属性

自定义属性是用户定义的名值对属性，用户调用接口对一段内存空间进行读写操作，然后赋值给消息的自定义属性域。消息自定义属性的个数最大200个，且消息内容长度和自定义属性长度之和不大于4M字节。

八：发送方式

8.1 同步发送

应用调用消息发送接口函数，接口内部等待工作节点返回发送消息的确认应答后，接口函数才会返回。

8.2 异步发送

异步模式调用发送接口放入客户端发送缓存队列后，接口函数立即返回，不等待工作节点返回发送消息的确认应答。在工作节点返回发送确认应答后，客户端调用预先注册的回调函数进行处理。

8.3 批量发送

将一批消息在客户端打包进行一次性发送，增加带宽暂用率，提升效率。

1. 组合后的单个批量消息大小不大于4M字节。

2. 批量消息的通信域名、目的队列名或主题名相同。

3. 批量消息中支持分别设置每条消息的持久性、优先级、有效期等属性。

九：接收方式

9.1 同步接收

应用调用消息接收接口时，消息接收接口阻塞等待，直到接收到一条消息或接收超时，接口返回。

9.2 异步接收

应用要在接收消息前注册异步消息处理回调函数，然后调用一次接收接口启动接收。

9.3 批量接收

应用可以通过设置批量拉取的消息条数实现消息的批量接收。

1. 单次批量拉取的消息总大小不超过 4M 字节。

2. 消息大小超过 4M，工作节点仅返回 4M 消息。注意：工作节点不截断单条消息，如果需要批量拉取的消息总大小超过了 4M，工作节点仅返回总大小接近 4M 的完整消息条数。

例如：需要批量拉取的消息条数为 5 条，总大小超过 4M，前 3 条消息和部分第 4 条消息总大小为 4M，工作节点仅返回前 3 条消息，不返回第 4 条消息。

3. 没有拉取到消息工作节点提示找不到消息并直接返回。

9.4消息批量清理

⚫ 当工作节点为普通节点时：

工作节点可定时在配置的时间点检查消息是否删除。当消息文件过期，工作节点以文件为单位删除消息的数据文件和索引文件。批量删除消息文件后，工作节点仍可持续运行。

⚫ 当工作节点为raft集群节点时：

工作节点可定时在配置的时间点检查raft消息文件是否删除。当raft消息文件过期，工作节点以文件为单位删除raft消息的数据文件，不会删除索引文件。批量删除消息文件后，工作节点仍可持续运行。

十：文件续传

网络发生异常或应用异常退出，应用有可能需要续传客户端正在发送中(Snding)或正在接收中(Rcving)状态的消息。

1. 消息发送的同步模式和异步模式都支持续传。

2. 消息接收采用拉取模式，默认支持续传。

3. 支持应用异常后的续传。

10.1 发送续传

续传发送消息需要提前在消息发送接口设置续传标识。每次调用发送接口都会清理上一次的发送续传。

网络发生异常时，文件消息发送中断，应用从发送接口返回。如果应用调用消息续传接口，发送从上次消息的中断处继续传输，而不是丢弃分片消息，从头开始发送消息。如果不调用消息续传接口，客户端重置发送中的文件消息，从头开始发送消息。

10.2 接收续传

接收文件消息默认支持续传。网络发生异常时，文件消息接收中断，应用需要续传客户端正在接收中状态的消息，即接收从上次消息的中断处继续传输，而不是丢弃分片消息，从头开始接收消息。

十一：队列

11.1 本地队列

本地队列是应用程序通过API对其进行读写操作的队列，TongHTP从网络上收到的消息，需要放入本地队列，才可以被应用所读取，应用既可向本地队列发送消息，也可从本地队列接收消息。

本地队列中消息的排列方式有：先进先出和消息优先级（消息按优先级从高到低存放）。

⚫ 若为先进先出时，则接收消息时，首先接收符合条件的第一条消息；

⚫ 若为优先级时，则高优先级的先被处理。

11.2 发送队列

用于存放即将发送到远端某个集群节点上的消息。发送队列作为消息发送的媒介，一个发送队列对应某个集群节点上的一个目的队列，此目的队列为本地队列、发送队列、集群队列或主题。发送队列内的消息不能被客户端消费。

发送队列发送消息到目的队列有两种发送方式：直连模式和路由模式。

直连模式：发送队列直接连接某个集群节点上的对应目的队列。如下图所示，生产者（Producer）将消息通过发送队列名（sendqueue）传送到集群1工作节点，集群1工作节点经传输链路（LinkNo）发送消息到已建立连接的集群2工作节点的对应目的队列（destination），消费者（Consumer）负责从集群2工作节点通过目的队列名（destination）去消费消息。

路由模式：发送队列连接某个集群节点上由管理节点分配的工作节点的对应目的队列。如下图所示，生产者（Producer）将消息通过发送队列名（sendqueue）传送到集群1工作节点，集群2管理节点分配真实可用的工作节点并告知集群1工作节点，集群1工作节点经传输链路（LinkNo）发送消息到集群2管理节点分配的工作节点的对应目的队列（destination），消费者（Consumer）负责从集群2工作节点通过目的队列名（destination）去消费消息。

11.3 集群队列

集群队列将消息按配置，分发到指定的目的队列。分发策略分为复制分发和权重分发。复制分发将消息复制到每一个目的队列中。权重分发则将消息按权重顺序轮询分发到目的队列中。

⚫ 集群队列、本地队列、发送队列在配置中分属不同的配置小节，队列名不能重复；

⚫ 集群队列内的消息不能被客户端消费；

⚫ 集群队列的目的地队列只能是本地队列或发送队列；

⚫ 集群队列无内部优先级。

11.4 延时队列

具有队列的特性，再给它附加一个延迟消费队列消息的功能,也就是说可以指定队列中的消息在哪个时间点被消费。生产者将消息发送到工作节点，但并不期望立马投递这条消息，而是延迟一定时间后才投递到消费者进行消费。

消息设置延时的属性，称为延时消息。延时消息默认有1-18个时间等级，分别对应延长时间1s、5s、10s、30s、1min、2min、3min、4min、5min、6min、7min、8min、9min、10min、20min、30min、1h、2h。

若消息的延时等级不合法，则直接创建消息的原索引，可被正常消费。

11.5 死信队列

生产者将消息投递到队列中，消费者从队列中取出消息进行消费，由于特定的原因导致队列中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信（Dead Letter），所有的死信都会放到死信队列中。

约定死信主题的名称为%DLQ%消费组名称，提供单独的生成死信消息API函数（创建死信队列，将原消息放入）。如需消费死信消息，客户端调用普通消费API，向管理节点查询死信队列，连接死信对应的工作节点，可以指定消费的offset，直接拉取消息内容获取死信。

十二：安全

12.1 黑白名单

客户端接入管理提供是否允许客户端接入功能，对应客户端添加进黑名单，则不允许接入集群，若客户端添加进白名单，则允许接入集群。黑名单与白名单为互斥操作，在黑名单中的客户端不能加入白名单。

管理节点可以在HTPManager/config/nameServer.xml中对客户端进行监管配置：

⚫ 黑名单：

 <ClientBlackList>：客户端黑名单，有效的clientID，以逗号分隔；

 <ClientIPBlackList>：客户端IP黑名单，有效的clientIP，以逗号分隔；

黑名单上的客户端向管理节点注册不成功，无法发送消息。

⚫ 白名单：

 <ClientWhiteList>：客户端白名单，有效的clientID，以逗号分隔；

 <ClientIPWhiteList>：客户端IP白名单，有效的clientIP，以逗号分隔；

白名单上的客户端注册时，无需认证即可接入TongHTP服务端。

12.2 用户权限

管理节点提供用户权限管理文件HTPManager/config/user.xml，可设置是否开启客户端接入集群时的认证。开启认证后（默认关闭），客户端需使用已设置的账号及密码登录（默认管理员及密码admin/admin），并享有相应的权限。要添加或修改用户名密码，需要通过管理控制台或命令行实现，账户可设置为管理员或普通账户，并对其指定可使用的主题及所属通信域。

客户端管理类操作协议（创建通信域、删除通信域、创建主题、删除主题、修改主题等），需要具备管理权限才能操作，否则相关操作返回失败。管理节点对此提供权限识别管理功能。