Distributed

这是 Redis 任务队列系列的第一篇：从一个具体的计算任务开始，用 Python 实现生产者和消费者，先掌握 Redis List 的入队与阻塞出队，再看为什么它还不能直接作为可靠的生产任务队列。

接口返回后继续计算，是否就算任务队列？要看任务如何等待、被领取以及在进程中断后恢复。本文从一个五任务场景推导生产者与消费者模型，再讨论并发、积压、数据库租约，以及 Celery 和 Redis 分别负责什么。

副标题 / 摘要 “网络可靠”“延迟为零”是分布式系统的经典谬论。本文用工程案例解释这些误区的代价。 目标读者 架构与后端工程师 需要设计跨服务系统的团队 学习分布式系统的新手 背景 / 动机 系统设计中最危险的错误是假设“网络就是本地”。 理解这些谬论能避免隐蔽的线上故障。 核心概念 网络不可靠：必须处理失败与重试 延迟不为零：跨地域延迟显著 带宽有限：批量传输会放大延迟 实践指南 / 步骤 所有网络调用都设置超时 重试必须有退避与幂等 对跨区域调用做缓存或异步化 监控延迟分布而不是平均值 可运行示例 import random import time def remote_call(): # 模拟网络不可靠 if random.random() < 0.3: raise TimeoutError("network timeout") time.sleep(0.05) return "ok" def call_with_retry(retries=3): for i in range(retries): try: return remote_call() except TimeoutError: time.sleep(0.02 * (i + 1)) return "failed" if __name__ == "__main__": print(call_with_retry()) 解释与原理 分布式系统中，网络可能失败、延迟可变、带宽有限。 因此所有远程调用都必须假设“会失败”。 常见问题与注意事项 重试会不会放大故障？ 会，因此要有退避与限流。 网络延迟是固定的吗？ 不是，长尾延迟才是主要风险。 本地调用和远程调用能等同吗？ 不能，成本差异巨大。 ...

副标题 / 摘要 故障是分布式系统的常态。本文介绍超时、重试、熔断与降级等核心策略。 目标读者 负责服务稳定性的后端工程师 需要设计容错机制的团队 关注可靠性的技术负责人 背景 / 动机 网络抖动、依赖失败、资源耗尽都会导致故障。 没有系统化的策略，故障会扩散为雪崩。 核心概念 超时：避免无限等待 重试：恢复短暂故障 熔断：快速失败，保护系统 降级：保核心功能 实践指南 / 步骤 为所有外部调用设置超时 重试加入退避与上限 引入熔断器阻止雪崩 为关键路径准备降级策略 可运行示例 class CircuitBreaker: def __init__(self, threshold=3): self.failures = 0 self.threshold = threshold self.open = False def call(self, fn): if self.open: return "fallback" try: result = fn() self.failures = 0 return result except Exception: self.failures += 1 if self.failures >= self.threshold: self.open = True return "fallback" def unstable(): raise RuntimeError("fail") if __name__ == "__main__": cb = CircuitBreaker() for _ in range(4): print(cb.call(unstable)) 解释与原理 超时与重试解决“短暂故障”，熔断防止“持续故障扩散”。 降级保证系统在失败时仍能提供核心价值。 ...

副标题 / 摘要 在封闭网络中，你可以更依赖内网信任；在开放网络中必须假设一切不可信。本文对比两者的设计差异。 目标读者 设计跨网络系统的工程师 需要制定安全策略的团队 架构与安全负责人 背景 / 动机 封闭网络强调效率与内部可信，开放网络强调安全与边界控制。 混用设计思路会带来严重风险。 核心概念 信任边界：封闭 vs 零信任 身份与认证：强身份验证是开放网络的前提 加密与审计：保护数据与可追溯性 实践指南 / 步骤 明确系统是否跨公网 开放网络必须使用强认证与加密 封闭网络也需最小权限原则 建立审计与异常检测 可运行示例 import hmac import hashlib def sign(secret, payload): return hmac.new(secret, payload.encode("utf-8"), hashlib.sha256).hexdigest() def verify(secret, payload, sig): return hmac.compare_digest(sign(secret, payload), sig) if __name__ == "__main__": secret = b"k" msg = "order=1" sig = sign(secret, msg) print(verify(secret, msg, sig)) 解释与原理 开放网络下的核心假设是“任何节点都不可信”。 因此必须依赖身份验证、加密与审计来保证安全。 常见问题与注意事项 封闭网络就不需要安全吗？ 不，内部攻击与误操作同样危险。 加密会影响性能吗？ 会，但安全通常是必须成本。 零信任是否过度？ 对关键系统不是过度，而是必要。 ...

