ユニバーサルインターフェイスを開発し、受信データで、このインターフェイスを介してユーザーは、複雑な論理処理のためのデータを取得し、データがマッチング表示分布やその他の操作の様々なされ、プロセスを処理することは非常に大規模ですが、インターフェイスは、データを受信し、この要求のIDの操作の要求を返すように保持され、操作の残りの部分は、他の手順の処理に非同期です。
idを返す操作には、データベースへの2つの接続が必要です。1つは最新のidを取得するためにデータベースを読み込み、もう1つはidをデータベースに更新します。
独自の手順は、上記の図のように実行されると考え、要求、データベースを読み取り、データベースを書き込み、IDを返し、非同期処理の残りの部分。しかし、アカウントに高い並行性、強い圧力にパフォーマンスの問題を記述するために、高い並行性で、複数のインタフェースのスレッドがデータベースにアクセスするために同僚を取らなかった、そのような状況は、同時同期の問題は、もちろん、この点を考慮され、スレッドロックの使用は、データのファントムリードを避けるために、繰り返し読み取りなど。しかし、一度このようなインターフェイスのスレッドの数が多ければ、すぐにサーバーのCPUは、ダウンタイムを運ぶことができなくなります！
スレッド同期ロックを試さなければ、データ不一致の問題が発生するだけでなく、極端にスレッド化されたアクセスの圧力にデータベースが耐えられず、CPU使用率が85%に達することは明らかです！プログラムは麻痺する危険性があります。
利点：データベースサーバーを増やすと、その圧力が複数のサーバーに分散され、データベースへの圧力が軽減されます。
悪い点：大規模なハードウェアコスト データベースマスターとスレーブの問題 ハッシュ一貫性の問題 単一障害点の問題
メリット：アクセス圧力を複数のサーバーに分散 スレッドスタッキングを効果的に解消
悪い点：多額のハードウェアコスト 単一障害点による問題 nignxロードバランサー構築 複雑な運用
究極のソリューションは、アプリケーションの読み書き分離です！
メリット：ハードウェア・コストの変化なし データベースのプレッシャーを解放 データベースとサーバーのプレッシャーを心配する必要なし
短所：なし
1。読み取りライブラリ操作でデカップルドは、キャッシュサービスのecacheを（また、redisなどの他のことができます）増加し、読み取りは、もはや直接データベースに直面していない、唯一のときにキャッシュ内のデータをキャッシュにデータベース内のデータを読み取り、書き込むには、データベースの読み取り圧力が完全に解放されるように！
この時間は、全体の操作を見て、読み取りと書き込みは、もはや直接データベースに直面しているが、データベースのデータはまだ間違っていない、キャッシュ操作は非常に高速で、インターフェイスサーバーは、もはやスレッドの多くは、ハードウェアコストの場合には、データベースとサーバーの圧力を解決するために変更されないまま圧迫されていない大きすぎると、完璧なソリューションであると言うことができます！
これまでのところ、問題の圧力が正常に解決され、もちろん、問題は解決策の一握りではありませんが、まだいくつかの他の問題は、分散トランザクションのソリューションなど、ここではもはや1つずつを繰り返すには、バックこれらの分散サービスの古典的な問題について話をする機会を見つけることです！
