大促系统实践经验

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

相关推荐