Java fresh business platform - Promotion architecture and practical solutions spike
Background:
With the hot electricity supplier of the past few years, we often see some of the businesses in order to promotions and rapid gains, have launched a spike activity either daily supermarket promotions, star concert tickets sell, or subscribe to the Spring Festival. train tickets, and so we can see the shadow spike activity.
1. Build spike activity architecture
1.1 Description
System architecture design, the number of peak value and trough value, depending on the flow of traffic to a certain extent, the effective flow of good estimate is a crucial step, sample sizes of traffic, we will not design the appropriate architecture as this will affect subsequent system architecture design. instead of building the system is not the hardest part, because many large companies, has its own set of mature system architecture
1.2 Critical Design
1.2.1 around the product design and drive technology.
1) General spike activity is T + N, the benefits of this design is well in advance to help us estimate user traffic, this step will affect whether our expansion, as a temporary expansion of urban legend, I have been conservative obviously for large flow peak season, this temporary expansion of the program is not mature enough, because the micro-blog has been hit in the face pop.
2) before spike activity to a wave of small game, some people asked product is not brain bubbling ? I have come to spike commodity .....
3) before spike activity, need to enter a verification code 12306 type, the product is not what should be beaten?
4) before spike activity, countdown barrage reminder, the products have been gg
In fact, these tricks designed, on the one hand in order to prevent a large influx of traffic before the event does not start, on the one hand is to prevent malicious users, on the other hand is active rally
1.2.2 cache and preheat
1). Static page, then static page CDN deployed on the server, the server room to deploy multiple, remote live, so that the user can access the nearest node to the corresponding server.
2) .redis double lane
3). Earlier landing hot data
1.2.3 MQ messaging middleware
Delay queue, blocking queue
1.2.4 limit, downgrade
推荐sentinel开源中间件,sentinel是以流量为切入点,从流量控制、熔断降级、系统负载保护等多个纬度保护服务稳定性.sentinel和谷歌guaval不同的地方在于它可以做到全局性的限流.对于快到水位线时候,可以随机拒绝一些请求,做好保护.
1.2.5 网关拦截
过滤和限制恶意请求和爬虫之类的,限制参与秒杀的用户需要登陆的token
1.2.6 是否查询数据库
大型秒杀活动是可以不查数据库的,数据异步落库就行
2. 技术难点
其实在第一章节,我并没有过细的赘述,因为现在业界这些框架已经非常成熟了,拿来即用,甚至有些活动并没有那么的流量,可能都无需限流.
2.1 库存是否锁定
是否锁定库存需要看场景,像卖林俊杰演唱会门票这种,是无需锁库存的,why?
对于用户购买意愿非常强烈的活动中,是无需锁定库存的,一方面可以做到公平购买,另一方面防止一些用户其实就是看看的心态,下单了不付钱,导致那些真正想买的人买不到票.而一般的活动是需要锁定库存的,即用户预下单后就锁定库存,但是一般我们秒杀的订单都具有时效性,一般在5-30分钟不等.
2.2 如何释放库存
1)首先查询库存,检查库存状况,库存不足直接返回前端.
2)库存够,用户可以购买商品,用户预下单
3)服务端构建用户订单消息,锁定库存,推送订单消息给延迟消费队列和更新订单缓存,调用预下单接口,然后调用第三方预支付接口
4)前端唤起sdk去付款
5)支付成功,第三方支付会回调通知商户,然后通知业务线去更新支付状态
6)规定时间里面成功支付的订单,删掉缓存
7)延迟消费队列监听,先查询缓存,看缓存数据是否存在,存在的为,超时订单,需要释放库存加1,缓存里面不存在的订单为成功支付的有效订单,落库
2.3 如何解决超卖的问题
redis本质上是没有办法保证是否超卖的问题,在高并发下这种现象很常见.以下提供一些解决方案,性能上可以根据实际情况做调整.
1)悲观锁
2)乐观锁
3)分布式锁
4)队列串行化
5)异步队列分散
6)分段锁