1、Redisの5つのオブジェクト：
Redisの中に5つのオブジェクト、それぞれ、文字列、リスト、ハッシュ、セット、ソートセットがあります。
これらの5つのオブジェクトは、各コードを達成するために、独自のコードを持って、異なる独自の利用シナリオを持っています。
コマンド：オブジェクトがキー名エンコードキーを確認するためにエンコードタイプを。
、文字列（文字列タイプ）：
INT：整数は、long型を保存するために使用することができます。
EMBSTR：文字列に加えて、長い間、これは倍精度浮動小数点数が、必要な長さ<= 44を保存することができます。
RAW：保存文字列の長さは、長い間、ダブル44以上です。
B、一覧（リスト）：
クイックziplistを最適化するために、複数のziplistを含みます。
リスト-MAX-ziplistサイズの整数値は、ノードクイックziplist上の数を示す場合、負の数はziplist（式：KB = -1 * 2 ^ N）の大きさを示しています。
- -3：16キロバイトを超えることができないziplistサイズクイックの兄弟ノード。
- -2：ziplistサイズクイックの兄弟ノードが8キロバイト（超えることができないデフォルト値）。
- -1：ziplistは兄弟ノードクイックの4キロバイトのサイズを超えません。
リストの両端は、高効率を達成するように設計されているので、この条件は、によって満たされている場合、中間データ抽出効率が低く、リスト圧縮深度メモリセーブさらに中間圧縮データの構成に関する。
- 0：特別な値、圧縮されていない（デフォルト値）。
- 1：1、圧縮された中間ノードを圧縮しないクイック各ノードの両端。
- 2：各端部にクイック二つのノードは、圧縮された中間ノードが圧縮されません。
- などなど。
C、ハッシュ（辞書）：
ときに同時に会う二つの条件でハッシュオブジェクト、ziplistコード：
- 以下64バイト以上の長さのすべての重要な要素は、デフォルト値がハッシュMAX-ziplist値を変更することによって変更することができます。
- キー値の数が少ない512より、デフォルト値はハッシュMAX-ziplst・エントリを変更することによって改変することが可能です
D、セット（セット）：
次の2つの条件は、コーディングINTSETを使用して、オブジェクトのコレクションをコレクションオブジェクトを満たした場合
- オブジェクトのコレクションのすべての要素の保存値の整数です。
- 512を超えていないキー値の数は、デフォルト値が設定ファイル属性にセットMAX-インセット・エントリを変更することによって変更することができます。
E、ZSET（注文したセット）：
ときにオブジェクトziplist符号化の順序集合を使用して、次の条件の両方のオブジェクトのセットを注文しました。
以下64のバイトよりも長さが格納されたオブジェクトの順序付けられたセットのすべてのメンバーは、デフォルト値がZSET-MAX-ziplist-value属性プロファイルを変更することによって変更することができます。
格納されたオブジェクトの順序付けられた集合の全ての要素の数が128よりも小さい場合、デフォルト値は、設定ファイル属性にZSET-MAX-ziplist・エントリを変更することによって変更することができます。
2、Redisの持続性
、RDBの永続性：
RDB永続的な方法であるプロセスのスナップショットは、ディスクを形成するように、現在のプロセスデータが格納されている手動および自動トリガに分け、。
マニュアル：
- コマンドを保存する：コマンドが保存メインプロセスをブロックし、大量のデータが通常のサービス要求に影響する場合。
- bgsaveコマンド：bgsaveは子プロセスをforkします、子プロセスのフォーク時間が短時間ブロックされ、ブロックされます。
自動トリガ条件：
- よると、（秒）単位時間当たりのデータの修正時刻は次のようにトリガーされ、デフォルトの設定は次のとおりです。
- 900 1保存
- 300 10保存
- 60 10000保存
- ノードから全額レプリケーション時間。
- 実行、デバッグreloadコマンドをするとき。
- 実行shutdownコマンドの時間AOFなっていない場合は、実行bgsaveを。
RDB永続的な手順：
- Bgsaveコマンド実行後、親プロセスは、（RDB / AOPのような）子プロセスが存在するか否かを決定する直接戻った場合、実行されています。
- 子プロセスを作成するには、親プロセスのフォーク操作、そして親プロセスは、（最新の時間のかかる操作を表示するには、情報統計ビューlatest_fork_usec Aフォークオプション、微妙なユニットに命令することができる）ブロックします。
- 親プロセスフォークの後、bgsaveは「節約背景が開始」を返し、親プロセスを詰まらせません。
- RDBの子プロセスがファイルを作成します。
RDBの長所と短所：
利点：
- RDB永続ファイルは非常にコンパクトである（圧縮）、それはあなたが簡単に、リモートデータセンターにデータを転送することができ、時間のポイントにデータを保存します災害復旧のために適しました。
- bgsaveメモリは、ときにサブプロセスを使用して操作を実行するために最大限にするために、最適化のRedisのパフォーマンスを。
- AOFと比較して、中に大量のデータを復元速くなります。
短所：
- ので、それは、データをリアルタイムで保存されていないため、それはダウンタイム中に、いくつかのデータが失われます。
- 大量のデータ場合、フォークプロセスは非常に時間がかかるであろうフォークがブロック場合、メインスレッドにも影響されるであろう。
- RDB方式的持久化的文件是特定的格式，可读性、兼容性差（不同版本的RDB格式都不一样）。
b、AOF持久化：
RDB与AOF两种持久化方式只能二选一，若需要使用AOF需要通过配置文件开启，因为默认是不开启的。
配置：
- 是否开启APO（默认false）：appendonly yes。
- AOF文件名（默认appendonly.aof）：appendfilename xxx.aof。
- 保存路径：通过dir配置指定。
AOF持久化是通过保存Redis服务器所执行的命令来记录数据库的状态，每执行一个命令就会往AOF文件后追加一个命令。
AOF采用RESP协议写入数据：
单行字符，+开头。
多行字符，$开头，后跟字符串长度。
整数值，:开头，后跟整数字符串形式。
错误消息，-开头。
数组，*开头，后跟数组长度。
AOF持久化流程：
- 首先每次追加直接操作磁盘的话，性能上肯定不高，所以Redis会先将命令追加到aof_buf中。
- 然后缓冲区再根据相应的策略将缓冲区的内容同步到磁盘。
- 并且Redis还会定期的对AOF文件进行重写，以达到压缩的目的。
- 服务器重启时可以通过AOF文件恢复数据。
为什么AOF文件能够重写：
- 过期的数据可以不写入。
- 无效的数据可以不写入。
- 多条命令可以合并成一个写入。
AOF持久化的优缺点：
优点：
- 支持秒级持久化。
- 可用于不同版本的Redis服务器，兼容性强。
- 可读性高。
缺点：
- 文件大，恢复数据慢。
3、Redis主从复制
a、主从复制是什么：
在绝大多数中间件中都会具有主动复制这一功能，而多数也就是为了服务的高可用罢了；Redis也不例外，它提供了复制功能，实现了相同数据的多个副本。
b、搭建复制三种方式：
- 从节点配置文件中加入slaveof <masterIp> <masterPort>
- 启动命令后加入--slaveof <masterIp> <masterPort>
- 通过命令laveof <masterIp> <masterPort>
注意：
- slaveof是异步命令，节点保存主节点信息后便返回，后续复制就从在节点异步进行。
- 由于复制模式是单向的，从节点接收写命令的话无法让主节点感知，这样会造成数据不一致的情况，所以从节点需要配置成只读模式（slave-read-only=yes）。
c、主动复制原理：
流程：
- 保存主节点信息：从节点保存主节点信息（ip、port）。
- job网络连接主节点：从节点内部通过job来维护复制相关逻辑，当job发现新的主节点后会尝试与该节点建立网络连接；若无法连接job会无限重试直到连接成功，或执行slaveof no one命令取消复制。
- 发送ping给主节点：从节点会发送ping命令，检测主动之间套接字是否可用，和主节点当前是否可接受处理命令。
- 权限验证：如果主节点设置了requirepass则需要密码验证，且从节点需要有相同的配置才能通过验证；如果验证失败复制终止，从节点断开连接。
- 连接成功：发送从节点的ip、port给主节点。
- 数据同步：依据情况主从之间进行全量或部分复制。
- 命令传播：当上述步骤完成后，也算是完成了复制的建立流程，接下来主节点会持续地把命令发送给从节点来保证主从数据的一致性。
全量复制于部分复制：
）全量：psync ? -1
一般用于初次复制的场景（虽然早期的Redis也仅支持全量复制），它会一次性的打包所有的数据给从节点，当数据量较大时会主从节点和网络造成很大的开销。
）部分：psync <runid> <offset>
用于复制过程中宕机或网络闪断的场景，主节点会补发数据给从节点。因补发数据远小于全量数据，所以可以有效的避免全量复制的开销。
部分复制的三要素：
- 复制偏移量：参与复制的主从节点都会维护自身的偏移量，主节点在处理完写命令后会累加这个偏移量，从节点会每秒的上报偏移量，因此主节点就拥有了主从的偏移量。
- 温馨提示：可以通过主节点master_repl_offset信息判断主动节点相差的数据量，从而得知复制的健康度。
- 复制积压缓冲区：主节点执行写命令时不但会将数据同步给从节点，还会写入到复制积压缓冲区。部分复制时会根据缓冲区的偏移量来判断从哪开始复制。
- 运行ID：若主从runid相同，则表示此主从之前同步过，进行部分复制即可；若不同则表示从节点之前同步的主节点并非此主节点，所以要进行全量复制。
psync命令流程图：
