From 0ca51dabd80f0aef11d63f6e2b43aa5a35e3c7f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=BD=97=E7=A5=A5?= <1366971433@qq.com>
Date: Fri, 13 Dec 2019 17:38:01 +0800
Subject: [PATCH] redis
---
notes/Redis_哨兵模式.md | 6 +---
notes/Redis_持久化.md | 12 +++----
notes/Redis_数据类型和常用命令.md | 40 +++++++++++-----------
notes/Redis_集群模式.md | 20 ++++-------
4 files changed, 34 insertions(+), 44 deletions(-)
diff --git a/notes/Redis_哨兵模式.md b/notes/Redis_哨兵模式.md
index ca3aa8b..7cc4068 100644
--- a/notes/Redis_哨兵模式.md
+++ b/notes/Redis_哨兵模式.md
@@ -52,12 +52,11 @@ slaveof{newMasterIp} {newMasterPort}
哨兵模式的主要作用在于它能够自动完成故障发现和故障转移，并通知客户端，从而实现高可用。哨兵模式通常由一组 Sentinel 节点和一组（或多组）主从复制节点组成，架构如下：
-
### 2.1 架构说明
#### 1. Sentinel 与 Redis Node
-Redis Sentinel 是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送`info`命令获取其拓扑结构和状态信息。
+Redis Sentinel 是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送`info`命令获取其拓扑结构和状态信息。
#### 2. Sentinel 与 Sentinel
@@ -181,16 +180,13 @@ redis-sentinel sentinel-26381.conf
使用 `ps -ef | grep redis` 命令查看进程，此时输出应该如下：
-
可以使用 `info replication` 命令查看 Redis 复制集的状态，此时输出如下。可以看到 6379 节点为 master 节点，并且有两个从节点，分别为 slave0 和 slave1，对应的端口为 6380 和 6381。
-
可以使用 `info Sentinel` 命令查看任意 Sentinel 节点的状态，从最后一句输出可以看到 Sentinel 节点已经感知到 6379 的 master 节点，并且也知道它有两个 slaves 节点；同时 Sentinel 节点彼此之间也感知到，共有 3 个 Sentinel 节点。
-
## 参考资料
1. 付磊，张益军 . 《Redis 开发与运维》. 机械工业出版社 . 2017-3-1
diff --git a/notes/Redis_持久化.md b/notes/Redis_持久化.md
index 44c26e2..692c4ef 100644
--- a/notes/Redis_持久化.md
+++ b/notes/Redis_持久化.md
@@ -45,9 +45,9 @@ RDB 机制是以指定的时间间隔将 Redis 中的数据生成快照并保存
RDB 文件默认保存在 Redis 的工作目录下，默认文件名为 `dump.rdb`，可以通过静态或动态方式修改：
-+ 静态配置：通过修改 `redis.conf` 中的工作目录`dir`和数据库存储文件名`dbfilename`两个配置
++ 静态配置：通过修改 `redis.conf` 中的工作目录`dir`和数据库存储文件名`dbfilename`两个配置；
-+ 动态修改：通过在命令行中执行以下命令
++ 动态修改：通过在命令行中执行以下命令：
```shell
config set dir{newDir}
@@ -56,7 +56,7 @@ RDB 文件默认保存在 Redis 的工作目录下，默认文件名为 `dump.rd
**2. 压缩算法**
-Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理， 这样可以减少占用空间和网络传输的数据量，但是压缩过程会耗费 CPU 的计算资源， 你可以按照你的实际情况，选择是否启用。可以通过修改 `redis.conf` 中的`rdbcompression `配置项或使用以下命令来进行动态修改：
+Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理， 这样可以减少占用空间和网络传输的数据量，但是压缩过程会耗费 CPU 的计算资源， 你可以按照实际情况，选择是否启用。可以通过修改 `redis.conf` 中的`rdbcompression `配置或使用以下命令来进行动态修改：
```shell
config set rdbcompression{yes|no}
@@ -64,7 +64,7 @@ config set rdbcompression{yes|no}
## 三、AOF 机制
-AOF 是 Redis 提供的另外一种持久化的方式，它以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令，从而达到恢复数据的命令。
+AOF 是 Redis 提供的另外一种持久化的方式，它以独立日志的方式记录每次写入操作，重启时再重新执行这些操作，从而达到恢复数据的命令。
### 3.1 执行原理
@@ -82,7 +82,7 @@ Redis 提供了三种同步策略，用于控制 AOF 缓冲区同步数据到磁
write 和 fsync 操作说明：
-- write 操作会触发延迟写机制，Linux 在内核提供页缓冲区用来提高硬盘的 IO 性能，write 操作在写入系统缓冲区后直接返回。同步操作依赖于系统调度机制， 例如：缓冲区页空间写满或达到特定时间周期。 同步文件之前， 如果此时系统故障宕机， 缓冲区内数据将丢失。
+- write 操作会触发延迟写机制，Linux 在内核提供页缓冲区用来提高硬盘的 IO 性能，write 操作在写入系统缓冲区后直接返回。同步操作依赖于系统调度机制， 例如：缓冲区页空间写满或达到特定时间周期。 同步文件之前， 如果此时系统故障宕机，缓冲区内数据将丢失。
- fsync 针对单个文件操作，做强制硬盘同步，fsync 将阻塞直到写入硬盘完成后返回，保证了数据持久化。
Redis 默认的同步机制为`everysec`，此时能够兼顾性能和保证数据安全，在发生意外宕机的时，最多会丢失一秒的数据。
@@ -103,7 +103,7 @@ Redis 默认的同步机制为`everysec`，此时能够兼顾性能和保证数
#### RDB 的缺点
-- RDB 方式没办法做到数据的实时持久化，假设每次持久化的时间间隔是5分钟，当在上一次持久化后3分钟后发生了服务宕机，则这三分钟内的数据会全部丢失。
+- RDB 方式没办法做到数据的实时持久化，假设每次持久化的时间间隔是 5 分钟，当在上一次持久化后 3 分钟后发生了服务宕机，则这三分钟内的数据会全部丢失。
- fork 操作是一个重量级的操作，如果数据集很大，Fork 操作可能会非常耗时。
#### AOF 的优点
diff --git a/notes/Redis_数据类型和常用命令.md b/notes/Redis_数据类型和常用命令.md
index bfefdc5..883f29e 100644
--- a/notes/Redis_数据类型和常用命令.md
+++ b/notes/Redis_数据类型和常用命令.md
@@ -4,14 +4,14 @@
Redis 5 支持以下多种数据类型：
-- 二进制安全字符串。
-- Lists (列表)：根据插入顺序排序的字符串元素的集合。
-- Sets (集)：未排序的不重复的字符串元素的集合。
-- Sorted Sets (排序集)：类似于集，但每个字符串元素与被称为分数的值相关，元素总是按其分数排序。
-- Hashes (散列) ：由字段 (Field) 和值都是字符串组成的映射的集合。
-- Bit Arrays (也称 bitmaps 位图) ：Bitmaps 本身不是一种数据结构， 实际上它就是字符串，但是它可以对字符串的位进行操作，所以在 Redis 官方的分类当中将其单独归为一类；
-- HyperLogLogs：实际类型为字符串类型 ，它是一种基数算法， 通过 HyperLogLog 可以利用极小的内存空间完成独立总数的统计。
-- Streams (流) ：Stream是 Redis 5.0 引入的一种新数据类型，用于在生产者和消费者之间建立数据通道。
+- 二进制安全的字符串。
+- **Lists (列表)**：根据插入顺序排序的字符串元素的集合。
+- **Sets (集)**：未排序的不重复的字符串元素的集合。
+- **Sorted Sets (排序集)**：类似于集，但每个字符串元素与被称为分数的值相关，元素总是按其分数排序。
+- **Hashes (散列)** ：由字段 (Field) 和值都是字符串组成的映射的集合。
+- **Bit Arrays (也称 bitmaps 位图)** ：Bitmaps 本身不是一种数据结构， 实际上它就是字符串，但是它可以对字符串的位进行操作，所以在 Redis 官方的分类当中将其单独归为一类；
+- **HyperLogLogs**：实际类型为字符串类型 ，它是一种基数算法， 通过 HyperLogLog 可以利用极小的内存空间完成独立总数的统计。
+- **Streams (流)** ：Stream是 Redis 5.0 引入的一种新数据类型，用于在生产者和消费者之间建立数据通道。
## 二、常用命令
@@ -104,11 +104,11 @@ Redis 5 支持以下多种数据类型：
| 交集 | zinterstore destination numkeys key \[key ...] [weights weight [weight ...]] \[aggregate sum\|min\|max] |
| 并集 | zunionstore destination numkeys key \[key ...] [weights weight [weight ...]] \[aggregate sum\|min\|max] |
-- destination： 交集计算的结果保存到这个键。
-- numkeys： 需要做交集计算键的个数。
-- key[key...]： 需要做交集计算的键。
-- weights weight[weight...]： 每个键的权重， 在做交集计算时， 每个键中的每个 member 会将自己分数乘以这个权重， 每个键的权重默认是1。
-- aggregate sum|min|max： 计算成员交集后， 分值可以按照sum（和） 、min（最小值） 、 max（最大值） 做汇总， 默认值是 sum。
+- **destination**： 交集计算的结果保存到这个键。
+- **numkeys**： 需要做交集计算键的个数。
+- **key[key...]**： 需要做交集计算的键。
+- **weights weight[weight...]**： 每个键的权重， 在做交集计算时， 每个键中的每个 member 会将自己分数乘以这个权重， 每个键的权重默认是1。
+- **aggregate sum|min|max**： 计算成员交集后， 分值可以按照sum（和） 、min（最小值） 、 max（最大值） 做汇总， 默认值是 sum。
### 2.7 全局命令
@@ -126,10 +126,10 @@ Redis 5 支持以下多种数据类型：
可以使用以下命令完成设置键的过期时间：
-- expire key seconds： 键在 seconds 秒后过期；
-- expireat key timestamp： 键在秒级时间戳 timestamp 后过期；
-- pexpire key milliseconds： 键在 milliseconds 毫秒后过期；
-- pexpireat key milliseconds-timestamp：键在毫秒级时间戳 timestamp 后过期。
+- **expire key seconds**： 键在 seconds 秒后过期；
+- **expireat key timestamp**： 键在秒级时间戳 timestamp 后过期；
+- **pexpire key milliseconds**： 键在 milliseconds 毫秒后过期；
+- **pexpireat key milliseconds-timestamp**：键在毫秒级时间戳 timestamp 后过期。
注意事项：
@@ -148,9 +148,9 @@ Redis 5 支持以下多种数据类型：
scan cursor [match pattern] [count number]
```
-- cursor：游标，第一次遍历从 0 开始， 每次遍历完都会返回当前游标的值， 直到游标值为 0， 表示遍历结束。
-- match patternr：可选参数， 它的作用的是匹配特定模式的键；
-- count numberr：可选参数， 它的作用是表明每次要遍历的键个数， 默认值是 10。
+- **cursor**：游标，第一次遍历从 0 开始， 每次遍历完都会返回当前游标的值， 直到游标值为 0， 表示遍历结束。
+- **match pattern**：可选参数， 它的作用的是匹配特定模式的键；
+- **count number**：可选参数， 它的作用是表明每次要遍历的键个数， 默认值是 10。
### 2.10 数据库管理
diff --git a/notes/Redis_集群模式.md b/notes/Redis_集群模式.md
index c10a587..263793b 100644
--- a/notes/Redis_集群模式.md
+++ b/notes/Redis_集群模式.md
@@ -32,13 +32,11 @@ HASH_SLOT = CRC16(key) mod 16384
假设现在有一个 6 个节点的集群，分别有 3 个 Master 点和 3 个 Slave 节点，槽会尽量均匀的分布在所有 Master 节点上。数据经过散列后存储在指定的 Master 节点上，之后 Slave 节点会进行对应的复制操作。这里再次说明一下槽只是一个虚拟的概念，并不是数据存放的实际载体。
-
### 1.2 节点通讯
在 Redis 分布式架构中，每个节点都存储有整个集群所有节点的元数据信息，这是通过 P2P 的 Gossip 协议来实现的。集群中的每个节点都会单独开辟一个 TCP 通道，用于节点之间彼此通信，通信端口号在基础端口上加 10000；每个节点定期通过特定的规则选择部分节点发送 ping 消息，接收到 ping 信息的节点用 pong 消息作为响应，通过一段时间的彼此通信，最终所有节点都会达到一致的状态，每个节点都会知道整个集群全部节点的状态信息，从而到达集群状态同步的目的。
-
### 1.3 请求路由
#### 1. 请求重定向
@@ -126,7 +124,6 @@ cluster-config-file nodes-6480.conf
启动所有 Redis 节点，启动后使用 `ps -ef | grep redis` 查看进程，输出应如下：
-
接着需要使用以下命令创建集群，集群节点之间会开始进行通讯，并完成槽的分配：
```shell
@@ -137,10 +134,9 @@ redis-cli --cluster create 127.0.0.1:6479 127.0.0.1:6480 127.0.0.1:6481 \
执行后输出如下：M 开头的表示持有槽的主节点，S 开头的表示从节点，每个节点都有一个唯一的 ID。最后一句输出表示所有的槽都已经分配到主节点上，此时代表集群搭建成功。
-
### 2.3 集群完整性校验
-集群完整性指所有的槽都分配到存活的主节点上， 只要16384个槽中有一个没有分配给节点则表示集群不完整。 可以使用以下命令进行检测， check 命令只需要给出集群中任意一个节点的地址就可以完成整个集群的检查工作。
+集群完整性指所有的槽都分配到存活的主节点上， 只要16384个槽中有一个没有分配给节点则表示集群不完整。 可以使用以下命令进行检测， check 命令只需要给出集群中任意一个节点的地址就可以完成整个集群的检查工作：
```shell
redis-cli --cluster check 127.0.0.1:6479
@@ -160,21 +156,20 @@ Redis 集群提供了灵活的节点扩容和缩容方案，可以在不影响
### 3.1 集群扩容
-这里准备两个新的节点 6485 和 6486，配置和其他节点一致，配置完成后进行启动。集群扩容的命令为 `add-node`，第一个参数为需要加入的新节点，第二个参数为集群中任意节点，用于发现集群。
+这里准备两个新的节点 6485 和 6486，配置和其他节点一致，配置完成后进行启动。集群扩容的命令为 `add-node`，第一个参数为需要加入的新节点，第二个参数为集群中任意节点，用于发现集群：
```shell
redis-cli --cluster add-node 127.0.0.1:6485 127.0.0.1:6479
```
-成功加入集群后，可以使用 `cluster nodes` 命令查看集群情况。不做任何特殊指定，默认加入集群的节点都是主节点，但是集群并不会为分配任何槽。如下图所示，其他 master 节点后面都有对应的槽的位置信息，但新加入的 6485 节点则没有，由于没有负责的槽，所以该节点此时不能进行任何读写操作。
+成功加入集群后，可以使用 `cluster nodes` 命令查看集群情况。不做任何特殊指定，默认加入集群的节点都是主节点，但是集群并不会为分配任何槽。如下图所示，其他 master 节点后面都有对应的槽的位置信息，但新加入的 6485 节点则没有，由于没有负责的槽，所以该节点此时不能进行任何读写操作：
```shell
redis-cli -h 127.0.0.1 -p 6479 cluster nodes
```
-
-想要让新加入的节点能够进行读写操作，可以使用 `reshard` 命令为其分配槽，这里我们将其他三个主节点上的槽迁移一部分到 6485 节点上，这里一共迁移 4096 个槽，即 16384 除以 4 。 `cluster-from ` 用于指明槽的源节点，可以为多个，`cluster-to` 为槽的目标节点，`cluster-slots` 为需要迁移的槽的总数。
+想要让新加入的节点能够进行读写操作，可以使用 `reshard` 命令为其分配槽，这里我们将其他三个主节点上的槽迁移一部分到 6485 节点上，这里一共迁移 4096 个槽，即 16384 除以 4 。 `cluster-from ` 用于指明槽的源节点，可以为多个，`cluster-to` 为槽的目标节点，`cluster-slots` 为需要迁移的槽的总数：
```shell
redis-cli --cluster reshard 127.0.0.1:6479 \
@@ -183,11 +178,10 @@ redis-cli --cluster reshard 127.0.0.1:6479 \
--cluster-slots 4096 --cluster-yes
```
-迁移后，再次使用 `cluster nodes` 命令可以查看到此时 6485 上已经有其他三个主节点上迁移过来的槽。
+迁移后，再次使用 `cluster nodes` 命令可以查看到此时 6485 上已经有其他三个主节点上迁移过来的槽：
-
-为保证高可用，可以为新加入的主节点添加从节点，命令如下。`add-node` 接收两个参数，第一个为需要添加的从节点，第二个参数为集群内任意节点，用于发现集群。`cluster-master-id` 参数用于指明作为哪个主节点的从节点，如果不加这个参数，则自动分配给从节点较少的主节点。
+为保证高可用，可以为新加入的主节点添加从节点，命令如下。`add-node` 接收两个参数，第一个为需要添加的从节点，第二个参数为集群内任意节点，用于发现集群。`cluster-master-id` 参数用于指明作为哪个主节点的从节点，如果不加这个参数，则自动分配给从节点较少的主节点：
```shell
redis-cli --cluster add-node 127.0.0.1:6486 127.0.0.1:6479 --cluster-slave \
@@ -196,7 +190,7 @@ redis-cli --cluster add-node 127.0.0.1:6486 127.0.0.1:6479 --cluster-slave \
### 3.2 集群缩容
-集群缩容的命令如下：第一个参数为集群内任意节点，用于发现集群；第二个参数为需要删除的节点。
+集群缩容的命令如下：第一个参数为集群内任意节点，用于发现集群；第二个参数为需要删除的节点：
```
redis-cli --cluster del-node 127.0.0.1:6479 ``
