Redis with asynq #43
Description
思想
将_任务_发送到_消息代理的队列_ 然后一组_后台工作者_，不断轮询队列并处理任务 以_Redis_作为_消息代理_
为什么Redis可以作为消息代理
什么是消息代理？
消息代理（Message Broker）是一种中间件，用于在分布式系统中解耦消息的生产者（Producer）和消费者（Consumer），负责接收、存储、路由和分发消息。它的核心作用包括：
异步通信： 生产者发送消息后无需等待消费者立即处理。
缓冲与削峰： 在高并发时暂存消息，避免系统过载。
消息路由： 根据规则将消息分发给不同的消费者。
可靠性： 确保消息不丢失（持久化）、不重复（去重）、有序（顺序消费）。
1. 原生支持发布/订阅模式（Pub/Sub）
Redis 提供了 PUBLISH、SUBSCRIBE 等命令，允许消息的一对多广播。
订阅者可以监听特定频道（channel），发布者将消息发送到频道后，所有订阅者会实时收到消息。
2.列表（List）实现队列功能
Redis 的 LPUSH（左端插入）和 BRPOP（阻塞右端弹出）命令可以组合成一个简单的队列：
生产者用 LPUSH 将消息写入列表。
消费者用 BRPOP 阻塞等待并获取消息。
优点：轻量级、支持阻塞等待，避免消费者轮询。
3. Stream 数据类型
Redis Stream 是专门为消息队列设计的持久化数据结构，支持：
消息持久化：消息不会因消费而丢失。
消费者组（Consumer Group）：多个消费者协同处理消息，支持负载均衡和故障转移。
消息回溯：可以重新读取历史消息。
对于Pub/Sub
实时性：消息一旦发布，所有订阅者立即收到（基于推送模式，无需轮询）。
无持久化：消息发送后，如果没有订阅者，消息会丢失（与 Redis Stream 不同）。
轻量级：适合高频、低延迟的实时场景（如聊天室、实时通知）。
频道（Channel）模型：订阅者需明确指定监听的频道（支持通配符 * 匹配）。
一些思想：
最初的轮询设计： CPU 或程序如何得知外部设备/任务是否有新数据或状态变化。（轮询的本质是 “主动询问”，其目的是让客户端或服务定期检查状态变化，以获取最新数据或事件。）
cpu最早无法被动接收外部变化 只能_主动自己反复检查_寄存器 缓冲区
[TODO]中断！
高可用性
高可用性指系统在出现故障时仍能持续提供服务，核心目标是最小化停机时间（如达到99.99%可用性，即全年宕机不超过52分钟）。
Redis Sentinel（哨兵）
作用：监控主从节点，自动故障转移。
架构：
至少3个Sentinel实例（避免脑裂）。
主节点（Master） + 从节点（Slave）。
Redis Cluster（集群）
作用：分布式数据分片（Sharding） + 高可用。
架构：
16384个哈希槽（Slot）分配到多个主节点。
每个主节点有1个或多个从节点。
目前还是不太理解
主从节点
主从节点的本质：分工协作
你（主节点）：
只负责关键任务（如收钱、进货）。
所有商品变动的记录（写操作）由你亲自处理。
员工（从节点）：
复制你的所有操作（如记录商品价格变化）。
只处理顾客咨询（读操作），比如告诉顾客商品价格。
- 场景1：数据库读写分离
主节点（Master）：处理用户注册、订单支付（写操作）。
从节点（Slave）：处理商品浏览、历史订单查询（读操作）。
效果：写操作不影响查询速度，即使主库宕机，用户仍能浏览商品
主从只是分布式的最简单形态