🍔系统设计与高并发架构：用快餐店经营的例子轻松理解
type
status
date
slug
summary
tags
category
icon
password
Status
1. 单个厨师 (Single Chef) → 单体应用 (Monolithic Application)
- 思考方式： 就像一家刚起步的小店，所有的功能（点餐、烹饪、收银等）都集中在一个厨师身上。在系统设计初期，为了快速开发和部署，我们可能会选择将所有功能模块打包成一个单独的应用。
- 实际系统设计： 适用于小型项目或者快速原型开发。但随着业务增长，单体应用会变得臃肿、难以维护和扩展。
2. 给厨师加薪/优化流程/购买自动化设备 (Increasing Salary/Optimizing Workflow/Buying Automated Equipment) → 垂直扩展 (Vertical Scaling) 和 代码优化/流程优化 (Code Optimization/Process Optimization)
- 思考方式： 为了提高单个厨师的处理能力，可以提高他的技能（加薪激励），优化他的工作流程（例如，提前准备食材），或者给他更强大的工具（自动化设备）。
- 实际系统设计：
- 垂直扩展 (Scale Up)： 提升服务器的硬件配置（CPU、内存、磁盘等），以提高单个服务器的处理能力。适用于流量增长初期，但存在硬件上限。
- 代码优化/流程优化： 优化代码逻辑、数据库查询、算法等，提高系统在现有硬件上的运行效率。这始终是提升系统性能的重要手段。
3. 预先准备食材 (Pre-preparing Ingredients) → 批量预处理 (Batch Pre-processing)
- 思考方式： 在订单低峰期提前完成一些耗时的准备工作，例如清洗蔬菜、腌制肉类，这样在高峰期可以更快地处理订单。
- 实际系统设计： 对于一些不需要实时处理的任务，例如数据分析、报表生成、定时任务等，可以在系统空闲时段进行批量处理，提高系统在高并发时的响应速度。
4. 备用厨师 (Backup Chef) → 主备/主从架构 (Master-Slave/Active-Passive Architecture)
- 思考方式： 为了防止主厨生病导致店铺无法运营，需要一个备用厨师在主厨无法工作时顶替。
- 实际系统设计： 部署多个相同的服务实例，其中一个作为主节点（Master/Active），负责处理主要的业务请求。另一个或多个作为备节点（Slave/Passive），在主节点发生故障时接管其工作，提高系统的可用性，避免单点故障。
5. 雇佣更多厨师和设备 (Hiring More Chefs and Equipment) → 水平扩展 (Horizontal Scaling)
- 思考方式： 当单个厨师的处理能力达到极限时，增加厨师的数量和相应的设备是应对更多订单的直接方法。
- 实际系统设计： 通过增加更多的服务器实例来分担流量和计算压力。每个服务器运行相同的应用程序代码，共同处理用户的请求。这是应对高并发场景最常用的方法。
6. 店小二分配订单 (Waiter Assigning Orders) → 负载均衡 (Load Balancing)
- 思考方式： 当有多个厨师时，需要一个店小二来合理地分配顾客的订单，避免某些厨师过载而其他厨师空闲。
- 实际系统设计： 使用负载均衡器（例如，Nginx, HAProxy, Kubernetes Service）将用户的请求均匀地分发到后端的多个应用服务器实例上，提高系统的整体吞吐量和可用性。
7. 轮询分配 (Round Robin Assignment) → 负载均衡算法 (Load Balancing Algorithms)
- 思考方式： 店小二可以按照顺序将订单分配给每个厨师。
- 实际系统设计： 负载均衡器可以使用不同的算法（例如，轮询、加权轮询、最少连接、IP Hash 等）来决定将请求转发到哪个后端实例。选择合适的算法取决于具体的业务场景和需求。
8. 配菜师傅提前准备配料 (Ingredient Preparation Chef Prepares Ingredients) → 缓存 (Caching)
- 思考方式： 配菜师傅提前准备好常用的配料，这样主厨在制作菜品时可以直接使用，节省时间和精力。
- 实际系统设计： 使用缓存（例如，Redis, Memcached）存储经常被访问的数据，例如热点商品信息、用户信息、计算结果等。当用户请求这些数据时，可以直接从缓存中获取，避免访问数据库等慢速存储，提高系统的响应速度和性能。
9. 顾客排队 (Customer Queue) → 队列 (Queue)
- 思考方式： 当订单量过大，厨师无法及时处理时，让顾客排队等待，保证厨师能够按照自己的节奏处理订单，避免系统崩溃。
- 实际系统设计： 使用消息队列（例如，RabbitMQ, Kafka, RocketMQ）来异步处理请求。当系统接收到大量请求时，先将请求放入队列中，然后由后端的服务按照自己的处理能力从队列中取出并处理。这可以起到削峰填谷的作用，防止系统被突发的流量压垮，并提高系统的可靠性。
10. 叫号系统 (Call Number System) → 异步处理 (Asynchronous Processing)
- 思考方式： 顾客下单后不必一直等待，可以在菜品做好时通过叫号系统通知他们。
- 实际系统设计： 将一些耗时的操作放到后台异步执行，例如发送邮件、处理支付、生成报表等。用户发起请求后可以立即得到响应，无需等待后台操作完成。这可以提高用户体验和系统的并发处理能力。
11. 厨房内的矛盾 (Conflicts in the Kitchen) → 服务耦合 (Service Coupling)
- 思考方式： 多个厨师在同一个厨房内共享资源，可能会因为争抢工具或操作失误而产生冲突。
- 实际系统设计： 在单体应用中，不同的功能模块之间可能存在高度的依赖关系，修改一个模块可能会影响到其他模块，导致系统不稳定。
12. 将厨房拆分开 (Separating Kitchens) → 微服务架构 (Microservices Architecture)
- 思考方式： 将不同的菜品制作分配给不同的厨师和独立的厨房，每个厨师专注于自己的菜品，互不干扰。
- 实际系统设计： 将一个大型的单体应用拆分成多个小型、独立的服务。每个服务负责一个特定的业务功能，可以独立开发、部署和扩展。微服务之间通过轻量级的通信机制（例如，RESTful API, gRPC）进行交互。这可以提高系统的可维护性、可扩展性和灵活性。
13. 亲信小刘检查订单 (Trusted Manager Checking Orders) → API 网关 (API Gateway)
- 思考方式： 为了保证财务安全，需要一个可信的人来检查订单是否已付款，并决定将订单分配给哪个厨师。
- 实际系统设计： API 网关是外部客户端访问后端服务的统一入口。它可以负责处理身份验证、授权、请求路由、流量控制、监控等横切关注点，保护后端服务的安全和稳定。
14. 黑名单 (Blacklist) → 黑白名单控制 (Blacklist/Whitelist Control)
- 思考方式： 将经常逃单或恶意行为的顾客加入黑名单，拒绝他们的订单。
- 实际系统设计： API 网关或应用防火墙可以维护黑名单和白名单，用于阻止来自特定 IP 地址、设备 ID 或用户 ID 的恶意请求。
15. 超时处理 (Timeout Handling)
- 思考方式： 如果厨师长时间没有处理订单，小刘不会一直等待。
- 实际系统设计： 在服务调用过程中设置合理的超时时间，如果被调用的服务在指定时间内没有响应，则返回错误，避免请求被无限期地阻塞。
16. 失效转移 (Failover)
- 思考方式： 如果某个厨师很忙，小刘会将订单转发给其他空闲的厨师。
- 实际系统设计： 当某个服务实例发生故障或响应缓慢时，负载均衡器或客户端可以自动将请求路由到其他可用的实例，提高系统的容错能力。
17. 熔断 (Circuit Breaker)
- 思考方式： 如果发现某个厨师总是没有反应（例如去厕所了），暂时停止将订单分配给他，直到他恢复正常。
- 实际系统设计： 当某个服务连续发生错误时，熔断器会暂时切断对该服务的调用，防止故障扩散到其他服务。一段时间后，熔断器会尝试重新连接该服务，如果恢复正常则关闭熔断。
18. 流控/限流 (Flow Control/Rate Limiting)
- 思考方式： 当制作某种菜品的厨师都非常繁忙时，适当控制该菜品的订单数量，防止他们过载。
- 实际系统设计： 对服务的请求流量进行限制，防止过大的流量冲击导致服务崩溃。可以使用令牌桶、漏桶等算法实现限流。
19. 监控录像 (Surveillance Camera) → 日志记录 (Logging)
- 思考方式： 记录菜品的制作过程，方便后续追查问题。
- 实际系统设计： 记录应用程序的运行状态、错误信息、用户操作等日志，用于故障排查、性能分析和安全审计。
20. 监控室的小刘 (Xiao Liu in Monitoring Room) → 监控系统 (Monitoring System)
- 思考方式： 实时监控厨房的运作情况，发现异常及时报警。
- 实际系统设计： 使用监控系统（例如，Prometheus, Grafana, ELK Stack）实时收集和展示应用程序和基础设施的各项指标（例如，CPU 使用率、内存使用率、请求延迟、错误率等），并设置告警规则，当指标超过阈值时发送通知。
21. 断电 (Power Outage) → 单点故障 (Single Point of Failure)
- 思考方式： 只有一个店铺，一旦断电整个业务就停止了。
- 实际系统设计： 系统中存在某个组件一旦失效就会导致整个系统不可用的情况。需要通过冗余部署、故障转移等机制来避免单点故障。
22. 开分店 (Opening a Second Branch) → 同城跨机房部署 (Same-City Multi-Availability Zone Deployment)
- 思考方式： 在不同的地点开设分店，即使一家分店出现问题，另一家仍然可以继续营业。
- 实际系统设计： 将应用程序部署在同一城市的不同机房（可用区）中，这些机房之间网络互联，但电力和网络等基础设施相互独立。当一个可用区发生故障时，另一个可用区的实例可以继续提供服务，提高系统的可用性和容灾能力。
23. 两地三中心 (Multi-Region Deployment with Three Data Centers)
- 思考方式： 在异地建立灾备中心，提供更高级别的容灾能力。
- 实际系统设计： 将应用程序部署在地理位置不同的多个数据中心，通常采用主备或双活模式。当一个地域发生重大故障时，可以将流量切换到另一个地域，保证业务的连续性。