あなたの原理の理解の深さとのRedisの持続的な方法でテキスト

Redisの持続性は、一つはRDBの形式のスナップショットに基づいており、その他はAOFのログ形式に基づいており、それぞれの方法は、独自の長所と短所があり、この記事では、これらの2つの方法のRedisの持続性をご紹介します、希望、二つの方法を提供しますこの記事を読んだ後、あなたはRedisの両方の、より包括的かつ明確な理解を持っています。

RDB永続的なスナップショット

RDBスナップショットは、RDBは、永続的な方法でオープンRedisのデフォルトである、我々はRDBに関連した設定情報を見て、別のを開く必要はありませんチャットを開始します：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#   save ""
# 自动生成快照的触发机制 中间的是时间，单位秒，后面的是变更数据 60 秒变更 10000 条数据则自动生成快照
save 900 1
save 300 10
save 60 10000

# 生成快照失败时，主线程是否停止写入
stop-writes-on-bgsave-error yes

# 是否采用压缩算法存储
rdbcompression yes

# 数据恢复时是否检测 RDB文件有效性
rdbchecksum yes

# The filename where to dump the DB
# RDB 快照生成的文件名称
dbfilename dump.rdb

# 快照生成的路径 AOF 也是存放在这个路径下面
dir .

構成に関するRDB多くの情報、我々は唯一のメカニズムを変更し、スナップショットファイルの格納パスを生成する必要があり、さらに少ない調整するために必要なビジネスの彼らの量に基づくことができます。

：RDBの永続性の2つの方法があり、手動トリガと自動トリガ、次の2つのコマンドを使用して手動トリガ：

保存：RDBスナップショットの生成には、例えば、長い時間のための比較的大容量のメモリが閉塞を引き起こす可能性があり、完全なので、オンライン環境が推奨されなくなるまで、他のコマンドに応答する現在のRedisサーバをブロックします
bgsave：Redisのマスタープロセスが子プロセスをforkします、RDBスナップショット世代は、子供に責任が完了した後、子供は自動的に終了し、フォークの子プロセスをブロックに短期間のみをbgsave必要があり、このプロセスは非常に短いですが、それが推奨されます手動でトリガするには、このコマンドを使用します

手動トリガーコマンド外部を実行することに加えて、内部がRedisの永続機構は自動的にRDBをトリガし、Redisのは自動的にRDBは次の場合に永続トリガします。

上記のような構成の構成情報保存関連して、我々は、プロファイルsave 60 10000がm秒以内にn回のプレゼンス修正データセットを示す、構成「MN保存」形式として分類することができる場合に、自動的にbgsaveをトリガします。
コピー操作の全額がノードから実行した場合、メイン場合に、マスタノードが自動的に実行されているノードから生成bgsave RDBは、ファイルを送信します
Redisのをリロードするデバッグreloadコマンドを実行すると、それが自動的に保存操作をトリガーします
ときにshutdownコマンド、機能の永続ないオープンAOFはデフォルトbgsaveによって自動的に実行された場合

上記は、永続的なRDBで、ほとんどの場合に使用し、saveコマンド比較的小さいことがわかるし、我々はbgsaveの原理を見てみましょういくつかのものがあり、このコマンドbgsaveので、bgsaveコマンドです、フローチャートで始まることを開始するために開始されます：

bgsave動作フローチャート

次の手順についてbgsaveコマンド：

1、実施bgsaveコマンドは、現在RDB / AOF子プロセスが実行されているかどうかを決定するメイン処理をRedisの、存在する場合、bgsave直接バックダウンコマンドを実行しません。
図2に示すように、子プロセスを作成するために、親プロセスフォーク操作は、親プロセスのフォーク操作は他のコマンドを受け入れることができない閉塞をフォークします親プロセスの完了後にブロックされます。
3は、RDBの子プロセスが新しいファイルを作成するには、新しいRDB RDBファイルと元のファイルの交換が完了した後、現在のメモリデータの親プロセスに基づいて、一時的なスナップショットファイルを生成し、親プロセスに送信されたRDB完了通知のスナップショットを作成します

