需要原因
非常に同時ビジネスシナリオでは、データベースの同時ユーザーは、ほとんどの場合に最も弱いリンクにアクセスします。だから、あなたはRedisのに最初の要求へのアクセスではなく、MySQLと他のデータベースに直接アクセスするので、バッファRedisの操作を使用する必要があります。
このビジネスシナリオは、主に一般的に業務にフローチャートに従って、キャッシュのRedisから読み出されたデータを解決します。
読む・キャッシング・ステップは、一般的には問題ありませんが、それはデータ更新に来るとき：データベースとキャッシュを更新する、それがしやすいキャッシュ（Redisの）とデータベース（MySQLの）間のデータの整合性。
MySQLデータベースを作成し、その後、Redisのキャッシュを削除する最初のかどうか、またはキャッシュを削除、書き込みライブラリは、データの不整合が発生する可能性があります。例として：
1.あなたはキャッシュのRedisを削除した場合、書き込みデータベースのMySQLに読み込むための別のスレッドが時間がなかった、キャッシュが空で見つけ、その後、キャッシュに書き込まれたデータを読み取るためにデータベースに行き、その後、キャッシュが汚れています。
2.キャッシュを削除する前に、スレッドライブラリダウンライトのライブラリを書く場合は、データの不整合が発生することもあります、キャッシュを削除されません。
書き込みや読み出しが同時なので、順序を保証することはできません、データキャッシュとデータベースの問題に矛盾があるでしょう。
如来は解決しますか？ここでは、ビジネスとテクノロジーのコストが使用することを選択した組み合わせは、最初の2つのソリューションを、より簡単な問題です。
キャッシュとデータベースの整合性ソリューション
最初のシナリオ：使用して遅延戦術二重欠失
前と後の書き込みライブラリがredis.del（キー）を操作して、かつ合理的なタイムアウトを設定します。
擬似コード
公共ボイドライト（文字列キー、オブジェクトデータ）{redis.delKey（キー）; db.updateData（データ）のThread.sleep（500）; redis.delKey（キー）;}
2.具体的な手順は、以下のとおりです。
1）キャッシュを削除
2）書き込みデータベース
3）スリープ500ミリ秒
4）再度、キャッシュを削除
だから、この500ミリ秒はどのように具体的な睡眠時間の長さを決定しましたか？
自分のプロジェクトのビジネスロジックを評価するためのデータ時間のかかる必要性をお読みください。そうすることの目的は、書き込み要求がダーティデータによって引き起こされるキャッシュされた読み取り要求を削除することができます読み取り要求の終了ことを確認することです。
もちろん、この戦略にも時間がかかり、Redisのデータベースのマスタ・スレーブ同期考慮されるべきです。睡眠時間の最後の書き込みデータ：ビジネス・ロジック上のデータを読むことに時間のかかる基盤、我々は数百ミリ秒を追加することができます。たとえば、次のようにスリープ1秒。
3.キャッシュの有効期限を設定します
理論的には、キャッシュの有効期限を設定し、それが最終的なソリューションの一貫性を確保することです。データベースへのすべての書き込みは限りキャッシュ有効期限に達すると、読み取り要求が戻って自然に埋め戻しキャッシュを、新しいデータベースからの値とを読み、勝ちます。
プログラムの4の欠点
組み合わせたデュアル戦略+削除キャッシュのタイムアウト設定なので、最悪の場合には、データの矛盾がタイムアウト時間内に存在することである、とも時間のかかる書面による要求を増加させました。
二番目のオプション：非同期更新キャッシュ（サブスクリプションベースのバイナリログの同期メカニズム）
1.技術的な全体的なアイデア：
RedisのへのMySQL binlogの増分サブスクリプションのメッセージキューの消費量+ +増分データの更新
1）リードのRedis： Redisの中で実質的に熱的データ
2）書き込みのMySQL： CRUD操作は、MySQLです
3）更新データのRedis： MySQデータ操作のbinlogは、Redisのを更新します
2.Redis更新
1）操作データは、2つのブロックに分割されます。
- これは、合計金額（ライトワンスのRedisへのすべてのデータ）であります
- 一つは、増分（ライブアップデート）である
*
MySQLへの更新、挿入、delate変化データを参照して、増分であるここに。
2）メッセージ・キューを使用して、バイナリログ分析を読んだ後、各Redisのステーションのアップデートキャッシュデータをプッシュします。
例えばMySQLは新たな書き込み、更新、または削除操作を生成したら、それはRedisのバイナリログ関連するメッセージにプッシュすることができ、Redisのは、次にRedisの更新の記録をBINLOG。
MySQLのデータの整合性スタンバイバイナリログすることによって達成されるので、実際には、このメカニズムは、マスター・スレーブのMySQLバックアップ機構に非常に類似しています。
運河は、バックアップ要求スレーブmysqlデータベースの模倣である一方、データ更新のRedisは同じ効果に達したので、ここで運河（アリ、オープンソースのフレームワーク）を組み合わせることができ、あなたは、フレームを介してMySQLのバイナリログを購読することができます。
Rを達成するためにカフカ、RabbitMQのプッシュの更新など：もちろん、ここでのメッセージのプッシュツール、あなたは他のサードパーティ製を使用することができます
どのように一緒に学ぶために、空き情報がありませんか？
ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！