Rahulab14/swiggy-scale

# 📖 概述 本仓库是一个综合性的 **站点可靠性工程 (SRE)** 和 **系统设计** 案例研究，分析类似 Swiggy 的外卖平台在极端流量条件下的表现，以及如何重新设计系统以在 massive scale 下生存。 该项目模拟了一个真实场景： 目标是确定： - 什么会最先崩溃？ - 为什么会崩溃？ - 财务影响是什么？ - 应该如何重新设计架构？ - 新基础设施的成本是多少？ - 在事故发生时工程师应如何响应？ # 🎯 项目目标 本仓库展示了： - 级联故障分析 - 容量规划 - 分布式系统设计 - 云架构设计 - AWS 成本估算 - 故障响应工程 - 生产环境运行手册编写 # 📊 流量模拟 ### 促销推送 ``` Notification Recipients: 180,000,000 Click Through Rate: 8% Active Users: 14,400,000 ``` ### 用户行为 每个用户大约执行： ``` GET /restaurants GET /restaurant/:id POST /orders ``` 平均值： ``` 3 API requests per user ``` ### 峰值请求速率 ``` Peak RPS = (10,000,000 × 3) / 60 = 500,000 Requests/Second ``` # 🚨 关键发现 ## 1. PostgreSQL 最先崩溃 数据库配置为： ``` max_connections = 100 ``` 同步支付处理会占用连接： ``` 200ms – 2000ms ``` 连接池在几秒钟内即被耗尽。 ## 2. Node.js 超载 41 倍 单服务器容量： ``` ≈ 12,000 RPS ``` 流量需求： ``` ≈ 500,000 RPS ``` 结果： ``` 500,000 / 12,000 ≈ 41x overload ``` ## 3. 支付调用放大了故障 每个订单： ``` Acquire DB Connection ↓ Call Payment Gateway ↓ Wait 200–2000ms ↓ Release Connection ``` 这极大降低了有效吞吐量。 ## 4. 促销码竞态条件 当前流程： ``` SELECT promo UPDATE promo ``` 在高并发下： ``` Millions validated Before updates commit ``` 结果： - 促销码超额订阅 - 收入流失 - 客户投诉 ## 5. 图片可能导致平台崩溃 如果没有 CDN： ``` 10M users × 20 images × 200 KB ``` 产生： ``` ≈ 40 TB ``` 在第一分钟内的图片流量。 应用服务器在处理业务请求之前就会达到网络带宽瓶颈。 # 📂 仓库结构 ``` swiggy-scale/ │ ├── README.md │ ├── docs/ │ ├── FAILURE-CASCADE.md │ ├── ARCHITECTURE.md │ ├── COST-ESTIMATE.md │ └── RUNBOOK.md │ └── assets/ └── image.png ``` # 📚 文档 | 文档 | 描述 | |-----------|-------------| | FAILURE-CASCADE.md | 完整的级联故障分析，包括 RPS 计算、瓶颈、故障触发条件和事件时间线 | | ARCHITECTURE.md | 重新设计的可扩展架构，包含 CDN、Redis、ALB、PgBouncer、Read Replicas 和 SQS | | COST-ESTIMATE.md | AWS 基础设施定价，包括基准和峰值事件的计算 | | RUNBOOK.md | 生产环境故障响应指南，包括告警、分类、恢复、回滚和复盘流程 | # 🏗 架构概述 ## 现有单体架构 ``` Users │ ▼ Node.js │ ▼ PostgreSQL ``` 问题： - 单点故障 - 无水平扩展 - 无缓存 - 无连接池 - 无异步处理 - 无 CDN ## 重新设计的架构 ``` Users │ ▼ CloudFront CDN │ ▼ Application Load Balancer │ ▼ Auto Scaling Node.js Fleet │ ├─────────────┐ ▼ ▼ Redis SQS Queue │ │ ▼ ▼ PgBouncer Payment Workers │ ▼ PostgreSQL Primary │ ├── Read Replica 1 └── Read Replica 2 ``` # 🔧 引入的组件 | 组件 | 用途 | |------------|----------| | CloudFront | 卸载静态资源和图片 | | ALB | 负载均衡和健康检查 | | Auto Scaling | 流量高峰时的动态扩容 | | Redis | 菜单缓存和促销锁 | | PgBouncer | 数据库连接池 | | PostgreSQL Replicas | 读取扩展 | | SQS | 异步支付处理 | | Payment Workers | 后台支付执行 | # 💰 成本摘要 ## 基础设施基准 | 服务 | 每月成本 | |----------|--------------| | EC2 Fleet | $119 | | PostgreSQL Primary | $131 | | Read Replicas | $262 | | Redis Cluster | $358 | | ALB | $56 | | CloudFront | $85 | | SQS | $12 | | **总计** | **~$1,024/月** | ## 世界杯决赛期间扩容 额外的 4 小时事件成本： ``` ≈ $455 ``` ## 商业理由 收入损失预估： ``` ₹4.2 Crore / Minute ``` 45 分钟宕机： ``` ₹189 Crore ``` 基础设施投资： ``` ~$1,024 / Month ``` 预防成本与宕机成本相比微不足道。 # 📋 故障响应 该仓库包含一份完整的操作运行手册，涵盖： - 告警阈值 - 故障检测 - 分类决策树 - 特定组件的修复措施 - 回滚程序 - 复盘模板 专为以下情况设计： ``` Junior Engineers On-Call Engineers SRE Teams DevOps Teams Platform Engineers ``` # 🛠 涵盖技术 ### 后端 - Node.js - Express.js ### 数据库 - PostgreSQL - Read Replicas - PgBouncer ### 缓存 - Redis - ElastiCache ### 消息传递 - Amazon SQS ### 基础设施 - AWS EC2 - AWS ALB - AWS CloudFront - AWS CloudWatch - AWS Auto Scaling ### 可靠性工程 - 容量规划 - 故障响应 - 故障分析 - 运行手册设计 - 成本优化 # 🎓 学习成果 研究本仓库后，您将了解： - 如何计算系统容量限制 - 瓶颈如何导致级联故障 - 如何扩展 Node.js 应用 - 如何扩展 PostgreSQL 数据库 - Redis 如何减少数据库负载 - 异步系统如何提高可靠性 - 如何估算 AWS 基础设施成本 - 如何编写生产级运行手册 # 🚀 最终总结 本项目最重要的经验是： 在这个场景中： ``` 100 PostgreSQL Connections + Synchronous Payment Calls + 500,000 RPS ``` 导致了不可避免的级联故障： ``` Database Pool Exhaustion ↓ Request Queueing ↓ Node.js Saturation ↓ Timeouts ↓ Application Crash ↓ Revenue Loss ``` 重新设计的架构逐一消除了每个瓶颈，将脆弱的单体架构转变为一个具有弹性、可扩展的平台，能够应对重大体育赛事期间的流量激增。

标签：AWS成本估算, MITM代理, 可靠性工程, 容量规划, 库, 应急响应, 搜索引擎查询, 故障分析, 架构设计, 测试用例, 系统设计