副标题 / 摘要 网络分区不可避免，关键是恢复与收敛。本文介绍分区后的常见恢复策略与工程实践。 目标读者 负责分布式系统的后端工程师 需要设计一致性策略的架构师 关注数据正确性的技术负责人 背景 / 动机 网络分区会让系统产生分歧版本。 恢复阶段的策略决定了正确性与用户体验。 核心概念 分区恢复：网络恢复后进行数据对齐 冲突解决：合并不同版本的写入 补偿事务：修正错误状态 实践指南 / 步骤 明确冲突解决策略（LWW/版本向量） 设计对账流程与修复脚本 对关键数据做人工审核入口 记录审计日志以便回放 可运行示例 # 简化 LWW（Last-Write-Wins）示例 node_a = {"value": "A", "ts": 1} node_b = {"value": "B", "ts": 2} def reconcile(a, b): return a if a["ts"] >= b["ts"] else b if __name__ == "__main__": merged = reconcile(node_a, node_b) print(merged) 解释与原理 恢复阶段需要“合并分歧”。 LWW 简单但可能丢失并发写；更复杂的系统会用版本向量或业务合并规则。 常见问题与注意事项 能否保证不丢数据？ 需要业务级合并或日志回放。 恢复会影响性能吗？ 会，需安排低峰执行或异步处理。 用户感知如何控制？ 提供“同步中”提示与延迟一致性说明。 最佳实践与建议 关键写入保留审计与回放能力 对账与修复流程自动化 为冲突策略建立可解释的规则 小结 / 结论 网络分区后的恢复是分布式系统的必修课。 没有清晰策略，系统会在分区后留下长期脏数据。 ...

副标题 / 摘要 请求/响应强调确定性与即时性，发布/订阅强调解耦与扩展。本文给出工程取舍与选型依据。 目标读者 设计系统通信方式的工程师 需要落地消息队列的团队 关注系统扩展性的架构师 背景 / 动机 不同业务对实时性、耦合度与可靠性要求不同。 选错通信模式会导致复杂度或性能问题。 核心概念 请求/响应：点对点、强同步 发布/订阅：多对多、异步解耦 背压与重试：决定系统稳定性 实践指南 / 步骤 确定是否必须实时同步返回结果 评估消费者数量与扩展需求 设计失败重试与死信队列 为消息定义幂等与去重策略 可运行示例 # 极简发布/订阅示例 subscribers = [] def subscribe(fn): subscribers.append(fn) def publish(event): for fn in subscribers: fn(event) if __name__ == "__main__": subscribe(lambda e: print("A got", e)) subscribe(lambda e: print("B got", e)) publish({"type": "order.created", "id": 1}) 解释与原理 请求/响应适合“需要立即结果”的业务流程。 发布/订阅适合“事件驱动、解耦扩展”的场景，但需要处理一致性与幂等。 常见问题与注意事项 发布/订阅会丢消息吗？ 可能，需配置持久化与重试机制。 请求/响应能扩展吗？ 可以，但耦合更高、弹性更差。 混用可以吗？ 可以，常见是“同步写 + 异步通知”。 ...