上記のコマンドは、同じ主題のRDBの内容、背後bgsaveものです、我々は長所と短所のRDBの永続性の要約、取るRDBの方法の利点を：

RDBは、瞬間Redisのデータノードのメモリのスナップショットでバックアップを実行するために非常に適している、または災害復旧のためのリモート・サーバー・ファイル・システムにアップロード
RDBのデータ復旧は、AOFよりもはるかに高速です

欠点も利点が存在している、欠点RDBは：

RDB永続的な方法でリアルタイムデータの永続性/秒レベルの永続性を行うための方法はありません。我々はすでに、頻繁に高いコストを行っ大物操作に属し、あなたが実行するたびにフォーク操作が子プロセスを作成する必要がありますbgsaveコマンドを知っています。
RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题

如果我们对数据要求比较高，每一秒的数据都不能丢，RDB 持久化方式肯定是不能够满足要求的，那 Redis 有没有办法满足呢，答案是有的，那就是接下来的 AOF 持久化方式

AOF 持久化方式

Redis 默认并没有开启 AOF 持久化方式，需要我们自行开启，在 redis.conf 配置文件中将 appendonly no 调整为 appendonly yes，这样就开启了 AOF 持久化，与 RDB 不同的是 AOF 是以记录操作命令的形式来持久化数据的，我们可以查看以下 AOF 的持久化文件 appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$6
mykey1
$6
你好
*3
$3
set
$4
key2
$5
hello
*1
$8

大概就是长这样的，具体的你可以查看你 Redis 服务器上的 appendonly.aof 配置文件，这也意味着我们可以在 appendonly.aof 文件中国修改值，等 Redis 重启时将会加载修改之后的值。看似一些简单的操作命令，其实从命令到 appendonly.aof 这个过程中非常有学问的，下面时 AOF 持久化流程图：

永続的なフローチャートAOF

在 AOF 持久化过程中有两个非常重要的操作：一个是将操作命令追加到 AOF_BUF 缓存区，另一个是 AOF_buf 缓存区数据同步到 AOF 文件，接下来我们详细聊一聊这两个操作：

1、为什么要将命令写入到 aof_buf 缓存区而不是直接写入到 aof 文件？

我们知道 Redis 是单线程响应，如果每次写入 AOF 命令都直接追加到磁盘上的 AOF 文件中，这样频繁的 IO 开销，Redis 的性能就完成取决于你的机器硬件了，为了提升 Redis 的响应效率就添加了一层 aof_buf 缓存层，利用的是操作系统的 cache 技术，这样就提升了 Redis 的性能，虽然这样性能是解决了，但是同时也引入了一个问题，aof_buf 缓存区数据如何同步到 AOF 文件呢？由谁同步呢？这就是我们接下来要聊的一个操作：fsync 操作

2、aof_buf 缓存区数据如何同步到 aof 文件中？

aof_buf 缓存区数据写入到 aof 文件是有 linux 系统去完成的，由于 Linux 系统调度机制周期比较长，如果系统故障宕机了，意味着一个周期内的数据将全部丢失，这不是我们想要的，所以 Linux 提供了一个 fsync 命令，fsync 是针对单个文件操作（比如这里的 AOF 文件），做强制硬盘同步，fsync 将阻塞直到写入硬盘完成后返回，保证了数据持久化，正是由于有这个命令，所以 redis 提供了配置项让我们自行决定何时进行磁盘同步，redis 在 redis.conf 中提供了appendfsync 配置项，有如下三个选项：

# appendfsync always
appendfsync everysec
# appendfsync no

always：每次有写入命令都进行缓存区与磁盘数据同步，这样保证不会有数据丢失，但是这样会导致 redis 的吞吐量大大下降，下降到每秒只能支持几百的 TPS ，这违背了 redis 的设计，所以不推荐使用这种方式
everysec：这是 redis 默认的同步机制，虽然每秒同步一次数据，看上去时间也很快的，但是它对 redis 的吞吐量没有任何影响，每秒同步一次的话意味着最坏的情况下我们只会丢失 1 秒的数据，推荐使用这种同步机制，兼顾性能和数据安全
no：不做任何处理，缓存区与 aof 文件同步交给系统去调度，操作系统同步调度的周期不固定，最长会有 30 秒的间隔，这样出故障了就会丢失比较多的数据。

