キューの概念：
1、キューミドルウェアの設定
2、メッセージに即時の必要はありません。
図3に示すように、注文は、加入者/消費者によって処理されます。
キューの原則：
また、デカップリングの原則：ビジネスシステムとキュー処理システムは問題ではありません
書き込み（ビジネスシステム）、リード（キュー管理システム）。
ただ、書き込みへの書き込みキュー、他に何も心配しないでください、読み取りおよび書き込みを読むことができない問題ではありません
同様に、ちょうど仕事でドライに読み出さキューからの読み取り、仕事から回復しませんでした
シナリオ：
冗長性：永続これで処理が完了した後、注文処理によって、その後の買収、キューに格納され、削除の記録
デカップリング：これは、2つのシステム（ビジネスおよびキュー処理）の溶液である、我々が通常行うシステムです。別のシステムが原因間隔キューに、影響されない、ジャンプ前記エンキューおよびデキュー直接システムに関連していません、
スパイクと買い：フローは、風水を切りました。メッセージキューバッファを用いて流サージ（下限は、わずか10のように、キューメモリ10は、後に格納され、スパイクに端を要求されない場合）
非同期通信：非同期動作プログラムを達成するようにエンキューメッセージ自体は、直接リターンシステムを作ることができるので
シーンスケーラビリティ：受注と金融システムのみがあるので、私は直接システムを選ぶ、フォローピッキングシステムを追加したいと思いますが、このキューを購読することができます
保証オーダー：キュー自体は、そのようなシステムから、単一では、シングルスレッドの単一にすることができるので、このような手順を処理バンクデータとしていくつかのシナリオでは、することは、非常に重要です
メディアを実現します：
1、MySQLを使用して：高い信頼性を実現するのは簡単、遅いです
2、Redisの使用：速い、低老化の単一の大きなメッセージパケットを
3、より専門サードパーティのライブラリの使用：プロフェッショナルで、信頼性の高い、高学習コスト。
私はこのブログを参照してくださいhttp://blog.csdn.net/qq_33862644/article/details/79386484
トリガ機構の取り扱いのメッセージ：
1は、無限ループが読み：実装が容易、障害が迅速に対応することはできませんしながら、（このような短い時間をスパイクに適用可能）
2、定期的なタスク：圧力の共有（あなたがキューの前にピークがキューの後にシステムがまだ定期的に行ってどれだけ不安定にかかわらず、システムの）、処理上限があります
注：タイミングが重要な時期である：ない通常のミッションが行われていない上、次のタスクは、タイマーを起動することです
ケース：オーダーシステム、すぐに単一の成功の下にキューとリターンに書き込ま注文後に注文情報。システムにキューを読むために数分ごとに時間をピッキング、処理の順序が集約します
3、デーモン：PHP-FPMおよびCGI、シェルベースに必要と同様（キュー、コンテンツの内容があるか否かを検出するために、このプロセスを使用して、処理のために、チーム・システムを開始します）
mysqlのケースをデカップリングを使用します。
なぜデカップリング：アーキテクチャ一緒にした場合。注文システム圧力、および物流の情報がすぐに返さ必要ありません。注文崩壊は、物流にもデカップリングするので、跳ね上がっ
テーブルデザイン：
受注待ち行列システムは、コードを書いています：
システムキューをピッキングすると、コードを読んで：
定期的なタスクを実行してのcrontab -e
注：このログファイルを彼らの新しいをします
1、アクセスはブラウザを介して順序を追加order.php
2、シェルで見られる結果をログに記録し、結果のデータベースを参照するには（正常に実行されていないレビューがランで完成ので、それは、特定の特性のshファイルカタログそれに必要な場合があります）
使用Redisの交通カットフロントケース
アイデア：
1、書き込みスパイクRedisのにプログラム要求
2、廃棄上限（スパイク戻り端）を越え、Redisの長チェックデータを寄託されています
図3に示すように、データのRedisの無限ループ処理及び貯蔵に
テーブルデザイン：
スパイクコード：
倉庫コード：
直接アクセスuser.phpにブラウザ
シェルでsavetodb.php -f PHPを使用して
データベースを表示するには