共计 863 个字符，预计需要花费 3 分钟才能阅读完成。
电商营销中少不了大促，根据长期的工作经验，总结了大促系统核心需要关注以下几个点：
1. 隔离
绝大多数公司的大促类需求都是下单链路的旁路，就是说要做到大促失败是不影响下单的，
这就要求大促系统做到隔离，隔离主要指的是中间件及机器的隔离，对于中间件，数据库，q
缓存，都不应该跟其他人混合部署，个人之前是吃过大亏的，还有机器，现在很多都是虚拟机，
但是隔离做的很差，如果跟下单链路公用宿主机，就有可能造成下单抖动
2.sharding
理论上来讲系统的 qps 是没有上限的，只要是分布式的架构. 在大促中系统中 q 和数据库一定要 sharding
q 在在大促是必不可少的，用来削峰，异步和解耦，在异步场景中流量是首先到 q 的，如果做不好 sharding
q 的消息堆积能力就会大打折扣；还有一个是数据库，最脆弱的就是数据库，但是如果数据库分库分表做的好
数据库就不会成为瓶颈
3. 限流
限流技术现在已经有通用的解决方案，比如阿里基于 Sentinel 的限流及一些基于网关层的限流
工程中主要是这样用的，理论上主要分为计数法和桶法
计数法包括固定计数法和滑动窗口计数法
桶发放主要是漏桶算法和令牌桶算法，
漏桶算法可以简单理解为是生产者 / 消费者模式在流量上的应用，简单高效
令牌桶算法生产者以恒定的速度生产令牌放到令牌桶中（决定了 QPS 阈值）
每个请求去获取令牌，获取到就执行，获取不到则触发限流
4. 错峰
在削峰填谷的思路下任何形式的错峰都是有必要的，前端 random 也是一种思路，打撒后把流量放到后端，
在业务层面能错峰的思路更多，比如玩游戏，每个人有不同的游戏时间等
5. 奥卡姆剃刀原理
要对自己的大促场景有清晰的认知，遵循奥卡姆剃刀原理，就是简单就是有效原理，
举个例子，大促场景下是不是所有的扣减库存都要在 redis 等中间件中扣除，很多是没有必要的，
只要不是单点问题或者热点数据，不存在短时频繁更新数据库的场景，在 DB 操作完全够了。比如电商店铺维度的抢购
数据库扣减库存就够了，天猫也是这么处理的。但是如果是海量用户抢购一个商品这种场景，一定要用 redis 等中间件，扣减之前还需要做预热
