多进程间无法直接共享变量，必须通过外部媒介如Redis、Queue、Pipe或Channel（如Celery）实现通信；Redis最通用但需避免连接复用、竞态和序列化开销，Channel适用于任务编排场景。
多进程间不能直接共享变量，必须走外部媒介
Python 的 multiprocessing 默认用 fork 或 spawn 启动子进程，内存空间完全隔离。你改主进程里的 list、dict，子进程根本看不到——这不是 bug，是设计使然。别试 global、闭包或类属性，全无效。
常见错误现象：
– 主进程打印 data = [1, 2]，子进程里 print 出空列表或旧值
– 用 multiprocessing.Manager() 却没注意它序列化开销大、不支持任意对象（比如带方法的实例）
– 直接传函数参数以为能“同步更新”，结果只是传了个快照
- 轻量、高频读写：优先选
Redis，尤其已有 Redis 服务时 - 单机、低延迟、结构简单：用
multiprocessing.Queue或Pipe，但只适合点对点或生产者-消费者模型 - 需要广播、事件通知、跨语言：上
Redis Pub/Sub或Channel类组件（如 Celery 的redis://broker）
Redis 是最稳的通用方案，但得避开连接复用陷阱
每个子进程都该有自己的 redis.Redis 实例，不能在父进程中创建后传给子进程——fork 后文件描述符会冲突，spawn 下更直接报 ConnectionError。
使用场景：多个 worker 进程持续更新/查询同一个计数器、缓存键、任务状态等。
实操建议：
- 子进程中用
redis.Redis(host='localhost', port=6379, decode_responses=True)新建连接，别复用父进程对象 - 对原子操作（如计数器），用
redis.incr('counter')而不是先get再set，避免竞态 - 大量小数据用
pipeline批量提交，减少网络往返；大数据考虑用hset分字段存，别全塞进一个string - 注意 Redis 默认最大连接数（
maxclients），100 个进程各开 1 连接，很容易打满
示例（安全写法）：
def worker(task_id):
r = redis.Redis(host='localhost', port=6379, decode_responses=True)
r.hset(f'task:{task_id}', mapping={'status': 'running', 'start_time': time.time()})
# ... do work
r.hset(f'task:{task_id}', 'status', 'done')
Channel 组件（如 Celery + Redis）适合有任务编排的场景
如果你不是单纯共享几个变量，而是要分发任务、等待结果、处理失败重试——那 Channel 不是“可选”，是“该用”。这里 Channel 指的是消息中间件抽象层，比如 Celery 的 broker 和 result_backend。
容易踩的坑：
- 误以为
Celery的shared_task能自动共享内存变量——它只负责调度和序列化参数，执行环境仍是隔离的 - 把所有数据塞进 task 参数里传，超长参数导致
redis.exceptions.DataError或性能骤降 - 没配
result_backend（比如还是用rpc://），结果查不到异步任务返回值 - 用
apply_sync()代替apply_async().get()，看似简单，实则阻塞主线程，失去多进程意义
参数差异关键点：
– broker（如 redis://localhost:6379/0）管任务分发
– result_backend（如 redis://localhost:6379/1）管结果存储，建议和 broker 分库，避免互相干扰
别忽略序列化成本和数据一致性边界
无论 Redis 还是 Channel，本质都是把内存数据转成字节再传，这个过程本身就有开销。一个 1MB 的 dict，每次 set 都要 pickle/unpickle，比本地赋值慢 2 个数量级。
真正容易被忽略的是“一致性”假象：
– Redis 的 GET 是瞬时快照，两次 GET 之间数据可能已被其他进程改过
– Channel 的 task 结果默认只存一段时间（Celery 默认 1 天），超时就查不到
– 没加锁（redis.lock）的情况下，并发更新同一 key，最后谁写入谁赢，中间变更全丢
所以，别拿 Redis 当本地变量使。该加锁的地方加锁，该用原子命令的别绕路，该拆成小字段的别图省事塞一起。
