80.sessionの共有方式
1.放送：イントラネットネットワークストームを引き起こすことが、集中的なブロードバンドネットワーク
2.IP_hash：nginxの設定と同じ固定IP同じサーバーを見つけ、このプログラムは悪いサービスになります
3.サードパーティのミドルウェア（データベース、Redisの）を使用し、我々はRedisのを使用しています
82.高並行性の問題：索引データベースの同期化
1.ハードコード：コードに対応するインデックスデータベース同期コードを増加させます。しかし、カップリングのこの方法は、予測不可能なエラーを引き起こす可能性が一緒に結合された高すぎ、本来は無関係なシステムであり、電気の供給者はタブープロジェクトです。
AOPの2.spring：方法のAOPの形態及びそのデータ更新されたデータベース・リンクを使用してのインデックス付きデータベース同期方法を書き込みます。このように、また、カップリングを引き起こします。
3.メッセージキュー：しかし、この方法では問題が発生しますし、それが消費者の障害のメッセージです。
：2つのシステム間の通信の問題を解決します。
メッセージの消費に失敗しました：集中型のインデックスデータベースの同期は、タイミングタスクを実行します。メッセージキューに加えてデータベースサーバーでは、我々はRedisのキャッシュを使用しています。送信された各メッセージのメッセージキューは、このメッセージはRedisのに永続化されます。次に、タイミングメッセージリストRedisのうちバッチ同期インデックスデータベースから取得されます（ユーザの少量の場合、我々は、夕方にあります）。
85.なぜコントローラ層内のメッセージであろうサービス層ActiveMQの間のコール？
トランザクションのため！あなたは、コントローラ層にメッセージを送信する場合、コントローラ層は、サービスは、トランザクションがコミット操作を完了している必要があります呼び出します。あなたはサービス層にメッセージを送信している場合、トランザクションがコミットしていない可能性があり、それがnullポインタ例外が発生します。
86.なぜインデックスデータベースの同期キューが道をActiveMQのでしょうか？（キューを使用するメリット）
1.メッセージを検討する必要が消費されていません
2.queue、永続メカニズムが付属しています
3.事業は比較的安全な、より単一です
87.メッセージキューの問題：インデックスデータベースの同期化、コンテンツ配信、なぜ商品IDの製品情報があるが、ありませんか？
商品IDの転送：
利点：商品の転送がIDであり、より少ないコンテンツ伝送効率が比較的高く、メッセージが詰まらないであろう。
短所：消費財は、情報から再びデータベースを照会する必要があり、かつインタラクティブなデータベースとより。
製品情報を送信します：
利点：消費者がデータベースとの相互作用を減らすこと、データベースの商品情報からデータを再クエリする必要はありません。
短所：情報の送信は、商品は、送信内容が比較的小さいです：メッセージの輻輳問題を生じることが、（理由は、ネットワーク伝送におけるテキスト情報は、ネットワークリソースの最小値を占有）が、私たちのメッセージを送ることにより、連続していないではありません高すぎる同時性がある（理由：メッセージを送信するときに送信され、承認後の作業のプラットフォームの必要性が）