Redis の永続性と一貫性のソリューションは「面接で尋ねる必要がある」

それは非常に簡単です: キャッシュが有効になっている場合、データをクエリするたびに、最初に Redis から確認する必要がありますか? そうですね、初めて確認してから、MySQL でデータ値を変更し、次にデータを確認しましょう。このとき、2 回目のクエリで取得したデータ値と、変更した MySQL のデータ値が一致しない、つまり 2 つのクエリで返された結果が同じであることが判明すれば、 Redis キャッシュが有効になりました。

MySQL と Redis データ間の非同期の問題を解決するにはどうすればよいですか?

方法 1: Redis キャッシュを直接クリアし、データベースを再度クエリします~! (これは症状を治療しますが、根本的な原因は治療しません)

方法 2:MySQL と Redis 間のデータ同期は強力な一貫性を保つことができません( それは不可能です分散システムで強力な一貫性を確保するため)、一部の最終的な一貫性ソリューションのみを使用できます。つまり、短期間のデータ遅延と不整合は許容されます。ただし、最終データは一貫している必要があります。MQ を直接使用して MySQL の bin ログファイルを非同期的にサブスクライブし (挿入/削除/更新)、同期を増分します。 Redis (増分同期の実装) => 最終的な整合性ソリューション。

方法 3:Alibaba の canal フレームワークを使用する:最下層は MQ を使用してサブスクライブします。 bin log 、 canal は、単純に増分データを同期するために使用されるツールとして理解できます。

補足：強整合性、弱整合性、結果整合性についてわかりやすく理解！

