Javaの新鮮なビジネスプラットフォーム - プロモーションアーキテクチャと実用的なソリューションスパイク
背景：
過去数年間の熱い電気の供給者で、私たちはしばしば、プロモーションや迅速な利益のために事業のいくつかを見るスパイク活性のいずれかの毎日のスーパーマーケットのプロモーション、スターのコンサートのチケットを販売し、または春祭りに加入を開始しました。列車のチケット、と私たちは影のスパイク活動を見ることができます。
1.ビルドスパイク活動アーキテクチャ
1.1説明
システムアーキテクチャ設計、ピーク値とトラフ値の数、ある程度のトラフィックの流れに応じて、良好な推定値の効果的な流れは非常に重要なステップであり、トラフィックのサンプルサイズ、我々は適切なアーキテクチャを設計しませんこれは、その後のシステムアーキテクチャ設計に影響を与えるだろうと。多くの大企業は、成熟したシステムアーキテクチャの独自のセットを持っているので、代わりにシステムを構築するのが、最も難しい部分ではありません
1.2クリティカル・デザイン
製品設計及び駆動技術の周り1.2.1。
1）一般的なスパイク活動は、この設計の利点は、私たちは、ユーザトラフィックを見積もる支援するために、事前に十分である、このステップは、私たちの拡大は、都市伝説の一時的な展開として、私は保守的となっているかどうかに影響する、T + Nでありますマイクロブログは顔ポップでヒットされているので、明らかに大流量のピークシーズンに向けて、プログラムのこの一時的な拡大は、十分に成熟していないです。
2）スパイク活動の前に小さなゲームの波に、一部の人々は、製品が脳のバブリングではありません尋ねました？私は商品をスパイクするようになった.....
3）スパイク活動の前に、検証コード12306タイプを入力する必要があり、製品が殴られるべきものではないのですか？
4）スパイク活動の前に、カウントダウン弾幕リマインダ、製品がされているGG
実際には、設計されたこれらのトリックは、一方では、イベントが起動しない前に、トラフィックの大量流入を防ぐために、一方では、悪意のあるユーザーを防ぐためである一方、アクティブラリーです
1.2.2キャッシュと予熱
1）静的ページ、ユーザが対応するサーバに最も近いノードにアクセスできるように、その後、静的ページCDNは、サーバ上で複数のリモートライブを展開するサーバルームを導入しました。
2）ダブルレーン.redis
3）。以前の着陸ホットデータ
1.2.3 MQメッセージング・ミドルウェア
遅延キュー、キューのブロッキング
1.2.4制限、ダウングレード
推荐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)分段锁