あなたは図スパイク交通監視システムを見れば、あなたはそれが直線であるでしょう、その第二スパイクの初めにスパイクが非常に単一に集中しているため非常にまっすぐまっすぐ直線、時間内にその要求であります特定の時点。その結果、それが特に高いトラフィックのピークにつながる、資源の消費量が瞬間的です。
スパイクこのシナリオでは、商品を購入することができ、人々の最後の数が固定されています。言い換えれば、100人と100万人の結果は、要求を開始した同じですが、商品を購入する最後のスパイクだけで100人が存在します。これは、並行処理の量が高いほど、最終的な無効な要求を意味します。
しかし、ビジネスのために、スパイク活動自体は、商業振興間違いなくより多くの人々がに巻き込まれることを願っています。より多くの無効な要求は、より多くの成功は、それが事業推進を表します。唯一のスパイクの初めに、これらの要求の多くは、サーバー上の重い負担を運ぶスパイクするスパイクますので、我々はピーク時のトラフィックを弱めるために、同時要求を遅らせたり、無効な要求をフィルタリングできるようにするルールを設計することができます交通クリッピングであるサーバー、上の圧力の。
なぜクリッピング
私たちは、それが所定の位置にあります、リソースを処理するサーバーがしたりせず、一定であることを知って、処理能力は変わりません。何の余暇時間は処理されませんが、ピークので、しかし、処理するために忙しいにつながる可能性が高いです。しかし、サービスの品質を確保するために、処理リソースの多くは、唯一の忙しい時間に応じて推定することができ、これは資源の浪費につながります。
トラフィックがピークシフト限界線のソリューションとなるよう、朝のラッシュアワーの問題と夕方のピークをクリッピングするようなものですので。
存在クリッピング、1はサーバプロセスがスムーズになることができます、そして第二に、あなたは、サーバーのリソースのコストを節約することができます。
このスパイクシーンについては、基本的にクリッピングすると、ユーザからの要求を遅らせることが多い、無効な要求を削減し、フィルタリングするためには、[縮小]の原則を順守しようとすることを要求します。
3つのアイデアの主な交通クリッピング操作、最初の行は、これらの3つの方法が実装（発行され、ユーザの要求を失うことなく、すなわち）非破壊あり、第三は、層状のフィルタであり、第二は、答えは、あります。もちろん、いくつかの非可逆の実装は、そのような電流制限と負荷保護などのマシンの安定性や他のいくつかの強制措置について紹介する方法はいくつかの後ろに含むことは保護をクリッピングの目的を達成することができ、これらは最後の施策の一部です。
並びます
トラフィッククリッピングに、最も明白な解決策は、流量をバッファにメッセージキューを使用することで、同期呼び出しを直接円滑に終了ピーク瞬時流量、他端を受ける中間キューを介して、間接的に非同期のプッシュに変換しましたニュースが押し出さ。ここでは、メッセージキューは、上流の氾濫傍受として洪水災害救援の目的を達成するために、下流の河川は、ピークフローにカット、貯水池のようなものです。
以下に示す瞬時流量方式をバッファするメッセージキューを使用します：
そのようなメッセージバックログのようなプロセスのメッセージ・キューの上限を達成するための時間の期間のピークフローは、マシン上のオンラインストレージ容量に達した場合は、メッセージキューも粉砕されます。これは、下流のシステムを保護し、要求を指示したが廃棄された多くの違いがありませんことができますが。洪水は貯水池があっても、渡って来るときと同じように助けにはなりません。
メッセージキューに加えて、キューと同様のような、多く存在します
1.ロックを待機するスレッドプールを使用すると、共通のキューイングです。
2. FIFOは、他の一般的なメモリのキューイングアルゴリズムの実装後に進みました。
3.要求は、ファイルにシリアライズされ、その後、順次ので、再度リクエストを復元するファイル（例えば、MySQLのバイナリログベースの同期機構）を読み取ります。
あなたは、これらのメソッドは共通の特徴を持っている、それがさらに操作のクッションの役割を増加させた2段階の操作、に、操作の手順で確認することができます。
しかし、クッションの追加層ので、アクセス要求の経路を増加させます。それは非常に合理的に見えますが、このステップはバッファを増加させない場合は、いくつかのシナリオでは、システムがベンの崩壊を指示することは非常に簡単ですが、システム設計の高可用性を満たしていない、システムの設計は妥協とバランスするために行われる必要があります。
答え
最も初期のスパイクが、純粋にページを更新し、購入ボタンをクリックし、以降は応答機能を追加しました。
プラス答え関数は2つの目的を達成するために、購入の複雑性を高めることです。
最初の目的は、スパイクはスパイクを浮気された撮影時に使用するいくつかのバイヤーを防ぐためです。2011年にスパイクが火災のとき、スパイクもより一般的であるため、マーケティングや市民参加の目的を達成するため、システムはスパイクデバイス機能に答えるには限界が増加していませんでした。応答機能の増加は、2秒後の基本的な制御のタイミングは、単一のスパイクの割合も大幅に減少しました。
2つ目の目的は、システムがより良い瞬間ピークトラフィックをサポートするように、要求、トラフィッククリッピングアクションの機能に対する要求を遅延させることです。この重要な機能は〜2S、前1秒から10秒の延長、細長い単一のピークを要求することです。このように、時間スライスのピークに基づいて要求。この時間スライスが同時サーバーを処理するために非常に重要ですが、それが大幅に圧力を軽減します。本当の同時書き込みが非常に限られているように、在庫の自然に到着しないことにより、要求した後、連続的な要求のためには、そう簡単に、最後のシングル・ステップを得ることができません。この設計思想は、現在、Alipayの[シュープのシュープ]として、非常に一般的に使用され、マイクロチャネル[シェイク]は、それらが同様の方法です。
ここではデザインのアイデアの焦点についての答えがあるスパイクを話すために、見て：
回答スパイク全体の論理的な機能は、それが3つの部分に分けることができます。
1.試験生成モジュール。主な部分は、それ自体がスパイクを防ぐために、機械で計算結果を防止することが重要である、あまりにも複雑である必要はありません質問と回答、トピックと回答を生成することである答えです。
2.プッシュモジュール試験。このセクションでは、スパイクの前に答えるために使用され、対象は、システムや取引システムの詳細を進めるためにプッシュ。リアルタイムのプッシュは、ユーザーの要求が対象となっている各時間は唯一の答えを不正行為防止のためにことを確認することです。
3.画像フォーマットとして生成トピックの画像生成モジュールのタイトル、及び画像に何らかの外乱を加えます。これはまた、タイトル自体の意味を理解することができる唯一の人を必要とし、その答えに直接マシンを防ぐためです。注意また、その、ネットワークが混雑している時に、事前に画像の対象とすべき答えがCDNにプッシュし、予熱しているため、ユーザーは実際の対象を要求するとそうでない場合、画像がより緩やかにロードすることができ、これの答えに影響を与えることは経験です。
実際には、本当の答えロジックを理解することは比較的容易、比較的簡単です。それ以外の場合は失敗し、次のステップは、論理的だっ比較して、答えを比較するために、ユーザによって提出され、対応するトピックへの答え限り。
ユーザーが頻繁にように提出を繰り返し、場合、検証ロジックがあります、また、着陸かどうかなど、ユーザー自身の身元を確認するなどの質問に対する検証の答え、に加えて、ユーザーのクッキーが、完全であることに注意してください。
もっと、有効性チェックを行うことに加えて、あなたも回答を提出するための時間制限を行うことができます。例えば、時間の最初から操作が可能性は非常に小さいと考えられているので、それが答え機械の問題を防ぐことができますので、1秒、1秒以上に答えるために答えを受信します。
階層化フィルタ
前面介绍的排队和答题，要么是在接收请求时做缓冲，要么是减少请求的同时发送，而针对秒杀场景还有一种方法，就是对请求进行分层过滤，从而过滤掉一些无效的请求。分层过滤其实就是采用【漏斗】式的设计来处理请求。
假如请求分别经过CDN、前台读系统（如商品详情系统）、后台系统（如交易系统）和数据库这层，那么，大部分数据和流量在用户浏览器或CDN上获取，这一层可以拦截大部分数据的读取；经过第二层（即前台系统）时，数据（包括强一致性的数据）都尽量走Cache，过滤一些无效的请求；再到第三层的后台系统，主要做数据的二次校验，对系统做好保护和限流，这样数据量和请求就进一步减少；最后在数据层完成数据的强一致性校验就好了。
这样的话，就像漏斗一样，尽量把数据量和请求量一层一层地过滤和减少。
分层过滤的核心思想是在不同的层次尽可能地过滤掉无效的请求，让漏斗最末端的才是有效请求。而要达到这种效果，我们就必须对数据做分层的校验。
分层校验的基本原则是：
1.将动态请求的读数据缓存（Cache）在Web端，过滤掉无效的数据读取。
2.对读数据不做强一致性校验，减少因为一致性校验产生性能瓶颈的问题。
3.对写数据进行基于时间的合理分片，过滤掉过期的失效请求。
4.对写请求做限流保护，将超出系统承载能力的请求过滤掉。
5.对写数据进行强一致性校验，只保留最后有效的数据。
分层校验的目的是在读系统中尽量减少由于一致性校验带来的系统瓶颈，但是尽量将不影响性能的检查条件提前，比如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求、营销等价物是否充足等。而在写数据系统中，主要对写的数据（如库存）做一致性检查，最后在数据库层保证数据的最终准确性（如库存不能为负数）。
总结
上面的内容介绍了如何在网站面临大流量冲击时进行请求的削峰，并主要介绍了流量削峰的3种处理方式：
1.通过队列来缓冲请求，即控制请求的发出。
2.通过答题来延长请求发出的时间，在请求发出后承接请求时进行控制，最后再对不符合条件的请求进行过滤。
3.对请求进行分层过滤，一层一层过滤掉无效请求，使最后到达的有效请求少。
其中，队列缓冲方式更加通用，它适用于内部上下游系统之间调用请求不平缓的场景，由于内部系统的服务质量要求不能随意丢弃请求，所以使用消息队列能起到很好的削峰和缓冲作用。
而答题更适用于秒杀或者营销活动等应用场景，在请求发起端就控制发起请求的速度，因为越到后面无效请求也会越多，所以配合后面介绍的分层拦截的方式，可以更进一步减少无效请求对系统资源的消耗。
分层过滤非常适合交易性的写请求，比如减库存或者拼车这种场景，在读的时候需要知道还有没有库存或者是否还有剩余空座位。但是由于库存和座位是不停变化的，所以读的数据是否一定要非常准确吗？其实不一定，你可以放一些请求过去，然后在真正减的时候再做强一致性保证，这样既过滤一些请求又解决了强一致性读的瓶颈。
另外，在削峰的处理方式上除了采用技术手段，其实还可以采用业务手段来达到一定效果，例如在零点开启大促的时候由于流量太大导致支付系统阻塞，这个时候可以采用发放优惠券、发起抽奖活动等方式，将一部分流量分散到其他地方，这样也能起到缓冲流量的作用。
"有些人离开不用说再见，有些事不开口也明白。"