分散アーキテクチャに関しては、「一貫性」の問題を避けることはできません。「一貫性」には実際にはデータの一貫性 と< /span> (データの一貫性。この記事では主にトランザクションの一貫性）。

データの整合性の問題が発生する唯一の原因はレプリケーションです。

すべての書き込みおよび読み取りリクエストの処理に 1 つのデータベースのみを使用する場合、データの一貫性の問題はまったく発生しません。ただし、中規模および大規模なプロジェクトでは、データのコピーを複数のデータベースに保存する必要があることがよくあります。 1 つのデータベース (つまりレプリケーション) には、次の 3 つの理由があります:

データベースの一部に障害が発生しても、システムは正常に動作し続けます (高可用性)

データを地理的にユーザーの近くに保持します (待ち時間が短くなります)。

処理できるマシンの数を拡大する読み取りリクエスト (スケーラビリティ、読み取りスループットの向上)

強い一貫性と弱い一貫性

実際、データの整合性には、強整合性と弱い整合性の 2 種類しかありません。

強い一貫性は線形一貫性とも呼ばれますが、これを除く他のすべての一貫性はすべて特殊なケース整合性が弱い。

強い整合性、弱い整合性、および最終的な整合性は、分散システムにおける異なる整合性モデルであり、システム内の大量のデータコピー間の整合性状態を記述するために使用されます。

強力な一貫性:強力な一貫性モデルでは、システムは、グローバルに一貫したデータコピーがどのノードでも表示されることを保証します。つまり、クライアントが読み取りまたは読み取りを行うとき、またはデータを書き込むと、最新かつ最も正確な結果が得られ、書き込み操作が完了すると、すべてのコピーがすぐに有効になります。

弱い整合性:弱い整合性モデルでは、一定期間、システム内のデータコピー間で不整合が発生する可能性があります。つまり、書き込み操作の後、異なるデータコピーが作成される可能性があります。弱い整合性モデルでは、特定のデータ遅延や競合は許容されますが、最終的に整合性のある状態に到達する必要があります。

結果整合性:結果整合性モデルは、弱い整合性モデルの特殊なケースです。結果整合性モデルでは、時間の経過とともに、システムのデータコピーは最終的に一定のレベルに達します。時間が経っても安定した状態。最終整合性モデルはパフォーマンスと可用性の両方を考慮しており、分散システムで広く使用されています。

特定のシナリオとニーズに基づいて、適切な整合性モデルを選択する必要があります。強い整合性モデルは、非常に高いデータ整合性を必要とするシナリオに適していますが、弱い整合性モデルは、最終的なデータ整合性を必要とするシナリオに適しています。整合性モデルは、高いパフォーマンスと高可用性を必要とする分散システムに適しています。

2. Redis 永続化メカニズム

Redisが何らかの理由でダウンしてもデータは失われない原理はRedisの永続化機構ですよ～！

永続化とは、サーバーのダウンタイムによるメモリデータの損失を防ぐために、メモリ内のデータをローカルディスクに永続化することです。

EHCAHE: は 1 次キャッシュに属し、JVM の組み込みキャッシュです。

ほとんどのキャッシュフレームワークには基本的な機能があります: 削除戦略、永続化メカニズム (Memcached だけが奇妙です。Memcached は単純なキャッシュフレームワークであり、永続化メカニズムはありません)...

マルチレベルキャッシュはデコレーションデザインパターンを使用します。これは、以前のキャッシュのコード自体には影響を与えないのと同じですが、キャッシュを強化できるため、デコレーションモードを使用してマルチレベルキャッシュが実装されます~!

マルチレベルキャッシュはデコレーションモードを使用して再構築できます~!

Redis の永続化メカニズム: Redis は、メモリ内のデータをディスクにバックアップする永続化メカニズムを提供します。停電またはダウンタイムの後に Redis を再起動すると、データが失われないように、ディスク上のファイルがメモリに再ロードされます。

永続化メカニズムにより、データの書き込み中に Redis プロセスがクラッシュした場合でも、データは失われないことが保証されます~!

Redis は、RDB (デフォルト) と AOF メカニズムという 2 つの永続化メカニズムを提供します。

Redis の永続化メカニズムには、RDB (デフォルト) と AOF という 2 つのオプションがあります。

Redis はデフォルトで RDB を使用してデータの永続性を実現します。

完全同期と増分同期の実装の違いは次のとおりです。

完全同期と増分同期はどちらも分散システムで一般的に使用されるデータ同期方法です。

完全同期

完全同期: スケジュールされた同期。これは、毎日タイミングを計る（ピーク期間を避ける）か、定期的な実装を使用することを意味します。データを別の場所にコピーします。たとえば、900 秒以内に Redis で 10 回の書き込み操作を実行すると、すべてのデータが永続的にハードディスクに書き込まれます。 a>またはすべてのデータをソースノードからターゲットノードに送受信して、ターゲットノードとソースノードのデータが完全に一致していることを確認します。

完全同期は通常、分散システム全体のバックアップ、再構築、初期化などのシナリオで使用されます。

完全同期を実行すると、同じデータレコードがすでに存在するかどうかに関係なく、データベース全体のデータがターゲットの場所にコピーされます。そのため完全同期には送信が必要です。したがって、データ量が比較的大きい場合は、時間がかかり、多くのネットワーク帯域幅とシステムリソースを占有します、完全な同期頻度はそれほど高くありませんが、データ損失が発生する可能性があります。

増分同期

増分同期:記録動作の操作を使用してデータ同期を実現します。、つまり、変更されたデータのみがソースノードとターゲットノードの間で送信されるため、ターゲットノードとソースノード間のデータの同期が確保されます。

増分同期は以前の同期ステータスとタグに基づいているため、変更された部分のみ、つまり変更されたデータのみが記録され、ターゲットの場所に転送されます。既存のデータレコードは繰り返しコピーされないため、増分同期のオーバーヘッドは軽減されます。比較的小さいですが、増分同期のプロセスは比較的頻繁であり、その頻度は非常に高くなります。頻度が非常に高い場合、Redis サーバー全体の同期に対する負荷は比較的大きくなりますが、データを確実に同期させることができます。失われていません。

完全同期と増分同期の比較:

増分同期は完全同期よりも多くのサーバーメモリを消費しますが、データ同期をより確実に行うことができます。

Redis では、マスターとスレーブのレプリケーションが典型的な増分同期シナリオです。Redis のマスターノードはデータをディスクに保存し、コマンドを通じてデータを変更できます。スレーブノードに送信します。スレーブノードがコマンドを受信すると、データの整合性を確保するために送信順に順次実行されます。

永続化メカニズム - RDB 永続化 - 完全同期 - メモリデータをディスクに永続化

RDB の正式名は Redis データベースバックアップファイル (Redis データバックアップファイル) です。Redis データスナップショットとも呼ばれ、デフォルトの永続化方法です。 Redis の。

RDBはスケジュール永続化機構を採用しているため、RDBは完全同期永続化方式を採用しており、メモリ上のデータを一定期間ごとにスナップショットの形でハードディスクに保存します。生成される対応するデータファイルはdumpとrdbであり、ただし、サーバーに問題があり、ダウンタイムによりデータが失われる可能性があります。

簡単に言うと、 Redis メモリ内のすべてのデータをバイナリとスナップショットの形式でディスクに記録/保存します。Redis インスタンスに障害が発生して再起動すると、このスナップショットファイルがディスクから読み取られ、メモリにロードされてデータが復元されます。

ディスク: ディスクからロードされたディスク DB

RDBバックアップファイル：dump.rdb =>バイナリ形式でデータを保存するバイナリファイル

スナップショットファイルは RDB ファイルと呼ばれ、最後のスナップショットが生成されたときに Redis 内のすべてのデータを保存します。デフォルトでは、現在の実行ディレクトリに保存されます。

Redis のおかげで、RDB ストレージをデフォルトで有効にすることができました~!

RDB永続化の実行タイミング

RDB 永続化は、パッシブ操作 (1、2、3) + アクティブ操作 (4) の 4 つの状況で実行されます。

1 つと 2 つはどちらも手動でスナップショット操作をトリガーし、Redis にバックアップを実行させます。

手動で保存コマンドを呼び出して実行すると、RDB を 1 回すぐに実行できます: DB がディスクに保存されました: ディスクに保存、保存コマンド Redis によって提供される RDB バックアップ操作を実行するメインプロセス Redis の作業スレッドはシングルスレッドであるため、保存命令の実行は他のすべてのコマンドの実行をブロックするため、推奨されません。 Redis はデータ移行中にのみ使用できます。この問題を回避するために、別の命令が提供されています: bgsave!
bgsave コマンドを手動で呼び出して実行し、RDB を非同期で実行します。bg はバックグラウンドを指し、バックグラウンドで実行されます。bgsave コマンドは、独立したフォークサブプロセスを開いて RDB バックアップ操作を実行し、メインプロセスがコマンドの処理を継続できるようにします。メインプロセスへの影響を回避メインプロセスユーザーリクエストは影響を受けることなく継続的に処理できます。
Redis がシャットダウンされる (Redis サーバーがシャットダウンされる) と、保存コマンドが実行され、RDB の永続性を実現するために RDB バックアップ操作が実行されます: 終了する前に最終的な RDB スナップショットを保存する終了する前に最終的な RDB スナップショットを保存します。ただし、注意: 突然の停電が発生した場合、Redis サーバーがアクティブにシャットダウンされるまで、RDB バックアップ操作は実行されません。

4. RDB 条件がトリガーされたとき: Redis 内には RDB をトリガーするためのメカニズムがあり、これは redis.conf ファイルにあります。形式は次のとおりです。

RDB：メモリ上のデータをRDBファイルに直接ダンプ＆バックアップ～！

構成ファイルの save パラメーターを使用してスナップショットサイクルを定義します - Redis サーバーのダンプ/バックアップスナップショットの頻度:

# 900秒内，如果至少有1个key被修改，则执行bgsave命令来指定RDB备份操作 如果是save "" 则表示禁用RDB
save 900 1  如果900s(15分钟)内有一个Key发生变化被修改,就触发一次RDB
save 300 10 如果300s(5分钟)内有十个Key发生变化,就触发一次RDB
save 60 10000 如果60s(1分钟)内有一万个Key发生变化(代表60s内至少执行10000次修改责编触发RDB),就触发一次RDB

RDB の他の構成は、redis、conf ファイルで設定することもできます。

# 是否对RDB备份文件做压缩处理,降低RDB文件的体积
# 建议不开启,压缩也会消耗cpu,影响Redis的性能磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# RDB文件保存的路径目录   ./表示当前目录
dir ./

RDBのメリットとデメリット

アドバンテージ：

ファイル dump.rdb は 1 つだけあり、永続化に便利です。

パフォーマンスを最大化するには、子プロセスをフォークして永続的な書き込み操作を実行し、メインプロセスがコマンドの処理を継続できるようにします。

データセットが大きい場合、起動効率は AOF よりも高くなります。

欠点:

停電が発生すると、RDB はデータを失うリスクにさらされます。これは、RDB が前回トリガーされたと仮定して、RDB は一定の間隔で永続化されるためですが、次回トリガーされる前に突然停電が発生し、その間に書き込みが行われるためです。 2 つの RDB データ入力時にデータ損失のリスクがあります。

RDBはメモリ上のデータやスナップショットを直接ディスクに保存しますが、RDBファイルの書き込みには時間がかかり、パフォーマンスも消耗します～！メモリに保存されているデータの量が比較的大きいことが前提となります。

耐災害性とは、ハードウェア障害、ソフトウェアエラー、その他の予期せぬ異常に直面しても、利用可能な一部またはすべての機能を維持するシステムの能力を指します。

RDB の完全同期はほとんど使用されず、AOF 増分同期が一般的に使用されます~!

永続化メカニズム - AOF 永続化 - 増分同期 - データを変更するコマンドの永続化

AOF はデータログ操作に基づく永続化であるため、AOF は増分同期永続化ソリューションを採用しています~!

AOF は追加専用ファイルの略です。
AOF バックアップファイル: appendonly.aof
AOF 永続性とは、Redis サーバーによって処理されるすべての書き込みコマンド/書き込み操作 (set command=> データ変更に影響する命令のみを記録=> 追加、削除、および変更) が AOF ファイルの末尾に追加されて記録されることを意味します。 Redis サーバーが受信した各書き込み操作コマンドは、テキスト形式でコマンドログファイルとみなすことができます。
Redis でデータを復元する必要がある場合は、AOF ファイル内のコマンドを再実行するだけです。
AOF 永続性は、各書き込み操作の後に AOF ファイルに追加されるため、より高いデータセキュリティを提供し、データ損失のリスクを回避できます。

AOF はデフォルトでオフになっています。AOF をオンにするには、redis.windows.conf 構成ファイルを変更する必要があります。

# 是否开启AOF持久化功能，默认是no,是关闭的,如果需要开启AOF持久化,则需要将no改为yes
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF のコマンド記録の頻度は、redis.windows.conf ファイルを通じて構成することもできます。 AOF の 3 つの同期戦略

# 表示每执行一次写命令,就立即记录到AOF文件(写一次,保存一次),能够实时的保证数据的安全性,保证数据不丢失,但是效率非常低
appendfsync always 
# sec是second-秒的简写,写命令执行完先放入AOF缓冲区,然后表示每隔1秒将缓冲区数据写到AOF文件,是默认方案,该方案是AOF的缺省策略。
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

AOF の 3 つの同期戦略の比較:

データの同期が確実で効率が良いeverysecの使用をお勧めしますが、最大1秒以内のデータが失われる可能性があるという欠点もありますが、効率は非常に高いです~!

AOF の長所と短所:

アドバンテージ：

データセキュリティ、AOF 永続性は appendfsync 属性で設定でき、書き込みコマンド操作が実行されるたびに常に aof ファイルに記録されます。

追加モードでファイルを書き込むことで、サーバーが途中でダウンした場合でも、redis-check-aof ツールを通じてデータの整合性の問題を解決できます。

欠点:

AOF ファイルは RDB ファイルより大きく、リカバリが遅くなります

データセットが大きい場合、RDBよりも起動効率が低くなります。

AOFファイルの書き換え

これは記録コマンドであるため、AOF ファイルは RDB ファイルよりもはるかに大きくなります、。また、AOF は、RDB ファイルへの複数の書き込みを記録します。同じキー操作ですが、最後の書き込み操作のみが意味を持ちます。
そのため、Redis は bgrewriteaof command=> を実行することで AOF を実行するコマンドを提供します。ログは書き換えることができます、AOF ファイルは書き換えることができます。AOF ファイルの書き換えは、AOF 永続化メカニズムを最適化する Redis の操作です。より小さい AOF ファイルを使用して元の AOF ファイルを置き換えることにより、ディスク領域の使用量が削減され、読み取りパフォーマンスが向上します。期限切れまたは削除されたデータコマンドを削除/削除することで => データのみが記録されます。キーの最後の変更では、同じことを達成するために最も少ないコマンドが使用されます。これにより、AOF ログファイルのサイズがある程度削減されます。
AOF ファイルの書き換えのプロセスは、元の AOF ファイルを単に圧縮または整理するだけではなく、メモリ内のデータを読み取って新しい AOF ファイルを再構築し、Redis の現在のメモリ内のデータを走査し、それを変換して AOF ファイルに書き込みます。新しい AOF ファイルをコマンド形式で作成します。プロセス全体は元の AOF ファイルの影響を受けないため、元の AOF ファイル内の期限切れまたは削除されたデータを削除できます。

AOF ファイルの書き換えをトリガーするには 2 つの方法があります。

手動トリガー:bgwriteaof コマンド を Redis サーバーに送信して、AOF ファイルの再構築を手動でトリガーします。。書く。
自動トリガー: redis.conf 構成ファイルで auto-aof-write-percentage パラメーターと auto-write-min-size パラメーターを設定することにより、AOF ファイルの書き換えを自動的にトリガーする条件を構成します。 Redis はまた、トリガーのしきい値に達したときに AOF ファイルを自動的に再書き込みします。AOF ファイルのサイズが最後のファイルと比較して指定されたパーセンテージを超えて増加した場合、または AOF ファイルのサイズが指定された最小ボリュームを超えた場合、Redis は AOF ファイルを自動的に書き換えます。 AOF ファイルの書き換えを自動的にトリガーします。

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

注意が必要:AOF ファイルの書き換えには時間がかかり、CPU リソースが消費されます。操作により、 Redis サーバーに負荷がかかるため、運用環境では注意して使用する必要があります。

RDBとAOFの比較

寸法	RDB	AOF
永続化メソッド	定期的にメモリ全体のスナップショットを作成します	実行された各書き込みコマンドを記録する
データの整合性	不完全であり、バックアップの間に失われます	比較的完成度が高いが、ブラッシング方法に依存する
ファイルサイズ	圧縮が行われます。ファイルサイズは小さいです	コマンドを記録すると、ファイルサイズが非常に大きくなります
ダウンタイムの回復速度	すぐ	遅い
データ復旧の優先順位	データの整合性が aof ほど良くないため、低い	データの整合性が高いため高
システムリソースの使用量	大量の CPU とメモリの消費量	少ない、主にディスク IO リソースですが、AOF の書き換えは多くの CPU およびメモリリソースを占有します
使用するシーン	数分間のデータ損失を許容し、より高速な起動速度を追求	データセキュリティに対する高い要件が一般的です

RDB と AOF にはそれぞれ独自の長所と短所があります。RDB と AOF の永続性を同時に有効にすることを選択すると、Redis の再起動時に RDB ファイルを使用してデータをロードし、 AOF ファイル内のコマンド~ !