副标题 / 摘要 分布式系统的 bug 往往只在故障下出现。本文给出可落地的测试方法：故障注入、一致性校验与时钟模拟。 目标读者 做分布式系统的工程师 负责可靠性与稳定性的团队 想提高系统韧性的开发者 背景 / 动机 分布式系统没有单点真相，故障一旦发生就可能出现数据不一致与链路雪崩。 必须在测试阶段引入“故障场景”。 核心概念 故障注入：模拟节点宕机、网络分区 一致性验证：检查状态是否收敛 时钟偏移：时钟不同步导致逻辑错误 可观测性：日志、追踪、指标 实践指南 / 步骤 定义关键不变量（一致性约束） 故障注入（延迟、丢包、断连、宕机） 引入时间控制（时钟偏移/暂停） 验证收敛与恢复 回归与自动化 可运行示例 下面模拟“随机失败”的分布式写入： import random nodes = ["n1", "n2", "n3"] state = {n: 0 for n in nodes} def write(value): for n in nodes: if random.random() < 0.2: # 模拟失败 continue state[n] = value if __name__ == "__main__": write(10) print(state) 解释与原理 分布式系统的正确性取决于故障场景下的行为。 只有在测试里注入故障，才能提前发现问题。 常见问题与注意事项 只测正常路径够吗？ 不够，真正的 bug 都在异常路径。 故障注入会不会太贵？ 代价远低于线上事故。 一致性如何验证？ 需要定义可验证的不变量。 ...

副标题 / 摘要 RPC 看似像本地调用，但它的失败模式与成本完全不同。本文总结 RPC 的通用缺点与工程应对策略。 目标读者 设计微服务通信的工程师 需要评估 RPC 成本的技术负责人 想避免分布式陷阱的开发者 背景 / 动机 RPC 把“跨网络调用”伪装成本地函数。 这会导致开发者低估失败概率与性能成本，从而引发稳定性问题。 核心概念 网络不可靠性：超时、丢包、抖动 部分失败：某些节点失败，其他正常 重试风暴：错误重试导致雪崩 版本演进：接口变更与兼容性问题 实践指南 / 步骤 为 RPC 设置超时与重试策略 避免级联调用 引入熔断与降级 做好可观测性（日志/追踪） 管理版本兼容性 可运行示例 import time import random def rpc_call(): time.sleep(random.random() * 0.2) if random.random() < 0.2: raise TimeoutError("rpc timeout") return "ok" if __name__ == "__main__": try: print(rpc_call()) except TimeoutError as e: print("fail", e) 解释与原理 RPC 的本质是网络调用，失败概率远高于本地函数。 把它当作本地调用，会导致过度耦合与错误传播。 常见问题与注意事项 RPC 一定比消息队列好吗？ 不一定，取决于一致性与解耦需求。 为什么重试会导致雪崩？ 因为失败请求叠加更多压力。 RPC 的最大风险是什么？ 部分失败与不可预测延迟。 ...

副标题 / 摘要 异步通信提升解耦与吞吐，但引入一致性与可观测性成本。本文给出适用场景与落地指南。 目标读者 负责系统架构与通信模式选型的工程师 设计消息队列与事件流的开发者 希望提升系统稳定性的团队 背景 / 动机 同步调用容易形成链路耦合与级联失败。 异步通信通过消息缓冲解耦，提高系统韧性，但代价是复杂度提升。 核心概念 同步通信：请求-响应，强一致 异步通信：事件驱动，最终一致 消息队列：解耦、削峰、缓冲 实践指南 / 步骤 判断是否必须强一致 评估下游稳定性与峰值压力 明确消息语义（至少一次/至多一次） 引入可观测性（重试、死信） 设计幂等与补偿机制 可运行示例 import queue import threading import time q = queue.Queue() def producer(): for i in range(5): q.put(i) time.sleep(0.1) def consumer(): while True: item = q.get() print("consume", item) q.task_done() if item == 4: break if __name__ == "__main__": threading.Thread(target=consumer).start() producer() 解释与原理 异步通信把“耦合”从时间维度中移除。 上游不必等待下游响应，减少链路阻塞与级联失败。 ...