用go-redis/v8+BRPop+固定worker池比Kafka/RabbitMQ更快落地、更可控，尤其适合中小规模业务（QPS 1k–5k）；因channel仅限单机内存通信，无法分布式，而Redis list+BRPop天然支持多消费者公平分发、阻塞消费与超时重试，部署成本远低于Kafka。
go-redis/v8 + BRPop + 固定 worker 数量的 goroutine 池，比引入 Kafka/RabbitMQ 更快落地、更可控，尤其适合中小规模业务场景（QPS 1k–5k）。
为什么不用 channel 做分布式队列？
本地 channel 是内存级的，goroutine 之间通信没问题，但一加机器就失效。分布式意味着多个进程/实例要共享同一份任务源——必须依赖外部存储。Redis 的 list + BRPop 天然支持阻塞式消费、多消费者公平分发、自动重试（靠超时+重入），且部署成本远低于 Kafka。
常见错误是强行把 chan Job 暴露给多机，结果只有一台机器收得到任务，其余空转。
- channel 只适用于单进程内协程通信，不是分布式原语
- 试图用 gRPC 或 HTTP 轮询模拟队列，会放大延迟、丢失原子性
- 没设
timeout参数导致BRPop卡死，worker 全部 hang 住
如何用 go-redis/v8 实现可伸缩的消费者池？
核心是让每个 worker 独立连接 Redis 并调用 BRPop，而不是共用一个连接——否则并发下降、连接争用严重。同时要控制 worker 数量，避免 Redis 连接数爆炸或 CPU 过载。
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
func startWorker(ctx context.Context, client *redis.Client, queueName string, concurrency int) {
for i := 0; i < concurrency; i++ {
go func() {
for {
// 注意 timeout 必须 > 0，否则退化为普通 Pop，丢任务
res, err := client.BRPop(ctx, 5*time.Second, queueName).Result()
if err == redis.Nil {
continue // 超时，继续轮询
}
if err != nil {
log.Printf("BRPop error: %v", err)
time.Sleep(time.Second) // 避免疯狂报错
continue
}
taskData := res[1] // BRPop 返回 [key, value]
processTask(taskData)
}
}()
}
}
-
concurrency建议设为 CPU 核数 × 2～4，而非无脑开 100 个 goroutine -
BRPop第二个参数是 timeout，必须显式传（如5*time.Second），不能写 0 - 每个 worker 应该有自己的
context.WithTimeout控制单任务执行上限，防卡死
任务失败后怎么重试而不丢？
Redis list 本身不提供“失败回滚”机制，得自己设计。最简方案是：消费成功再 LTrim 或 LRem；失败则 LPush 回原队列头部，加失败计数前缀（如 retry:3:task_xxx），超过阈值进死信队列。
不要依赖 BRPop 的原子性来保成功——它只保证取到，不保证处理完。真正可靠的做法是「先取、再处理、最后确认删除」。
- 别在
BRPop后直接LRem，那是竞态：万一处理中途 panic，任务就丢了 - 推荐模式：
BRPop→ 解析 → 执行 → 成功则LPop（如果用的是 list）或删 Redis key（如果用的是 stream） - 若用 Redis Stream，优先选
XReadGroup+ACK，天然支持失败重投和消费者组偏移管理
什么时候该换 Kafka 或 NATS？
当出现以下任意情况，说明 Redis 已经撑不住了：
- 单个任务平均耗时 > 30s，
BRPoptimeout 难以兼顾吞吐与可靠性 - 需要精确一次（exactly-once）语义，比如金融类扣款任务
- 消息堆积超过 100 万条，Redis 内存压力大、
LRANGE慢、bgsave 频繁阻塞 - 要求跨 DC 同步、多订阅者独立 offset、schema 管理
换之前先做压测：用 redis-benchmark -t lpush,lpop -n 1000000 看 Redis 吞吐是否达标。很多团队其实卡在连接池配置或网络带宽，而不是中间件选型本身。