这就是三种磁盘同步策略，但是你有没有注意到一个问题，AOF 文件都是追加的，随着服务器的运行 AOF 文件会越来越大，体积过大的 AOF 文件对 redis 服务器甚至是主机都会有影响，而且在 Redis 重启时加载过大的 AOF 文件需要过多的时间，这些都是不友好的，那 Redis 是如何解决这个问题的呢？Redis 引入了重写机制来解决 AOF 文件过大的问题。

3、Redis 是如何进行 AOF 文件重写的？

Redis AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程，重写之后的 AOF 文件会比旧的 AOF 文件占更小的体积，这是由以下几个原因导致的：

进程内已经超时的数据不再写入文件
旧的 AOF 文件含有无效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于 list、set、hash、zset 等类型操作，以 64 个元素为界拆分为多条。

重写之后的 AOF 文件体积更小了，不但能够节约磁盘空间，更重要的是在 Redis 数据恢复时，更小体积的 AOF 文件加载时间更短。AOF 文件重写跟 RDB 持久化一样分为手动触发和自动触发，手动触发直接调用 bgrewriteaof 命令就好了，我们后面会详细聊一聊这个命令，自动触发就需要我们在 redis.conf 中修改以下几个配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage：代表当前 AOF文件空间（aof_current_size）和上一次重写后 AOF 文件空间（aof_base_size）的比值，默认是 100%，也就是一样大的时候
auto-aof-rewrite-min-size：表示运行 AOF 重写时 AOF 文件最小体积，默认为 64MB，也就是说 AOF 文件最小为 64MB 才有可能触发重写

满足了这两个条件，Redis 就会自动触发 AOF 文件重写，AOF 文件重写的细节跟 RDB 持久化生成快照有点类似，下面是 AOF 文件重写流程图：

書き換えファイルAOF

AOF 文件重写也是交给子进程来完成，跟 RDB 生成快照很像，AOF 文件重写在重写期间建立了一个 aof_rewrite_buf 缓存区来保存重写期间主进程响应的命令，等新的 AOF 文件重写完成后，将这部分文件同步到新的 AOF 文件中，最后用新的 AOF 文件替换掉旧的 AOF 文件。需要注意的是在重写期间，旧的 AOF 文件依然会进行磁盘同步，这样做的目的是防止重写失败导致数据丢失，

Redis 持久化数据恢复

私たちは、Redisのがメモリに基づいていることを知って、マシンを再起動ダウンタイムやその他の要因は、我々のデータのすべてにつながるので、メモリに保存されているすべてのデータは、サーバーが再起動したときに、持続性が何をした理由である、失われますRedisのは、我々のデータは、再起動前にデータに復元され、その結果、ファイル内の永続的なデータからロードされます、どのようにこの1つのRedisのデータの回復が達成されますか？のは、データ復旧のフローチャートを見てみましょう。

Redisのデータ復旧

Redisのデータ回復プロセスは、RDBの速いAOFファイルよりも回復が、それでも優先させて頂きますが、AOF文書をロードするために、なぜ優先順位は、AOFファイル、AOFファイルが存在しない場合は、負荷RDBへのファイルの試みを復元することである、比較的単純なのですか？私は個人的にRDBよりもより完全でファイルデータAOF AOFの互換性ということは、データの読み込みが成功しなかった場合ときがRDB / AOF、Redisのサービスが起動に失敗することに留意すべきであると考えます。

遂に

現在、インターネット上の大物Redisのチュートリアルシリーズをたくさん持っている、任意の類似性は、私を許してください。元は容易ではない、コードワードは容易ではないですが、また、我々がサポートできることを願っています。また、テキストに誤ったが、何かがなさ見ると、あなたに感謝します。

スキャンコード懸念マイクロチャネルのパブリック番号を歓迎：一緒に学ぶ「フラットヘッドの弟の技術のブログを、」最初のコロンビアの平和は、一緒に進行します。

技術的ボーエンのマイナス弟