中断的启示：为什么CPU不用轮询
如果CPU用轮询方式检查每个设备是否有数据——现代计算机早完蛋了。别笑，轮询在软件世界里还很常见。你写的那个每秒查数据库的cron job，就是典型的轮询。发布订阅，说白了，就是软件系统中的中断机制。
事件发生时，生产者只管喊一嗓子，总线负责把消息丢给所有竖起耳朵的消费者。消费者是谁、有几个、在哪儿，生产者完全不用管。这就是解耦。但背后的实现呢？就拿Linux内核的kqueue和epoll来说，它们是发布订阅在文件描述符上的实践。当你调用epoll_wait，进程被挂起，直到有事件通知。这种机制，避免了CPU时间耗在无意义的“有事儿吗？没事儿”的循环上。我把这种模式称为“等事件”vs“问事件”。数据表明，一个10000个fd的服务，用epoll比用select（轮询实现的代表）在活跃连接数10%时，CPU使用率能降低80%以上。这就是中断替代轮询的威力。
不过话说回来，真正的发布订阅系统比epoll复杂得多。加入网络、分布式、消息持久化，立刻涌现出一堆问题。但核心思想没变：别傻等，等通知。
压测实录：用数据扇轮询一耳光
我特意搭了个环境：一台32核64G的服务器，模拟10000个客户端，每个客户端每秒产生1条消息。分别用HTTP轮询（每秒请求一次看有没有新消息）和基于NATS的发布订阅。结果？轮询方案在2000客户端时就出现了明显延迟，CPU idle只剩15%。而NATS，撑到10000客户端，CPU idle还有60%，消息延迟中位数1.2毫秒。轮询呢？延迟直接飙到800毫秒，还有30%的请求超时。看到这个数据我差点乐出声——轮询被按在地上摩擦。
为什么差距这么大？轮询的本质是“无事件也要空转”，白白消耗连接和计算资源。发布订阅则利用连接复用和异步推送，消费者只需维护一个长连接，消息来了直接推送。这就像你去餐厅，一个是每隔两分钟去前台问‘我的菜好了吗’，另一个是等着服务员端上来。谁更有效率，不言自明。当然，发布订阅也不是银弹，当消息生产速度远大于消费速度时，系统会面临背压——这是下节要说的坑。
差点删库的三个坑，以及怎么爬出来
坑一：消息悄悄丢了。那晚我正要睡觉，告警响了：订单状态不更新。一查，Redis Streams里消息堆积为零，但消费者却没收到。怎么回事？原来某个消费者组确认消息后，消息被删除了，但消费者实际处理失败。解决：业务逻辑做幂等，同时配置消息重试队列，消费失败不确认，转移到死信队列人工介入。别用Redis Pub/Sub做重要业务，它不持久。
坑二：消费速度不对等，系统雪崩。双十一零点，流量暴增。生产者每秒10万条，消费者每秒只能处理1万条。消息积压到磁盘满，整个集群失去响应。解决：引入分区（Partition）和消费者组。把主题分成N个分区，每个消费者组的一个实例消费一个分区，线性扩展。同时设置消息过期时间，避免磁盘爆满。
坑三：选型不慎，性能跳崖。当初觉得RabbitMQ简单易用，插件多，用它的fanout交换做发布订阅。结果发现，当绑定队列很多时，RabbitMQ的CPU飙升，因为它是逐个队列投递消息的。换成Kafka后，通过顺序写磁盘和零拷贝，吞吐量直接翻百倍。教训：评估发布订阅中间件时，一定要看它的投递机制——是广播到每个消费者还是可分区并行，这决定了水平扩展能力。
这些坑，每一个我都交了学费。现在线上稳稳的，回头看看，都是成长。
说到底，发布订阅不是什么新概念。它就是事件驱动架构的心跳。别再用轮询给服务器添堵了。真的。
