1. 从一个被问烂了的问题说起buzz 到底指什么如果你在技术社区或者产品圈子里待过一阵子一定遇到过这种场景有人抛出一个词——buzz然后底下立刻分成两派。一派说这是消息队列里的消息总线另一派说这是营销圈里的口碑传播效应还有一派干脆把它当成某个具体开源项目的代号。三派各说各话谁也说服不了谁。我自己第一次被这个词绊住是在帮一个朋友梳理他的后端架构文档时。他在文档里写了一句“所有事件统一走 buzz 层”我看完之后第一反应是你说的 buzz 是 Kafka 那种消息中间件还是你们内部自研的一个转发服务他愣了两秒说“就是那个 buzz 啊”。这个对话让我意识到buzz 这个词之所以容易造成沟通成本不是因为它冷门恰恰是因为它太常见、太泛化在不同语境下指向完全不同的东西。所以这篇内容我想做的事情很明确把 buzz 这个词在不同技术语境下的真实含义拆开讲清楚重点放在它作为“消息/事件流转中枢”这一层含义上因为这是绝大多数开发者在实际项目里会碰到的场景。同时我也会覆盖它在产品传播语境下的那层意思因为很多做增长、做运营的读者搜这个词想找的其实是那一块。整篇内容适合后端开发、架构设计、以及对系统间通信机制感兴趣的技术人员也适合产品经理和运营同学用来对齐术语。需要先说明一点buzz 本身并不是一个像 Redis、Nginx 那样有唯一官方定义的标准技术名词。它更像是一个“约定俗成的叫法”不同团队、不同项目给它赋予的含义可能不一样。我下面讲的内容是基于行业内常见的几种用法来展开的如果你所在团队对 buzz 有自己特定的定义以你们团队的为准我讲的是通用语境下最可能遇到的那几种情况。2. buzz 作为消息流转中枢它到底解决了什么问题2.1 为什么系统里需要一个“buzz 层”先从一个最朴素的场景讲起。假设你有一个电商系统用户下单之后需要做这么几件事扣减库存、生成订单记录、发短信通知用户、给推荐系统喂一条行为数据、更新用户的积分。最原始的做法是在下单接口里按顺序把这些逻辑全写一遍代码大概长这样def create_order(user_id, item_id): deduct_stock(item_id) save_order(user_id, item_id) send_sms(user_id) feed_recommend(user_id, item_id) update_points(user_id) return {status: ok}这段代码在业务简单的时候跑得挺好但它有几个致命问题。第一任何一个环节挂了整个下单就失败了比如短信服务抽风用户明明下单成功却看到报错。第二加一个新需求就得改这个函数比如产品说“下单后还要给用户发一张优惠券”你又得往里面塞一行。第三各个逻辑耦合在一起库存团队想改自己的扣减逻辑得跟订单团队协调发布节奏。buzz 层要解决的就是这个问题。它的核心思路是下单接口只负责一件事——把“用户下单了”这个事实广播出去至于谁关心这个事实、关心之后要做什么由各个下游服务自己去订阅和处理。下单接口变成这样def create_order(user_id, item_id): order_event {type: order_created, user_id: user_id, item_id: item_id} buzz.publish(order_created, order_event) return {status: ok}库存服务订阅order_created收到之后扣库存短信服务订阅同一个事件收到之后发短信推荐服务也订阅收到之后喂数据。新增优惠券逻辑优惠券服务自己订阅一下就行下单接口一行都不用改。这就是 buzz 层最核心的价值把“发生了什么”和“发生后要做什么”解耦。发布者只管发布事实订阅者只管处理自己关心的事实双方互不感知对方的存在。2.2 消息总线、事件总线、消息队列这几个词到底怎么区分很多人把 buzz 层和消息队列混为一谈其实它们不是一回事。我用一个生活化的类比来解释。消息队列Message Queue像是一个快递柜。你寄一个包裹放进去快递员取走包裹就没了。它强调的是“点对点”的传递一个消息被一个消费者消费掉就结束了。典型的代表是 RabbitMQ 的普通队列模式。消息总线Message Bus像是一个广播电台。电台发出一个信号所有调到这个频道的收音机都能收到。它强调的是“一对多”的广播一个消息可以被多个订阅者同时收到。Kafka 在发布订阅模式下就扮演这个角色。事件总线Event Bus和消息总线非常接近区别更多在语义层面。事件总线强调的是“事件”——已经发生的事实比如“订单已创建”“用户已注册”它天然带有“不可变”和“已发生”的含义。消息总线则更中性消息可以是命令“请扣减库存”也可以是事件“库存已扣减”。buzz 这个词在实际使用中通常指的是后两者——一个支持一对多广播的事件/消息流转中枢。它底层可能用 Kafka 实现可能用 RabbitMQ 的 fanout 交换机实现也可能是团队自研的一个轻量级转发服务。所以当你听到有人说“走 buzz”你要问清楚的是这个 buzz 底层是什么是广播还是点对点消息有没有持久化消费失败怎么处理。2.3 一个真实的 buzz 层选型对比我在几个项目里分别用过不同的方案来做 buzz 层这里把关键维度的对比整理出来方便你选型时参考。方案吞吐量消息持久化消费模式运维复杂度适用场景Kafka极高支持可回溯发布订阅 消费组高大数据量、需要回溯、多消费者RabbitMQ中等支持消费后删除点对点 发布订阅中业务解耦、任务分发Redis Pub/Sub高不支持纯发布订阅低实时通知、允许丢消息Redis Stream高支持发布订阅 消费组低轻量级、想省运维成本自研 HTTP 转发低看实现看实现低内部小规模、快速上线选型的时候最容易踩的坑是“上来就选 Kafka”。Kafka 确实强大但它的运维成本不低分区规划、副本配置、消费者组 rebalance 这些问题在小团队里很容易变成负担。我个人的经验是如果日均消息量在百万级以下且不需要消息回溯Redis Stream 或者 RabbitMQ 完全够用没必要为了“看起来专业”去上 Kafka。等业务量真的涨上来了再迁移也不迟前提是你一开始就把发布和订阅的接口抽象好底层换实现的时候上层代码不用动。3. 把 buzz 层落地从接口设计到消费幂等3.1 发布订阅接口应该长什么样一个设计得好的 buzz 层接口应该让调用方感觉不到底层用的是 Kafka 还是 Redis。我通常会把接口抽象成三个方法class BuzzClient: def publish(self, topic: str, event: dict, key: str None): 发布一个事件到指定主题 pass def subscribe(self, topic: str, handler: callable, group: str None): 订阅一个主题handler 是处理函数 pass def ack(self, message): 确认消息已处理 pass这里有几个设计细节值得展开说。topic 的命名规范。我见过太多项目把 topic 命名得乱七八糟有的叫order有的叫order_created有的叫ORDER_CREATE_EVENT。建议统一用“领域.实体.动作”的格式比如order.order.created、user.account.registered。这样一眼就能看出这个事件属于哪个领域、涉及哪个实体、发生了什么动作。命名统一之后订阅方在配置订阅关系的时候也不容易搞错。key 的作用。key 决定了消息被分配到哪个分区如果底层是 Kafka或者哪个消费组如果底层是 Redis Stream。同一个 key 的消息会被同一个消费者处理这对于需要保证顺序的场景很关键。比如订单相关的所有事件都用order_id作为 key那么同一个订单的创建、支付、发货事件就会按顺序被同一个消费者处理不会出现“先收到发货事件再收到创建事件”这种乱序问题。事件体的结构。我建议所有事件都带上这几个字段event_id全局唯一用于幂等、event_type事件类型、timestamp发生时间、payload业务数据。event_id尤其重要后面讲幂等的时候会用到。3.2 消费端最容易忽略的幂等处理消息系统有一个绕不开的问题消息可能被重复投递。这不是 bug而是分布式系统的固有特性。网络抖动导致 ack 丢失、消费者处理完但还没来得及提交 offset 就挂了、Kafka 的 rebalance 导致部分消息被重新消费——这些情况都会造成同一条消息被处理两次。如果你的消费逻辑不是幂等的重复消费就会出问题。比如扣库存重复消费一次就多扣一次用户明明只买了一件库存扣了两件。这种问题在生产环境里非常隐蔽往往要等到对账的时候才发现。处理幂等的标准做法是在消费端维护一张去重表。每次处理消息之前先拿event_id去表里查一下如果已经处理过就直接跳过没处理过就处理并记录。def handle_order_created(event): event_id event[event_id] if dedup_table.exists(event_id): return # 已经处理过直接跳过 # 处理业务逻辑 deduct_stock(event[payload][item_id]) # 记录已处理 dedup_table.set(event_id, ttl86400)去重表的 TTL 设置多久合适这取决于你的业务能容忍多长时间内的重复。一般来说设 24 小时就够了因为消息重投通常发生在几分钟内超过一天还重投的情况极其罕见。如果底层是 Redis直接用 SETNX 加过期时间就行性能足够。注意去重表的写入和业务逻辑的处理必须在同一个事务里或者至少保证“业务处理成功”和“去重记录写入”这两个操作要么都成功要么都失败。否则可能出现业务处理了但去重记录没写进去下次重投又处理一遍的情况。3.3 消费失败之后怎么办重试与死信消息处理失败是常态网络超时、下游服务不可用、数据格式不对都会导致处理失败。这时候不能简单地把消息丢掉也不能无限重试把消费者卡死。我的做法是分三级处理第一级立即重试。对于网络抖动这类瞬时故障立即重试一两次通常就能成功。重试的时候加一个短暂的 sleep比如 100 毫秒避免瞬间打爆下游。第二级延迟重试。如果立即重试还是失败把消息投递到一个延迟队列比如 30 秒后再试。延迟重试的次数设个上限比如 3 次。每次重试的间隔可以递增30 秒、2 分钟、10 分钟。第三级死信队列。超过重试上限的消息进入死信队列不再自动处理而是触发告警由人工介入排查。死信队列里的消息要保留完整的上下文包括原始消息体、失败原因、重试次数方便排查。def consume_with_retry(message): try: handle(message) except TransientError: if message.retry_count 3: delay_queue.push(message, delay30 * (2 ** message.retry_count)) else: dead_letter_queue.push(message, reasonmax retry exceeded) alert(消息进入死信队列, message) except PermanentError: dead_letter_queue.push(message, reasonpermanent error) alert(消息处理永久失败, message)这里的关键是区分“瞬时错误”和“永久错误”。瞬时错误值得重试永久错误重试多少次都没用直接进死信队列。怎么区分通常靠异常类型来判断比如网络超时是瞬时错误数据格式解析失败是永久错误。这个判断逻辑需要根据你的业务场景来定没有通用答案。4. buzz 在增长语境下的另一层含义4.1 口碑传播里的 buzz 是什么前面讲的都是技术层面的 buzz但如果你是在做产品增长、社区运营搜这个词的时候想找的可能是另一层意思buzz 指的是用户之间自发的口碑传播效应。这个概念的核心逻辑是当你的产品好到一定程度用户会主动跟身边的人提起它这种“口口相传”带来的传播效果比任何广告投放都更可信、成本更低。营销圈里常说的“制造 buzz”就是指通过一系列手段让用户愿意主动讨论你的产品。和技术层面的 buzz 相比这层含义更偏策略和运营但两者有一个共同点都强调“广播”和“扩散”。技术上的 buzz 是把一个事件广播给多个订阅者增长上的 buzz 是把一个信息扩散给多个潜在用户。理解了这一点你会发现这两个概念在底层逻辑上是相通的。4.2 制造 buzz 的几个可操作抓手如果你确实在做增长相关的事情想让产品产生口碑传播有几个抓手是经过验证有效的。第一个抓手是“超出预期的细节”。用户不会因为你的产品“符合预期”而主动传播只会因为“超出预期”而传播。比如一个笔记类应用用户以为它只能记文字结果发现它还能自动把语音转成文字并排版这个“没想到还能这样”的瞬间就是传播的触发点。做产品的时候要有意识地设计这种“惊喜时刻”。第二个抓手是“可展示的成果”。用户传播你的产品本质上是在传播“用了这个产品之后的自己”。如果你的产品能让用户产出一些可以展示给别人看的东西传播就会自然发生。比如一个做图工具用户用它做出来的图越好看越有可能分享出去分享的时候自然会带上工具的痕迹。第三个抓手是“低门槛的参与感”。让用户参与进来比让用户被动接受更容易产生传播。比如让用户投票决定下一个功能做什么让用户给产品起个昵称这些参与行为会让用户产生“这是我的产品”的归属感从而更愿意主动推荐。4.3 技术 buzz 和增长 buzz 的交叉点有意思的是技术层面的 buzz 层设计其实会直接影响增长层面的 buzz 效果。举个例子如果你的系统里有一个 buzz 层在实时处理用户行为事件你就能很快知道“用户在什么时刻产生了惊喜感”然后针对性地设计传播触发点。比如你发现用户在“第一次成功导出作品”之后的 5 分钟内分享率最高那你就可以在这个时间点弹出一个分享引导转化率会比随机弹窗高很多。这种“用技术手段捕捉增长机会”的做法前提就是你的 buzz 层能把用户行为事件实时、准确地流转到分析系统。所以如果你既做技术又关心增长我建议你在设计 buzz 层的时候就把“用户行为事件”作为一等公民来对待给它们设计专门的 topic 和消费链路。这些数据后面做增长分析的时候会非常值钱。5. 几个我在实际项目里踩过的坑5.1 消息体过大导致的性能问题有一次我们的 buzz 层突然变慢消费延迟从毫秒级涨到了分钟级。排查了半天发现是某个业务方往事件体里塞了一个完整的商品详情对象包含几十个字段和嵌套结构单条消息大小超过了 1MB。Kafka 对单条消息的大小是有限制的超过之后要么发送失败要么需要调大配置但调大之后又会拖慢整体吞吐。后来我们定了一条规矩事件体里只放 ID 和必要的变更字段不放完整对象。消费方如果需要完整数据拿 ID 自己去查。这样消息体小了吞吐上去了而且避免了“事件里的数据已经过期”的问题。# 不推荐塞完整对象 buzz.publish(order.created, {order: full_order_object}) # 推荐只放 ID 和关键字段 buzz.publish(order.created, {order_id: 123, user_id: 456, amount: 99.0})5.2 消费者组配置不当导致的重复消费Kafka 的消费者组机制有一个特点当消费者数量变化时会触发 rebalance期间所有消费者都会暂停消费等 rebalance 完成后重新分配分区。如果消费者频繁上下线rebalance 就会频繁发生导致大量消息被重复消费。我们当时的场景是消费者部署在 Kubernetes 里Pod 因为资源限制经常被驱逐一被驱逐就触发 rebalance。解决办法是给消费者配置更长的session.timeout.ms和max.poll.interval.ms同时给 Pod 设置合理的资源 request 和 limit避免被频繁驱逐。调整之后rebalance 频率从每小时好几次降到了每天一两次重复消费的问题基本消失了。5.3 订阅关系散落在各处导致的维护困难项目初期每个服务自己写代码订阅自己关心的事件订阅关系散落在各个代码库里。等到需要排查“到底有哪些服务订阅了 order.created 这个事件”的时候没人能说清楚只能一个个代码库去搜。后来我们做了一个改进把所有订阅关系集中到一个配置文件里管理每个服务启动的时候从这个配置里读取自己需要订阅的 topic。这样一眼就能看出全量的订阅关系新增或修改订阅也不用改代码改配置就行。subscriptions: - service: inventory-service topics: - order.order.created - order.order.cancelled - service: notification-service topics: - order.order.created - user.account.registered这个配置文件还可以作为文档使用新同事入职的时候看一眼就知道系统里有哪些事件、谁在消费比看代码快多了。6. 关于 buzz 这个词我最后想说的buzz 这个词之所以让人又爱又恨是因为它足够短、足够顺口所以大家都愿意用但正因为如此它的含义被稀释得很厉害。在技术语境里它可能指消息总线、事件总线、消息队列甚至某个具体的内部服务在增长语境里它指口碑传播效应。你跟不同的人说 buzz对方脑子里浮现的东西可能完全不一样。我的建议是在正式的技术文档和架构讨论里尽量用更精确的词。想说消息总线就说消息总线想说事件驱动就说事件驱动想说口碑传播就说口碑传播。buzz 这个词留在口头交流和非正式场合用就好。如果非要用第一次出现的时候加一句解释比如“本文中的 buzz 层指基于 Kafka 实现的事件总线”能省掉后面很多沟通成本。至于技术上的 buzz 层怎么落地核心就三件事接口抽象好让上层不感知底层实现消费端做好幂等别怕重复投递失败处理分好级瞬时错误重试永久错误进死信。这三件事做好了buzz 层基本就能稳定跑了。剩下的就是根据业务量做容量规划和监控告警那是另一个话题了。
buzz 到底指什么？消息总线、事件总线与口碑传播的完整解析
1. 从一个被问烂了的问题说起buzz 到底指什么如果你在技术社区或者产品圈子里待过一阵子一定遇到过这种场景有人抛出一个词——buzz然后底下立刻分成两派。一派说这是消息队列里的消息总线另一派说这是营销圈里的口碑传播效应还有一派干脆把它当成某个具体开源项目的代号。三派各说各话谁也说服不了谁。我自己第一次被这个词绊住是在帮一个朋友梳理他的后端架构文档时。他在文档里写了一句“所有事件统一走 buzz 层”我看完之后第一反应是你说的 buzz 是 Kafka 那种消息中间件还是你们内部自研的一个转发服务他愣了两秒说“就是那个 buzz 啊”。这个对话让我意识到buzz 这个词之所以容易造成沟通成本不是因为它冷门恰恰是因为它太常见、太泛化在不同语境下指向完全不同的东西。所以这篇内容我想做的事情很明确把 buzz 这个词在不同技术语境下的真实含义拆开讲清楚重点放在它作为“消息/事件流转中枢”这一层含义上因为这是绝大多数开发者在实际项目里会碰到的场景。同时我也会覆盖它在产品传播语境下的那层意思因为很多做增长、做运营的读者搜这个词想找的其实是那一块。整篇内容适合后端开发、架构设计、以及对系统间通信机制感兴趣的技术人员也适合产品经理和运营同学用来对齐术语。需要先说明一点buzz 本身并不是一个像 Redis、Nginx 那样有唯一官方定义的标准技术名词。它更像是一个“约定俗成的叫法”不同团队、不同项目给它赋予的含义可能不一样。我下面讲的内容是基于行业内常见的几种用法来展开的如果你所在团队对 buzz 有自己特定的定义以你们团队的为准我讲的是通用语境下最可能遇到的那几种情况。2. buzz 作为消息流转中枢它到底解决了什么问题2.1 为什么系统里需要一个“buzz 层”先从一个最朴素的场景讲起。假设你有一个电商系统用户下单之后需要做这么几件事扣减库存、生成订单记录、发短信通知用户、给推荐系统喂一条行为数据、更新用户的积分。最原始的做法是在下单接口里按顺序把这些逻辑全写一遍代码大概长这样def create_order(user_id, item_id): deduct_stock(item_id) save_order(user_id, item_id) send_sms(user_id) feed_recommend(user_id, item_id) update_points(user_id) return {status: ok}这段代码在业务简单的时候跑得挺好但它有几个致命问题。第一任何一个环节挂了整个下单就失败了比如短信服务抽风用户明明下单成功却看到报错。第二加一个新需求就得改这个函数比如产品说“下单后还要给用户发一张优惠券”你又得往里面塞一行。第三各个逻辑耦合在一起库存团队想改自己的扣减逻辑得跟订单团队协调发布节奏。buzz 层要解决的就是这个问题。它的核心思路是下单接口只负责一件事——把“用户下单了”这个事实广播出去至于谁关心这个事实、关心之后要做什么由各个下游服务自己去订阅和处理。下单接口变成这样def create_order(user_id, item_id): order_event {type: order_created, user_id: user_id, item_id: item_id} buzz.publish(order_created, order_event) return {status: ok}库存服务订阅order_created收到之后扣库存短信服务订阅同一个事件收到之后发短信推荐服务也订阅收到之后喂数据。新增优惠券逻辑优惠券服务自己订阅一下就行下单接口一行都不用改。这就是 buzz 层最核心的价值把“发生了什么”和“发生后要做什么”解耦。发布者只管发布事实订阅者只管处理自己关心的事实双方互不感知对方的存在。2.2 消息总线、事件总线、消息队列这几个词到底怎么区分很多人把 buzz 层和消息队列混为一谈其实它们不是一回事。我用一个生活化的类比来解释。消息队列Message Queue像是一个快递柜。你寄一个包裹放进去快递员取走包裹就没了。它强调的是“点对点”的传递一个消息被一个消费者消费掉就结束了。典型的代表是 RabbitMQ 的普通队列模式。消息总线Message Bus像是一个广播电台。电台发出一个信号所有调到这个频道的收音机都能收到。它强调的是“一对多”的广播一个消息可以被多个订阅者同时收到。Kafka 在发布订阅模式下就扮演这个角色。事件总线Event Bus和消息总线非常接近区别更多在语义层面。事件总线强调的是“事件”——已经发生的事实比如“订单已创建”“用户已注册”它天然带有“不可变”和“已发生”的含义。消息总线则更中性消息可以是命令“请扣减库存”也可以是事件“库存已扣减”。buzz 这个词在实际使用中通常指的是后两者——一个支持一对多广播的事件/消息流转中枢。它底层可能用 Kafka 实现可能用 RabbitMQ 的 fanout 交换机实现也可能是团队自研的一个轻量级转发服务。所以当你听到有人说“走 buzz”你要问清楚的是这个 buzz 底层是什么是广播还是点对点消息有没有持久化消费失败怎么处理。2.3 一个真实的 buzz 层选型对比我在几个项目里分别用过不同的方案来做 buzz 层这里把关键维度的对比整理出来方便你选型时参考。方案吞吐量消息持久化消费模式运维复杂度适用场景Kafka极高支持可回溯发布订阅 消费组高大数据量、需要回溯、多消费者RabbitMQ中等支持消费后删除点对点 发布订阅中业务解耦、任务分发Redis Pub/Sub高不支持纯发布订阅低实时通知、允许丢消息Redis Stream高支持发布订阅 消费组低轻量级、想省运维成本自研 HTTP 转发低看实现看实现低内部小规模、快速上线选型的时候最容易踩的坑是“上来就选 Kafka”。Kafka 确实强大但它的运维成本不低分区规划、副本配置、消费者组 rebalance 这些问题在小团队里很容易变成负担。我个人的经验是如果日均消息量在百万级以下且不需要消息回溯Redis Stream 或者 RabbitMQ 完全够用没必要为了“看起来专业”去上 Kafka。等业务量真的涨上来了再迁移也不迟前提是你一开始就把发布和订阅的接口抽象好底层换实现的时候上层代码不用动。3. 把 buzz 层落地从接口设计到消费幂等3.1 发布订阅接口应该长什么样一个设计得好的 buzz 层接口应该让调用方感觉不到底层用的是 Kafka 还是 Redis。我通常会把接口抽象成三个方法class BuzzClient: def publish(self, topic: str, event: dict, key: str None): 发布一个事件到指定主题 pass def subscribe(self, topic: str, handler: callable, group: str None): 订阅一个主题handler 是处理函数 pass def ack(self, message): 确认消息已处理 pass这里有几个设计细节值得展开说。topic 的命名规范。我见过太多项目把 topic 命名得乱七八糟有的叫order有的叫order_created有的叫ORDER_CREATE_EVENT。建议统一用“领域.实体.动作”的格式比如order.order.created、user.account.registered。这样一眼就能看出这个事件属于哪个领域、涉及哪个实体、发生了什么动作。命名统一之后订阅方在配置订阅关系的时候也不容易搞错。key 的作用。key 决定了消息被分配到哪个分区如果底层是 Kafka或者哪个消费组如果底层是 Redis Stream。同一个 key 的消息会被同一个消费者处理这对于需要保证顺序的场景很关键。比如订单相关的所有事件都用order_id作为 key那么同一个订单的创建、支付、发货事件就会按顺序被同一个消费者处理不会出现“先收到发货事件再收到创建事件”这种乱序问题。事件体的结构。我建议所有事件都带上这几个字段event_id全局唯一用于幂等、event_type事件类型、timestamp发生时间、payload业务数据。event_id尤其重要后面讲幂等的时候会用到。3.2 消费端最容易忽略的幂等处理消息系统有一个绕不开的问题消息可能被重复投递。这不是 bug而是分布式系统的固有特性。网络抖动导致 ack 丢失、消费者处理完但还没来得及提交 offset 就挂了、Kafka 的 rebalance 导致部分消息被重新消费——这些情况都会造成同一条消息被处理两次。如果你的消费逻辑不是幂等的重复消费就会出问题。比如扣库存重复消费一次就多扣一次用户明明只买了一件库存扣了两件。这种问题在生产环境里非常隐蔽往往要等到对账的时候才发现。处理幂等的标准做法是在消费端维护一张去重表。每次处理消息之前先拿event_id去表里查一下如果已经处理过就直接跳过没处理过就处理并记录。def handle_order_created(event): event_id event[event_id] if dedup_table.exists(event_id): return # 已经处理过直接跳过 # 处理业务逻辑 deduct_stock(event[payload][item_id]) # 记录已处理 dedup_table.set(event_id, ttl86400)去重表的 TTL 设置多久合适这取决于你的业务能容忍多长时间内的重复。一般来说设 24 小时就够了因为消息重投通常发生在几分钟内超过一天还重投的情况极其罕见。如果底层是 Redis直接用 SETNX 加过期时间就行性能足够。注意去重表的写入和业务逻辑的处理必须在同一个事务里或者至少保证“业务处理成功”和“去重记录写入”这两个操作要么都成功要么都失败。否则可能出现业务处理了但去重记录没写进去下次重投又处理一遍的情况。3.3 消费失败之后怎么办重试与死信消息处理失败是常态网络超时、下游服务不可用、数据格式不对都会导致处理失败。这时候不能简单地把消息丢掉也不能无限重试把消费者卡死。我的做法是分三级处理第一级立即重试。对于网络抖动这类瞬时故障立即重试一两次通常就能成功。重试的时候加一个短暂的 sleep比如 100 毫秒避免瞬间打爆下游。第二级延迟重试。如果立即重试还是失败把消息投递到一个延迟队列比如 30 秒后再试。延迟重试的次数设个上限比如 3 次。每次重试的间隔可以递增30 秒、2 分钟、10 分钟。第三级死信队列。超过重试上限的消息进入死信队列不再自动处理而是触发告警由人工介入排查。死信队列里的消息要保留完整的上下文包括原始消息体、失败原因、重试次数方便排查。def consume_with_retry(message): try: handle(message) except TransientError: if message.retry_count 3: delay_queue.push(message, delay30 * (2 ** message.retry_count)) else: dead_letter_queue.push(message, reasonmax retry exceeded) alert(消息进入死信队列, message) except PermanentError: dead_letter_queue.push(message, reasonpermanent error) alert(消息处理永久失败, message)这里的关键是区分“瞬时错误”和“永久错误”。瞬时错误值得重试永久错误重试多少次都没用直接进死信队列。怎么区分通常靠异常类型来判断比如网络超时是瞬时错误数据格式解析失败是永久错误。这个判断逻辑需要根据你的业务场景来定没有通用答案。4. buzz 在增长语境下的另一层含义4.1 口碑传播里的 buzz 是什么前面讲的都是技术层面的 buzz但如果你是在做产品增长、社区运营搜这个词的时候想找的可能是另一层意思buzz 指的是用户之间自发的口碑传播效应。这个概念的核心逻辑是当你的产品好到一定程度用户会主动跟身边的人提起它这种“口口相传”带来的传播效果比任何广告投放都更可信、成本更低。营销圈里常说的“制造 buzz”就是指通过一系列手段让用户愿意主动讨论你的产品。和技术层面的 buzz 相比这层含义更偏策略和运营但两者有一个共同点都强调“广播”和“扩散”。技术上的 buzz 是把一个事件广播给多个订阅者增长上的 buzz 是把一个信息扩散给多个潜在用户。理解了这一点你会发现这两个概念在底层逻辑上是相通的。4.2 制造 buzz 的几个可操作抓手如果你确实在做增长相关的事情想让产品产生口碑传播有几个抓手是经过验证有效的。第一个抓手是“超出预期的细节”。用户不会因为你的产品“符合预期”而主动传播只会因为“超出预期”而传播。比如一个笔记类应用用户以为它只能记文字结果发现它还能自动把语音转成文字并排版这个“没想到还能这样”的瞬间就是传播的触发点。做产品的时候要有意识地设计这种“惊喜时刻”。第二个抓手是“可展示的成果”。用户传播你的产品本质上是在传播“用了这个产品之后的自己”。如果你的产品能让用户产出一些可以展示给别人看的东西传播就会自然发生。比如一个做图工具用户用它做出来的图越好看越有可能分享出去分享的时候自然会带上工具的痕迹。第三个抓手是“低门槛的参与感”。让用户参与进来比让用户被动接受更容易产生传播。比如让用户投票决定下一个功能做什么让用户给产品起个昵称这些参与行为会让用户产生“这是我的产品”的归属感从而更愿意主动推荐。4.3 技术 buzz 和增长 buzz 的交叉点有意思的是技术层面的 buzz 层设计其实会直接影响增长层面的 buzz 效果。举个例子如果你的系统里有一个 buzz 层在实时处理用户行为事件你就能很快知道“用户在什么时刻产生了惊喜感”然后针对性地设计传播触发点。比如你发现用户在“第一次成功导出作品”之后的 5 分钟内分享率最高那你就可以在这个时间点弹出一个分享引导转化率会比随机弹窗高很多。这种“用技术手段捕捉增长机会”的做法前提就是你的 buzz 层能把用户行为事件实时、准确地流转到分析系统。所以如果你既做技术又关心增长我建议你在设计 buzz 层的时候就把“用户行为事件”作为一等公民来对待给它们设计专门的 topic 和消费链路。这些数据后面做增长分析的时候会非常值钱。5. 几个我在实际项目里踩过的坑5.1 消息体过大导致的性能问题有一次我们的 buzz 层突然变慢消费延迟从毫秒级涨到了分钟级。排查了半天发现是某个业务方往事件体里塞了一个完整的商品详情对象包含几十个字段和嵌套结构单条消息大小超过了 1MB。Kafka 对单条消息的大小是有限制的超过之后要么发送失败要么需要调大配置但调大之后又会拖慢整体吞吐。后来我们定了一条规矩事件体里只放 ID 和必要的变更字段不放完整对象。消费方如果需要完整数据拿 ID 自己去查。这样消息体小了吞吐上去了而且避免了“事件里的数据已经过期”的问题。# 不推荐塞完整对象 buzz.publish(order.created, {order: full_order_object}) # 推荐只放 ID 和关键字段 buzz.publish(order.created, {order_id: 123, user_id: 456, amount: 99.0})5.2 消费者组配置不当导致的重复消费Kafka 的消费者组机制有一个特点当消费者数量变化时会触发 rebalance期间所有消费者都会暂停消费等 rebalance 完成后重新分配分区。如果消费者频繁上下线rebalance 就会频繁发生导致大量消息被重复消费。我们当时的场景是消费者部署在 Kubernetes 里Pod 因为资源限制经常被驱逐一被驱逐就触发 rebalance。解决办法是给消费者配置更长的session.timeout.ms和max.poll.interval.ms同时给 Pod 设置合理的资源 request 和 limit避免被频繁驱逐。调整之后rebalance 频率从每小时好几次降到了每天一两次重复消费的问题基本消失了。5.3 订阅关系散落在各处导致的维护困难项目初期每个服务自己写代码订阅自己关心的事件订阅关系散落在各个代码库里。等到需要排查“到底有哪些服务订阅了 order.created 这个事件”的时候没人能说清楚只能一个个代码库去搜。后来我们做了一个改进把所有订阅关系集中到一个配置文件里管理每个服务启动的时候从这个配置里读取自己需要订阅的 topic。这样一眼就能看出全量的订阅关系新增或修改订阅也不用改代码改配置就行。subscriptions: - service: inventory-service topics: - order.order.created - order.order.cancelled - service: notification-service topics: - order.order.created - user.account.registered这个配置文件还可以作为文档使用新同事入职的时候看一眼就知道系统里有哪些事件、谁在消费比看代码快多了。6. 关于 buzz 这个词我最后想说的buzz 这个词之所以让人又爱又恨是因为它足够短、足够顺口所以大家都愿意用但正因为如此它的含义被稀释得很厉害。在技术语境里它可能指消息总线、事件总线、消息队列甚至某个具体的内部服务在增长语境里它指口碑传播效应。你跟不同的人说 buzz对方脑子里浮现的东西可能完全不一样。我的建议是在正式的技术文档和架构讨论里尽量用更精确的词。想说消息总线就说消息总线想说事件驱动就说事件驱动想说口碑传播就说口碑传播。buzz 这个词留在口头交流和非正式场合用就好。如果非要用第一次出现的时候加一句解释比如“本文中的 buzz 层指基于 Kafka 实现的事件总线”能省掉后面很多沟通成本。至于技术上的 buzz 层怎么落地核心就三件事接口抽象好让上层不感知底层实现消费端做好幂等别怕重复投递失败处理分好级瞬时错误重试永久错误进死信。这三件事做好了buzz 层基本就能稳定跑了。剩下的就是根据业务量做容量规划和监控告警那是另一个话题了。
