大促系统实践经验

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