基于Golang与Redis的事件通知处理方案优化技术问询

问题背景 #

我正尝试用Golang协程（goroutines）结合Redis实现事件存储，解决用户通知发送问题：两类事件message.new和message.read均来自HTTP/S POST请求。规则如下：

• message.new事件需存入队列（若已存在则替换旧事件），10秒后未被message.read触发删除，则发送至notification服务
• message.read事件需删除对应message.new事件

已实现架构 #

• 定义StorageHandler结构体，包含事件通道、Redis客户端等核心组件，通过ProcessTask方法将事件分发至对应通道
• 启动handleMessageNewWorker和handleMessageReadWorker后台协程分别处理两类事件：用Redis存储事件，自定义定时器处理过期逻辑，通过通道实现协程间同步
• 计划优化方向：添加信号量优化协程同步，给事件通道增加缓冲应对突发流量，采用工作池模型提升并发处理能力

技术疑问与解答 #

1. 应采用Redis作为事件仓库向ProcessTask投递事件，还是改用队列组件？ #

优先用Redis原生能力满足需求，没必要额外引入队列组件：

• message.new的“存在则替换+10秒过期”逻辑，直接用Redis的SET key value EX 10命令就能实现（要保证仅不存在时创建用NX参数，要替换则直接覆盖），Redis自带过期机制。还可以开启键空间通知（配置notify-keyspace-events Ex），监听__keyevent@0__:expired事件，事件到期时直接触发通知服务调用，省去自己维护定时器的麻烦
• message.read只需执行DEL key就能删除对应事件，阻止通知发送
• 只有后续业务复杂度升级（比如需要多消费者集群、复杂延迟规则），再考虑引入RabbitMQ、Kafka这类专门队列组件，当前Redis足够轻量且能覆盖需求

2. 现有系统是否可进一步简化，有无遗漏的优化点？ #

可简化的点：

• 砍掉自定义定时器：改用Redis键过期通知，直接监听过期事件触发通知，减少协程中维护定时器的逻辑，降低资源占用
• 精简分发环节：如果ProcessTask只是简单做事件路由，考虑直接在HTTP请求处理函数中调用Redis操作，再通过通道触发后续动作，避免多余的协程分发步骤

遗漏的优化点：

• 幂等性处理：针对重复投递的事件（比如POST请求重试），要保证message.new的替换、message.read的删除不会重复执行，可给每个事件分配唯一ID，用Redis键做幂等校验
• 错误重试：通知服务调用失败时，要加重试机制——比如用Redis列表做重试队列，定期拉取失败事件重试
• 监控告警：添加Redis键数量、事件处理延迟、通知发送成功率的监控指标，出现异常及时告警
• 批量操作：突发流量大时，将多个事件批量写入Redis，减少IO交互次数，提升处理效率

3. 基于协程与通道的架构能否支撑高负载场景？例如单聊天室100条消息会产生300次事件的量级。 #

完全可以支撑：

• Golang协程的开销极低（每个协程初始栈仅几KB），300次事件对应的协程数量远在Go的处理能力范围内，不会造成资源瓶颈
• 配合以下优化手段，能更稳定应对高负载：
  • 给事件通道设置合适的缓冲大小（比如根据预期峰值设1000-5000），避免HTTP请求因通道阻塞而超时
  • 用工作池模型限制worker数量：根据CPU核心数或Redis连接池大小，设置handleMessageNewWorker和handleMessageReadWorker的最大数量，避免协程过多导致上下文切换开销飙升
  • 配置合理的Redis连接池：避免因连接耗尽导致事件处理阻塞
  • 异步处理HTTP请求：HTTP请求处理仅负责把事件写入通道或Redis，立即返回响应，后续逻辑交给后台协程处理，大幅提升请求吞吐量

内容的提问来源于stack exchange，提问作者alex