京东外卖暂崩的思考学习

4.22的那个中午

京东和美团开价格战嘛，京东的外卖便宜又配送低，所以那几天一直在点，可是在4.22的中午，我一如往常地美美点了乡村基等吃，可是下课一看，30mins过去了，不仅地图上没显示商家情况，界面ui也一直鬼畜地变动，又等了20mins没吃上，换了一家还是那样。

上网上一搜，哦豁，京东外卖出问题了

大抵是外卖订单暴增，把服务打崩了。。

正好最近也在学分布式的内容，拆开来看一看

从来源入手

流量暴增总的根本来说有两个应对手段，要么开源，要么节流

先从节流上来看一下

流量削峰填谷：将高峰时段的请求分散到低峰或通过异步排队缓冲来处理的策略。常用方法包括排队系统、延迟响应、消息队列缓冲等，以防止峰值流量冲垮系统。RocketMQ 等中间件即提供“峰谷填充”功能，通过缓冲消息削减瞬时负载

就是把突发的高峰流量分散一些，抵挡一下，当一个缓冲

消息队列，正好可以用来做这个，而且，像网关也会做负载均衡，把流量分散到不同服务器上，好像还有能根据配置情况动态分发的，这部分还不太清楚，还需要继续学习

流量保护：在接入层使用限流器对突增流量做第一道防护。微服务内部根据自身承载能力实施级联限流。例如使用Envoy/Istio动态下发熔断限流规则，对某些服务关闭非关键接口，或返回预设提示。

如果真顶不住了，削峰也削不了，就可以学沟槽的大麦网抢票那样，顶不住就弹个窗报当前情况过载，不过这种一般用在秒杀里吧，外卖的话，还是必须保证能点，这次可能就是超出了预期

从后台入手

扩容临时资源：迅速增加计算资源，如横向扩展服务器实例、容器节点或使用云弹性伸缩（ESS）功能，临时提升计算和带宽能力

很简单的，扛不住最简单粗暴的办法就是加硬件，像这样短期集中的流量爆发，其他情况比较平淡，我之前不了解怎么做，查了一下，很多云服务都提供了弹性扩容的能力，遇到流量超标可以临时加机器

缓存和加速：核心热数据（商品、价格、运费规则等）优先缓存到Redis集群，适时更新。静态资源（商品图片、页面模板）采用CDN分发和缓存。对查询量巨大的统计/分析场景，可使用ElasticSearch等搜索缓存。

缓存预热和加速：提前将热点数据（商品信息、页面模板等）加载到缓存（如Redis），提高命中率减少数据库压力。针对已知促销或热销商品，可主动预热缓存。

流量太大，上！redis。防止mysql被打爆，遇到这种流量情况，就可以在redis上多做些辅助。而且可以根据外卖本身，哪些外卖比较火，哪些服务比较火，哪些店家比较火，针对性地对热key做提前缓存

服务降级：在流量高峰时舍弃或简化非必要业务。例如临时关闭商品评论、积分等功能，释放资源以保证下单链路正常。准备好降级和恢复策略，在监控压力接近阈值时可手动或自动触发降级开关。例如将临时业务指标设为不可买、关闭推荐等，让核心下单链路优先得到资源。降级结束后及时恢复正常功能。

流量实在太多，就可以暂时降级关闭其他服务或者推荐，或者前端那边，关闭一些窗口和情况，这次京东做的就不好，感觉是没有应对外卖的经验，高峰情况下前端ui有降级，但是很混乱，像修改订单，ui时弹时不弹，可能是应对没做好。

相关技术

技术选型推荐（示例对比）

技术类别	推荐方案	优势与说明
缓存（Cache）	Redis Memcached	Redis 支持丰富数据结构、持久化和主从复制，高可用性强；Memcached 轻量多线程、部署简易，但功能简单、不支持持久化。
消息队列	Kafka RabbitMQ/RocketMQ	Kafka 面向海量日志流设计，高吞吐、持久化，适合大数据流场景[；RabbitMQ/RocketMQ 支持复杂路由、高可用消息传递，适合业务事务场景。
容器&伸缩	Kubernetes (HPA) 云弹性伸缩(ESS)	Kubernetes 自带水平Pod自动扩缩容（HPA）机制，可基于CPU/内存等指标自动增减实例；云平台ESS可按策略自动扩容ECS实例，无需人工干预。
流量网关&限流	Nginx Envoy/Istio	Nginx 性能成熟，可用于反向代理、缓存和限流；Envoy/Istio 提供动态路由、服务熔断、流量镜像等高级功能，可实现细粒度流控和可观察性。