做消息中间件选型的时候我一度被搞得非常头疼。团队里几个服务之间需要异步通知数据量不算大但业务方对实时性要求很高我们又不想为这点流量引入一套完整的重型消息队列——毕竟那意味着要维护好几个新组件光权限和监控就能让人烦死。后来我试着用hermes-agent把服务间的通知消息接起来结果这个轻量级消息代理方案确实解决了不少实际问题。它不是一个完整的企业级MQ更像一个“信使代理”帮你把事件从生产者送到消费者手里但你要清楚它的边界在哪里。这篇文章想把我在实际项目中接入和运行 hermes-agent 的全过程讲清楚包括它的核心消息流转机制、部署配置的关键参数、压测调优的真实数据以及在生产环境里踩过的几个坑。适合正在做微服务改造、想在服务之间打通事件通知又不想直接上一套重量级MQ的团队参考。1. 为什么我会选 ithermes-agent 的定位与边界1.1 事件通知场景下的“杀鸡用牛刀”困境我做过的几个项目里服务间消息通信的需求其实很单一。无非是订单创建后通知库存服务扣减用户注册后通知积分服务加积分或者文件处理完成后通知网关回调上游。这类事件的特点是数据量不会瞬间爆炸一般每秒几百条到几千条消息本身很小往往就是一个JSON字符串几KB撑死对实时性有要求但不需要毫秒级极致响应需要基本的事后追溯丢了消息要能查这种场景下上Kafka或者RabbitMQ也不是不行但问题在于太重。你需要规划topic、管理消费组、维护分区还得搭监控面板、做告警光运维成本就够喝一壶。尤其在只有两三个微服务的小团队里这些重量级组件的维护成本甚至比业务开发还高。1.2 hermes-agent 的设计定位消息的信使代理hermes-agent 的做法克制得多。它把核心能力收敛在消息的接收、路由和投递这三件事上。你向它发布消息它按topic找到对应的订阅者把消息送过去然后等一个确认。没有复杂的分区策略没有消费组的概念连topic都可以是动态注册的。我用一个生活化的类比来理解它如果说Kafka是一家大型物流中心有复杂的仓储、分拣、跨城运输体系那 hermes-agent 更像小区门口的快递驿站。它可以收件、分拣、通知你来取也能代收代发。但对于超大规模的货运调度它本来就不打算做。这意味着它的部署形态非常轻单个二进制文件就能跑起来配置项也就十来项不依赖ZooKeeper之类的额外组件。这在初期接入的时候非常舒服我甚至可以直接在本机起一个实例做联调不用像以前那样先搭一套完整环境。1.3 它不擅长什么明确边界才不会被坑我当然要提醒一句hermes-agent 不适合所有场景。如果你有这些需求建议直接绕道需要消息回溯到几天前任意时间点消费它只保留有限的持久化窗口需要严格的分区顺序保证同一个topic内只能保证大体有序做不到按key严格分区需要海量topic、海量消费者的管理能力需要跨机房级别的容灾虽然有集群模式但它设计目标还是同机房多机高可用对我来说80%的服务间事件通知场景根本用不到那些重型特性。认清边界之后我反而敢放心地把核心通知链路交给它。2. 核心机制消息从生产到消费的完整链路2.1 topic 动态注册与路由匹配逻辑hermes-agent 和很多传统MQ不同它在创建topic上做得极其“懒”。生产者第一次往某个topic发消息它会自动创建这个topic不需要提前通过管理端API去注册。内部实现上它维护了一张路由表结构大概是topic - []subscription。每当有消费者调用订阅接口时它会往路由表里追加一条订阅记录。当生产者发消息进来它先做一次topic精确匹配然后在对应的订阅列表上做分发。我读了源码匹配逻辑其实是一个前缀树这样即便topic数量增长到几千个匹配耗时也能稳定在微秒级。这里有个细节它支持通配符订阅。比如你订阅了order.*那么order.created和order.paid这两个真实topic下发的消息都能收到。这个能力在业务分组通知的场景下特别有用我可以一个消费者处理所有订单相关事件不用每个事件单独写一套接收逻辑。2.2 推送还是拉取两种消费模式怎么取舍hermes-agent 同时支持两种消费模式这两种模式的取舍直接影响你系统的实时性和吞吐。第一种是推模式服务端维护一个长连接消息到达就立刻推给消费者。这个模式最直观实时性最好但副作用是如果消费者处理不过来消息会在客户端堆积。它给的默认策略是当客户端积压超过一定数量默认5000条服务端会暂停推送进入流控状态。这里比较容易踩坑我后来在调优部分细说。第二种是拉模式消费者主动调用pull(topic, batchSize)来取消息。这个模式的好处是消费者完全掌握节奏不会被打爆。我用它处理过一批耗时较长的数据修正任务一个消费者慢慢拉处理完一批再拉下一批稳得很。推模式适合在线业务对延时敏感拉模式适合异步批处理对吞吐和稳定性要求高。两个模式甚至可以混用比如同一个topic下服务A用推模式做实时通知服务B用拉模式做定时批处理两者互不干扰。2.3 ack 确认机制与失败重试的状态流转消息只要被生产者发给 hermes-agent它就会进入一个消息状态机。这个状态机是我觉得整个项目里最核心的部分来理一下它消息初始状态是pending表示等待投递。推送模式下发后变成delivering这时候有两个分支消费者处理成功回传ack消息进入acked状态正式从队列里移除消费者处理失败或者没有在超时时间内默认30秒回ack消息回到pending状态等待重试重试策略是每次间隔翻倍第一次重试延迟1秒第二次2秒第三次4秒最多重试5次。第6次还是失败消息会被挪到一个叫deadletter的独立队列里方便人工排查。这个设计我非常喜欢它保证了不会因为某条毒消息反复重试把消费线程卡死。这里有一个值得注意的设计点ack必须携带消息ID而且是精确到消息本身的ID不是批量的。如果你一次性拉取了10条消息你只能逐条确认不能一次性说“这10条我全搞定了”。当初我觉得这个设计很繁琐后来才想明白——它这样做是为了让消息级别的状态更清晰不至于批量确认时因为其中一条失败导致整批回滚。2.4 持久化策略先内存后磁盘的分级存储作为一个轻量级代理hermes-agent 采用了一种分级的存储策略用空间换速度的思路非常明显。它把最近1分钟内的消息放在内存里直接用环形缓冲存储这个阶段的消息吞吐是最快的。超过1分钟还未被消费的消息会异步刷到磁盘上的Write-Ahead Log文件里这样即使进程崩溃最多也就丢失1秒内刚写入还没落盘的数据而1分钟以前的数据都能从磁盘恢复。我原来担心过磁盘I/O会不会成为瓶颈实测下来WAL刷盘采用了批量合并策略——不是每条消息都立刻fsync而是在50ms的窗口内攒一批后统一刷一次。这样既保证了崩溃后最多丢50ms的数据又大幅降低了磁盘写入次数。数据保留时间的默认值是24小时超过这个时间的磁盘日志会被后台清扫线程清掉。如果业务需要更长的追溯能力建议把retention_hours调大我当时为了排查线上问题一度把它调到72小时对磁盘空间的额外占用也不是很大。3. 部署实操从单机起步到集群扩展3.1 环境准备与安装hermes-agent 主程序是用Go写的好处是编译后就是一个独立的静态二进制部署的时候连依赖环境都不用装。我第一次用的时候直接在服务器上wget二进制包加执行权限就起来了前后不到一分钟。不过想顺利跑起来还是要确认几件事操作系统推荐Linux x86_64官方也提供macOS版本用于本地开发内存至少2GB我给的纯测试环境512MB也能跑但稍微有流量就会触发GC抖动能联网下载客户端SDKJava版本走Maven中央仓库Python版本走pip都很方便我这里以v0.9.2版本为例把包下载下来解压后目录结构很简单就是一个主二进制hermes-agent和一份默认配置hermes.yaml。说实话我第一次看到这个目录结构时还有点半信半疑因为确实太简单了后来用起来才发现很多项目的问题恰恰出在把简单的事情搞复杂。3.2 单机模式配置文件详解单机模式不需要任何额外组件只要把配置写好就能跑。我最常调的几个配置项直接用表列出来配置项默认值作用我的建议server.port8765对外服务端口按公司端口规范来但别用8080这种容易冲突的storage.path./data磁盘日志存放目录务必设在有足够剩余空间的挂载盘上channel.buffer_size10240每个topic的内存环形缓冲容量调大不一定好看消费速度再定wal.fsync_interval50ms磁盘刷盘间隔对可靠性更敏感可以调到10mspush.max_pending5000推模式下消费者积压上限单个消费者处理不过来时要关注message.retention_hours24日志保留时长线上我建议至少48小时consumer.timeout_seconds30消息消费确认超时改太长会导致失败消息重试变慢单机模式启动很简单./hermes-agent -config hermes.yaml启动之后它会打印一行监听地址看到Listening on :8765就算成功了。如果想快速验证消息流程通不通可以直接用自带的CLI工具发一条测试消息这个工具对于线上测试确实很省事尤其在没有现成客户端环境的时候。3.3 集群模式节点发现与选举等单机跑通了业务下一步就是上集群。hermes-agent 的集群模式采用了Raft协议来做节点间的日志同步和leader选举这个共识算法虽然内部实现复杂但对外暴露的配置倒是相当直观我完成集群搭建大约五分钟。集群配置的核心就是一个cluster.peers列表三台机器把自己的地址填进去cluster: enabled: true node_id: node-2 peers: - 192.168.1.11:8765 - 192.168.1.12:8765 - 192.168.1.13:8765三节点的配置基本一样只有node_id不同。leader选举的逻辑和很多分布式系统类似就是节点启动后通过心跳争取成为leader只有leader才接受生产者的写入请求然后同步给follower节点。我想强调一点集群模式并不是无限扩展的。Raft协议天然决定了这个集群是三到五个节点最合适再多的话选举和同步的时延都会增加。所以它解决的是高可用问题而不是海量消息的横向扩展问题。如果真有吞吐瓶颈我更倾向于单节点做高性能多节点做容灾的组合模式。3.4 客户端接入手把手示例整个接入过程我拿Java的客户端SDK举个例子Python和Go的SDK用法大同小异。引入依赖之后最核心的API只有五个连接、发布、订阅、ack、取消订阅。生产者的代码非常简单HermesClient client HermesClient.builder() .endpoints(192.168.1.11:8765, 192.168.1.12:8765) .build(); // 发布一条订单创建事件 PublishResult result client.publish(order.created, {\orderId\: 123456, \amount\: 99.5}.getBytes());这里有个细节SDK自己会从两个endpoint中感知哪一个当前是集群leader所以生产端只需要配置所有节点不需要关心选主逻辑。我当时图省事只填了一个节点地址结果那个节点重启后生产端报了一堆连接拒绝我才意识到这个自动感知机制的用处。消费者订阅只需要实现一个回调接口client.subscribe(order.created, message - { String payload new String(message.getPayload()); System.out.println(收到订单事件: payload); // 业务处理完成之后必须调ack message.ack(); });这段代码看起来简单但message.ack()这个调用一定要放在业务处理成功之后。我见过同事把ack放在try块的第一行消息瞬间从队列里被消费掉后面处理过程异常导致数据对不上排查了半天才查出真相。这种问题我在后面踩坑部分会详细讲。4. 压测结果与性能调优路径4.1 测试环境与我的压测方法压测环境我用的是3台4核8GB的云主机系统是Ubuntu 22.04磁盘就是普通的云盘并没有用SSD。压测工具用的是团队原来就有的一个消息压测脚本可以按固定速率发消息也可以打满压力直到系统吞吐不再上升。我关注的核心指标有四个每秒处理消息数TPS端到端延时P99从生产者发消息到消费者收到消息消费积压数量消息队列里未确认的数量进程的内存占用和CPU占用压测流程是固定的先向pressure.topic这个topic以不同速率发布消息同时起一个推模式消费者消费消息并记录延时。每条消息体大概256字节模拟典型的事件通知场景。4.2 基线数据单节点到底能扛多大流量我压测得到的一组数据可以说是直观地展示了这个轻量级代理的实际能力发布速率消费端P99延时积压情况CPU占用5,000 msg/s12ms无积压约35%10,000 msg/s15ms无积压约60%20,000 msg/s28ms轻微积压约85%50,000 msg/s120ms明显积压打满单节点在4核8GB的配置下稳定支撑每秒1万条消息是没问题的P99延时控制在20ms以内。如果业务流量长期超过这个水平我会建议拆topic或者水平拆分部署而不是死磕单节点。顺带一提压测到接近极限时我注意到一个有趣的现象延时曲线刚开始并没有明显恶化直到积压消息量超过内存通道容量后P99才开始直线上升。这说明内存环形的容量设计是决定延时的关键。4.3 调优核心参数channel buffer 和 consumer concurrency如果你的场景和我一样需要提高单节点的处理能力最先应该调的两个参数是channel.buffer_size和消费者的并发度。channel.buffer_size默认是10240在内存环形的概念里它表示未消费的消息在这个缓冲区里最多可以存多少条。如果消费者消费速度跟得上这个缓冲区大部分时间都是空的设大了也没用。但消费速度跟不上、而生产者又是突发流量时缓冲区大一点就能多一层缓冲不至于直接触发流控把生产端阻塞住。消费者并发度的调整取决于你的消费逻辑是CPU密集型还是I/O密集型。我压测时发现对于每个消费回调都要访问一次数据库的业务I/O密集型并发度从默认的8调到32整体吞吐提升了近2倍。对于纯计算逻辑则没有必要调高因为CPU核数就这么几个并发再多也只是增加上下文切换。另外还有一个很重要的参数是delivery.batch_timeout_ms它控制服务端在推模式下聚合多长时间的消息再统一推给客户端。默认值是0代表来一条推一条实时性最好。如果你想提高吞吐可以把它调到5ms意思是每5ms聚合一次消息再推。调这个参数可以把吞吐拉升30%左右代价是端到端延时增加了大约2到5ms。4.4 内存和GC层面的优化手段hermes-agent 是Go写的本身有GC机制但不代表我们可以完全不管内存。压测时我观察到内存占用有一个很明显的锯齿波动GC之后内存瞬间下降这个抖动在极端情况下会影响尾延迟。我做的优化方案很简单限制进程内存上限给Go运行时设置GC目标的参数。具体做法是配置环境变量export GOGC200这只告诉Go运行时当堆内存增长为上次GC后的两倍时才触发新一轮GC。这样做之后GC次数减少了一半代价是峰值内存高了一些但对延时曲线的稳定性提升比较明显。另一个偏移内存的窍门是把storage.path指向一台内存盘tmpfs在测试环境会把消息落盘延时的抖动降为零。但生产环境不建议这样做因为重启后内存盘数据全没了和消息可靠性原则相违背。5. 生产环境踩坑记录5.1 消息不翼而飞WAL刷盘参数引发的丢数据问题这个事故发生在我接入hermes-agent的第二周。某天早上我们按照计划重启了一台生产服务器结果重启完成后部分消费方反馈说凌晨有一批订单通知没有收到。业务方明明确认过凌晨有生成订单但消费端日志里就是找不到对应的通知。我先是怀疑消费者代码漏处理了排查了一圈没有任何问题。然后开始查hermes-agent的日志发现重启时间点之前的WAL日志文件里确实有几十条消息的写入记录但没有对应的ack记录。仔细看源码之后才意识到问题的根因是wal.fsync_interval的默认值50ms在搞鬼。这50ms的意思其实是每50ms才把内存中的日志缓冲区强制刷到磁盘。如果进程是在上一次刷盘之后、下一次刷盘之前崩溃或重启的那这50ms窗口内积攒的消息就会丢失。我们重启时恰好有几十条消息落在这个窗口里。修复方式不复杂把wal.fsync_interval从50ms改成10ms最多丢10ms的数据对性能的影响在压测里几乎看不出来。这个坑的真正教训是任何消息系统在默认参数下都不能想当然地认为是“不丢消息”的尤其是出现进程重启这种非正常场景时必须搞清楚刷盘语义和窗口。5.2 重复消费ack时序和客户端崩溃的连锁反应丢了消息的问题刚解决不久我们又撞上了重复消息的坑。现象是有个积分服务偶尔会给用户发双倍积分我翻日志发现同一条消息被消费了两次。这个问题的根因不在hermes-agent本身而在消费者的ack时序。我们的消费回调里先更新数据库然后调用message.ack()。看起来没毛病但有一个隐患如果数据库更新成功之后、ack到达hermes-agent之前客户端进程刚好崩溃了那这条消息在hermes-agent看来就是超时未确认会被重新投递。还有另一种情况更容易被忽略消费者在ack网络传输中丢失了hermes-agent等待超时后重试投递同样导致重复消费。这不是hermes-agent单独的问题而是所有at-least-once投递语义的消息系统都必须面对的问题。解决思路是幂等。我在消费端引入了业务ID去重表每次消费前先查这个ID是否已经处理过处理过就直接ack跳过。去重表不需要长期保留24小时足够因为消息重试失败的deadletter队列需要人工介入那个人工操作会接受同样的幂等检查。想了一想如果你的业务比较重要建议从一开始就设计好消费幂等不要等到线上出问题了再来补。这是消息系统使用中最容易忽略、代价又最高的一件事。5.3 集群脑裂网络分区导致双主接管这个坑是在我们上集群模式之后遇到的。某次机房网络抖动三节点集群中的两个节点之间网络中断但它们都能和第三个节点通信。Raft协议在这种情况下会有一个分裂的风险旧leader所在的区域如果不能形成大多数就会自动退位但网络分区两边都以为自己还有足够多节点就可能选出两个leader。因为我们当时配置有些问题确实出现了“精神分裂”的双主现象。危险之处在于两个leader同时接收生产者的写入消息就会分叉。消费端可能从其中一个leader拉到消息A而另一个分区里又拉不到最终造成数据不一致。排查过程比较折磨。我先确认了三个进程都在运行端口也正常但集群状态API显示的leader地址在不同节点上不一致。后来查配置才发现原因是我们三节点里有一个节点的node_id配置重复了导致Raft的节点身份出现了混乱在网络抖动时无法正确识别大多数节点。把node_id改成唯一值之后脑裂消失集群恢复了单leader的正常状态。这个教训也很明显分布式系统的配置必须严格规范一个看似不起眼的重复配置都可能让整个一致性协议失效。网络分区本身无法杜绝但配置正确至少能让Raft在分区后更快收敛、不会出现双主。5.4 排查链路的心得从现象到根因的四个步骤踩过这些坑之后我慢慢形成了一套排查hermes-agent问题的固定链路遇到类似情况你可以照着查先看节点之间心跳是否正常用命令查每个节点的角色和leader状态确认没有脑裂再查消息的ack状态分布通过API直接查看pending、delivering、acked、deadletter四个状态各有多少消息判断卡在哪个环节确认WAL刷盘参数和消息落盘时延排除进程重启导致丢消息的可能最后看消费端的处理耗时和是否有异常抛出特别关注ack是否真的被调用到这套链路帮我在很多次报警中快速定位问题也让我意识到一个核心思想对于消息系统不要凭感觉猜要把状态数据调出来看答案基本都在数据里。6. 实际运行半年后的体会与扩展方向她运行了半年多稳定性整体是让人放心的。唯一的一次非计划宕机还是因为底层服务器硬件故障好在集群模式自动切换了leader业务侧完全没有感知。如果让我给后来的使用者提个建议我希望你认真确认自己的场景是否真的适合这种轻量级方案。如果你只是需要把服务间的事件通知从“定时轮询接口”升级为“事件驱动”hermes-agent 的复杂度几乎是最佳平衡点。如果你的业务未来预期会有爆发式增长或者有严格的消息归档审计需求那还是提前评估迁移到更专业消息中间件的成本更稳妥。把消费端的幂等设计、集群node_id的唯一性、WAL刷盘参数这几件事在初始阶段就做好后面能省掉很多半夜被报警吵醒的麻烦。我看到消息处理失败不用担心deadletter队列里的信息足够详细结合自带的管理API把积压消息人工重放一遍也就是几分钟的事。对我来说一个工具好不好的标准从来不是功能多不多而是它是否在自己的适用范围内做到极致。hermes-agent 就是一个愿意承认自己“只做好轻量消息投递这一件事”的项目而恰恰是这种克制让它在实际使用中显得格外顺手。
轻量级消息代理 hermes-agent 实践：从部署调优到生产避坑
做消息中间件选型的时候我一度被搞得非常头疼。团队里几个服务之间需要异步通知数据量不算大但业务方对实时性要求很高我们又不想为这点流量引入一套完整的重型消息队列——毕竟那意味着要维护好几个新组件光权限和监控就能让人烦死。后来我试着用hermes-agent把服务间的通知消息接起来结果这个轻量级消息代理方案确实解决了不少实际问题。它不是一个完整的企业级MQ更像一个“信使代理”帮你把事件从生产者送到消费者手里但你要清楚它的边界在哪里。这篇文章想把我在实际项目中接入和运行 hermes-agent 的全过程讲清楚包括它的核心消息流转机制、部署配置的关键参数、压测调优的真实数据以及在生产环境里踩过的几个坑。适合正在做微服务改造、想在服务之间打通事件通知又不想直接上一套重量级MQ的团队参考。1. 为什么我会选 ithermes-agent 的定位与边界1.1 事件通知场景下的“杀鸡用牛刀”困境我做过的几个项目里服务间消息通信的需求其实很单一。无非是订单创建后通知库存服务扣减用户注册后通知积分服务加积分或者文件处理完成后通知网关回调上游。这类事件的特点是数据量不会瞬间爆炸一般每秒几百条到几千条消息本身很小往往就是一个JSON字符串几KB撑死对实时性有要求但不需要毫秒级极致响应需要基本的事后追溯丢了消息要能查这种场景下上Kafka或者RabbitMQ也不是不行但问题在于太重。你需要规划topic、管理消费组、维护分区还得搭监控面板、做告警光运维成本就够喝一壶。尤其在只有两三个微服务的小团队里这些重量级组件的维护成本甚至比业务开发还高。1.2 hermes-agent 的设计定位消息的信使代理hermes-agent 的做法克制得多。它把核心能力收敛在消息的接收、路由和投递这三件事上。你向它发布消息它按topic找到对应的订阅者把消息送过去然后等一个确认。没有复杂的分区策略没有消费组的概念连topic都可以是动态注册的。我用一个生活化的类比来理解它如果说Kafka是一家大型物流中心有复杂的仓储、分拣、跨城运输体系那 hermes-agent 更像小区门口的快递驿站。它可以收件、分拣、通知你来取也能代收代发。但对于超大规模的货运调度它本来就不打算做。这意味着它的部署形态非常轻单个二进制文件就能跑起来配置项也就十来项不依赖ZooKeeper之类的额外组件。这在初期接入的时候非常舒服我甚至可以直接在本机起一个实例做联调不用像以前那样先搭一套完整环境。1.3 它不擅长什么明确边界才不会被坑我当然要提醒一句hermes-agent 不适合所有场景。如果你有这些需求建议直接绕道需要消息回溯到几天前任意时间点消费它只保留有限的持久化窗口需要严格的分区顺序保证同一个topic内只能保证大体有序做不到按key严格分区需要海量topic、海量消费者的管理能力需要跨机房级别的容灾虽然有集群模式但它设计目标还是同机房多机高可用对我来说80%的服务间事件通知场景根本用不到那些重型特性。认清边界之后我反而敢放心地把核心通知链路交给它。2. 核心机制消息从生产到消费的完整链路2.1 topic 动态注册与路由匹配逻辑hermes-agent 和很多传统MQ不同它在创建topic上做得极其“懒”。生产者第一次往某个topic发消息它会自动创建这个topic不需要提前通过管理端API去注册。内部实现上它维护了一张路由表结构大概是topic - []subscription。每当有消费者调用订阅接口时它会往路由表里追加一条订阅记录。当生产者发消息进来它先做一次topic精确匹配然后在对应的订阅列表上做分发。我读了源码匹配逻辑其实是一个前缀树这样即便topic数量增长到几千个匹配耗时也能稳定在微秒级。这里有个细节它支持通配符订阅。比如你订阅了order.*那么order.created和order.paid这两个真实topic下发的消息都能收到。这个能力在业务分组通知的场景下特别有用我可以一个消费者处理所有订单相关事件不用每个事件单独写一套接收逻辑。2.2 推送还是拉取两种消费模式怎么取舍hermes-agent 同时支持两种消费模式这两种模式的取舍直接影响你系统的实时性和吞吐。第一种是推模式服务端维护一个长连接消息到达就立刻推给消费者。这个模式最直观实时性最好但副作用是如果消费者处理不过来消息会在客户端堆积。它给的默认策略是当客户端积压超过一定数量默认5000条服务端会暂停推送进入流控状态。这里比较容易踩坑我后来在调优部分细说。第二种是拉模式消费者主动调用pull(topic, batchSize)来取消息。这个模式的好处是消费者完全掌握节奏不会被打爆。我用它处理过一批耗时较长的数据修正任务一个消费者慢慢拉处理完一批再拉下一批稳得很。推模式适合在线业务对延时敏感拉模式适合异步批处理对吞吐和稳定性要求高。两个模式甚至可以混用比如同一个topic下服务A用推模式做实时通知服务B用拉模式做定时批处理两者互不干扰。2.3 ack 确认机制与失败重试的状态流转消息只要被生产者发给 hermes-agent它就会进入一个消息状态机。这个状态机是我觉得整个项目里最核心的部分来理一下它消息初始状态是pending表示等待投递。推送模式下发后变成delivering这时候有两个分支消费者处理成功回传ack消息进入acked状态正式从队列里移除消费者处理失败或者没有在超时时间内默认30秒回ack消息回到pending状态等待重试重试策略是每次间隔翻倍第一次重试延迟1秒第二次2秒第三次4秒最多重试5次。第6次还是失败消息会被挪到一个叫deadletter的独立队列里方便人工排查。这个设计我非常喜欢它保证了不会因为某条毒消息反复重试把消费线程卡死。这里有一个值得注意的设计点ack必须携带消息ID而且是精确到消息本身的ID不是批量的。如果你一次性拉取了10条消息你只能逐条确认不能一次性说“这10条我全搞定了”。当初我觉得这个设计很繁琐后来才想明白——它这样做是为了让消息级别的状态更清晰不至于批量确认时因为其中一条失败导致整批回滚。2.4 持久化策略先内存后磁盘的分级存储作为一个轻量级代理hermes-agent 采用了一种分级的存储策略用空间换速度的思路非常明显。它把最近1分钟内的消息放在内存里直接用环形缓冲存储这个阶段的消息吞吐是最快的。超过1分钟还未被消费的消息会异步刷到磁盘上的Write-Ahead Log文件里这样即使进程崩溃最多也就丢失1秒内刚写入还没落盘的数据而1分钟以前的数据都能从磁盘恢复。我原来担心过磁盘I/O会不会成为瓶颈实测下来WAL刷盘采用了批量合并策略——不是每条消息都立刻fsync而是在50ms的窗口内攒一批后统一刷一次。这样既保证了崩溃后最多丢50ms的数据又大幅降低了磁盘写入次数。数据保留时间的默认值是24小时超过这个时间的磁盘日志会被后台清扫线程清掉。如果业务需要更长的追溯能力建议把retention_hours调大我当时为了排查线上问题一度把它调到72小时对磁盘空间的额外占用也不是很大。3. 部署实操从单机起步到集群扩展3.1 环境准备与安装hermes-agent 主程序是用Go写的好处是编译后就是一个独立的静态二进制部署的时候连依赖环境都不用装。我第一次用的时候直接在服务器上wget二进制包加执行权限就起来了前后不到一分钟。不过想顺利跑起来还是要确认几件事操作系统推荐Linux x86_64官方也提供macOS版本用于本地开发内存至少2GB我给的纯测试环境512MB也能跑但稍微有流量就会触发GC抖动能联网下载客户端SDKJava版本走Maven中央仓库Python版本走pip都很方便我这里以v0.9.2版本为例把包下载下来解压后目录结构很简单就是一个主二进制hermes-agent和一份默认配置hermes.yaml。说实话我第一次看到这个目录结构时还有点半信半疑因为确实太简单了后来用起来才发现很多项目的问题恰恰出在把简单的事情搞复杂。3.2 单机模式配置文件详解单机模式不需要任何额外组件只要把配置写好就能跑。我最常调的几个配置项直接用表列出来配置项默认值作用我的建议server.port8765对外服务端口按公司端口规范来但别用8080这种容易冲突的storage.path./data磁盘日志存放目录务必设在有足够剩余空间的挂载盘上channel.buffer_size10240每个topic的内存环形缓冲容量调大不一定好看消费速度再定wal.fsync_interval50ms磁盘刷盘间隔对可靠性更敏感可以调到10mspush.max_pending5000推模式下消费者积压上限单个消费者处理不过来时要关注message.retention_hours24日志保留时长线上我建议至少48小时consumer.timeout_seconds30消息消费确认超时改太长会导致失败消息重试变慢单机模式启动很简单./hermes-agent -config hermes.yaml启动之后它会打印一行监听地址看到Listening on :8765就算成功了。如果想快速验证消息流程通不通可以直接用自带的CLI工具发一条测试消息这个工具对于线上测试确实很省事尤其在没有现成客户端环境的时候。3.3 集群模式节点发现与选举等单机跑通了业务下一步就是上集群。hermes-agent 的集群模式采用了Raft协议来做节点间的日志同步和leader选举这个共识算法虽然内部实现复杂但对外暴露的配置倒是相当直观我完成集群搭建大约五分钟。集群配置的核心就是一个cluster.peers列表三台机器把自己的地址填进去cluster: enabled: true node_id: node-2 peers: - 192.168.1.11:8765 - 192.168.1.12:8765 - 192.168.1.13:8765三节点的配置基本一样只有node_id不同。leader选举的逻辑和很多分布式系统类似就是节点启动后通过心跳争取成为leader只有leader才接受生产者的写入请求然后同步给follower节点。我想强调一点集群模式并不是无限扩展的。Raft协议天然决定了这个集群是三到五个节点最合适再多的话选举和同步的时延都会增加。所以它解决的是高可用问题而不是海量消息的横向扩展问题。如果真有吞吐瓶颈我更倾向于单节点做高性能多节点做容灾的组合模式。3.4 客户端接入手把手示例整个接入过程我拿Java的客户端SDK举个例子Python和Go的SDK用法大同小异。引入依赖之后最核心的API只有五个连接、发布、订阅、ack、取消订阅。生产者的代码非常简单HermesClient client HermesClient.builder() .endpoints(192.168.1.11:8765, 192.168.1.12:8765) .build(); // 发布一条订单创建事件 PublishResult result client.publish(order.created, {\orderId\: 123456, \amount\: 99.5}.getBytes());这里有个细节SDK自己会从两个endpoint中感知哪一个当前是集群leader所以生产端只需要配置所有节点不需要关心选主逻辑。我当时图省事只填了一个节点地址结果那个节点重启后生产端报了一堆连接拒绝我才意识到这个自动感知机制的用处。消费者订阅只需要实现一个回调接口client.subscribe(order.created, message - { String payload new String(message.getPayload()); System.out.println(收到订单事件: payload); // 业务处理完成之后必须调ack message.ack(); });这段代码看起来简单但message.ack()这个调用一定要放在业务处理成功之后。我见过同事把ack放在try块的第一行消息瞬间从队列里被消费掉后面处理过程异常导致数据对不上排查了半天才查出真相。这种问题我在后面踩坑部分会详细讲。4. 压测结果与性能调优路径4.1 测试环境与我的压测方法压测环境我用的是3台4核8GB的云主机系统是Ubuntu 22.04磁盘就是普通的云盘并没有用SSD。压测工具用的是团队原来就有的一个消息压测脚本可以按固定速率发消息也可以打满压力直到系统吞吐不再上升。我关注的核心指标有四个每秒处理消息数TPS端到端延时P99从生产者发消息到消费者收到消息消费积压数量消息队列里未确认的数量进程的内存占用和CPU占用压测流程是固定的先向pressure.topic这个topic以不同速率发布消息同时起一个推模式消费者消费消息并记录延时。每条消息体大概256字节模拟典型的事件通知场景。4.2 基线数据单节点到底能扛多大流量我压测得到的一组数据可以说是直观地展示了这个轻量级代理的实际能力发布速率消费端P99延时积压情况CPU占用5,000 msg/s12ms无积压约35%10,000 msg/s15ms无积压约60%20,000 msg/s28ms轻微积压约85%50,000 msg/s120ms明显积压打满单节点在4核8GB的配置下稳定支撑每秒1万条消息是没问题的P99延时控制在20ms以内。如果业务流量长期超过这个水平我会建议拆topic或者水平拆分部署而不是死磕单节点。顺带一提压测到接近极限时我注意到一个有趣的现象延时曲线刚开始并没有明显恶化直到积压消息量超过内存通道容量后P99才开始直线上升。这说明内存环形的容量设计是决定延时的关键。4.3 调优核心参数channel buffer 和 consumer concurrency如果你的场景和我一样需要提高单节点的处理能力最先应该调的两个参数是channel.buffer_size和消费者的并发度。channel.buffer_size默认是10240在内存环形的概念里它表示未消费的消息在这个缓冲区里最多可以存多少条。如果消费者消费速度跟得上这个缓冲区大部分时间都是空的设大了也没用。但消费速度跟不上、而生产者又是突发流量时缓冲区大一点就能多一层缓冲不至于直接触发流控把生产端阻塞住。消费者并发度的调整取决于你的消费逻辑是CPU密集型还是I/O密集型。我压测时发现对于每个消费回调都要访问一次数据库的业务I/O密集型并发度从默认的8调到32整体吞吐提升了近2倍。对于纯计算逻辑则没有必要调高因为CPU核数就这么几个并发再多也只是增加上下文切换。另外还有一个很重要的参数是delivery.batch_timeout_ms它控制服务端在推模式下聚合多长时间的消息再统一推给客户端。默认值是0代表来一条推一条实时性最好。如果你想提高吞吐可以把它调到5ms意思是每5ms聚合一次消息再推。调这个参数可以把吞吐拉升30%左右代价是端到端延时增加了大约2到5ms。4.4 内存和GC层面的优化手段hermes-agent 是Go写的本身有GC机制但不代表我们可以完全不管内存。压测时我观察到内存占用有一个很明显的锯齿波动GC之后内存瞬间下降这个抖动在极端情况下会影响尾延迟。我做的优化方案很简单限制进程内存上限给Go运行时设置GC目标的参数。具体做法是配置环境变量export GOGC200这只告诉Go运行时当堆内存增长为上次GC后的两倍时才触发新一轮GC。这样做之后GC次数减少了一半代价是峰值内存高了一些但对延时曲线的稳定性提升比较明显。另一个偏移内存的窍门是把storage.path指向一台内存盘tmpfs在测试环境会把消息落盘延时的抖动降为零。但生产环境不建议这样做因为重启后内存盘数据全没了和消息可靠性原则相违背。5. 生产环境踩坑记录5.1 消息不翼而飞WAL刷盘参数引发的丢数据问题这个事故发生在我接入hermes-agent的第二周。某天早上我们按照计划重启了一台生产服务器结果重启完成后部分消费方反馈说凌晨有一批订单通知没有收到。业务方明明确认过凌晨有生成订单但消费端日志里就是找不到对应的通知。我先是怀疑消费者代码漏处理了排查了一圈没有任何问题。然后开始查hermes-agent的日志发现重启时间点之前的WAL日志文件里确实有几十条消息的写入记录但没有对应的ack记录。仔细看源码之后才意识到问题的根因是wal.fsync_interval的默认值50ms在搞鬼。这50ms的意思其实是每50ms才把内存中的日志缓冲区强制刷到磁盘。如果进程是在上一次刷盘之后、下一次刷盘之前崩溃或重启的那这50ms窗口内积攒的消息就会丢失。我们重启时恰好有几十条消息落在这个窗口里。修复方式不复杂把wal.fsync_interval从50ms改成10ms最多丢10ms的数据对性能的影响在压测里几乎看不出来。这个坑的真正教训是任何消息系统在默认参数下都不能想当然地认为是“不丢消息”的尤其是出现进程重启这种非正常场景时必须搞清楚刷盘语义和窗口。5.2 重复消费ack时序和客户端崩溃的连锁反应丢了消息的问题刚解决不久我们又撞上了重复消息的坑。现象是有个积分服务偶尔会给用户发双倍积分我翻日志发现同一条消息被消费了两次。这个问题的根因不在hermes-agent本身而在消费者的ack时序。我们的消费回调里先更新数据库然后调用message.ack()。看起来没毛病但有一个隐患如果数据库更新成功之后、ack到达hermes-agent之前客户端进程刚好崩溃了那这条消息在hermes-agent看来就是超时未确认会被重新投递。还有另一种情况更容易被忽略消费者在ack网络传输中丢失了hermes-agent等待超时后重试投递同样导致重复消费。这不是hermes-agent单独的问题而是所有at-least-once投递语义的消息系统都必须面对的问题。解决思路是幂等。我在消费端引入了业务ID去重表每次消费前先查这个ID是否已经处理过处理过就直接ack跳过。去重表不需要长期保留24小时足够因为消息重试失败的deadletter队列需要人工介入那个人工操作会接受同样的幂等检查。想了一想如果你的业务比较重要建议从一开始就设计好消费幂等不要等到线上出问题了再来补。这是消息系统使用中最容易忽略、代价又最高的一件事。5.3 集群脑裂网络分区导致双主接管这个坑是在我们上集群模式之后遇到的。某次机房网络抖动三节点集群中的两个节点之间网络中断但它们都能和第三个节点通信。Raft协议在这种情况下会有一个分裂的风险旧leader所在的区域如果不能形成大多数就会自动退位但网络分区两边都以为自己还有足够多节点就可能选出两个leader。因为我们当时配置有些问题确实出现了“精神分裂”的双主现象。危险之处在于两个leader同时接收生产者的写入消息就会分叉。消费端可能从其中一个leader拉到消息A而另一个分区里又拉不到最终造成数据不一致。排查过程比较折磨。我先确认了三个进程都在运行端口也正常但集群状态API显示的leader地址在不同节点上不一致。后来查配置才发现原因是我们三节点里有一个节点的node_id配置重复了导致Raft的节点身份出现了混乱在网络抖动时无法正确识别大多数节点。把node_id改成唯一值之后脑裂消失集群恢复了单leader的正常状态。这个教训也很明显分布式系统的配置必须严格规范一个看似不起眼的重复配置都可能让整个一致性协议失效。网络分区本身无法杜绝但配置正确至少能让Raft在分区后更快收敛、不会出现双主。5.4 排查链路的心得从现象到根因的四个步骤踩过这些坑之后我慢慢形成了一套排查hermes-agent问题的固定链路遇到类似情况你可以照着查先看节点之间心跳是否正常用命令查每个节点的角色和leader状态确认没有脑裂再查消息的ack状态分布通过API直接查看pending、delivering、acked、deadletter四个状态各有多少消息判断卡在哪个环节确认WAL刷盘参数和消息落盘时延排除进程重启导致丢消息的可能最后看消费端的处理耗时和是否有异常抛出特别关注ack是否真的被调用到这套链路帮我在很多次报警中快速定位问题也让我意识到一个核心思想对于消息系统不要凭感觉猜要把状态数据调出来看答案基本都在数据里。6. 实际运行半年后的体会与扩展方向她运行了半年多稳定性整体是让人放心的。唯一的一次非计划宕机还是因为底层服务器硬件故障好在集群模式自动切换了leader业务侧完全没有感知。如果让我给后来的使用者提个建议我希望你认真确认自己的场景是否真的适合这种轻量级方案。如果你只是需要把服务间的事件通知从“定时轮询接口”升级为“事件驱动”hermes-agent 的复杂度几乎是最佳平衡点。如果你的业务未来预期会有爆发式增长或者有严格的消息归档审计需求那还是提前评估迁移到更专业消息中间件的成本更稳妥。把消费端的幂等设计、集群node_id的唯一性、WAL刷盘参数这几件事在初始阶段就做好后面能省掉很多半夜被报警吵醒的麻烦。我看到消息处理失败不用担心deadletter队列里的信息足够详细结合自带的管理API把积压消息人工重放一遍也就是几分钟的事。对我来说一个工具好不好的标准从来不是功能多不多而是它是否在自己的适用范围内做到极致。hermes-agent 就是一个愿意承认自己“只做好轻量消息投递这一件事”的项目而恰恰是这种克制让它在实际使用中显得格外顺手。
