笔记-redis深入学习-1

笔记-redis深入学习-1

redis的基本使用已经会了，但存储和读取只是数据库系统最基础的功能；

数据库系统还得为可靠实现这两者提供一系列保证；

1. 数据、操作备份和恢复，主要是持久化；
2. 高可用：主要是主从和集群；

1.      持久化

redis是内存数据库，想将数据保存到磁盘上，需要配置持久化。

redis持久化有两种模式RDB和AOF。

1.1.    RDB

RDB:全称redis database，在指定的时间点将内存中的数据集快照，在恢复时直接将快照文件读到内存里。

redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，主进程不进行IO。

1.1.1.   优劣

1. 优点：

快；

基本不影响主进程；

1. 缺点：

前面说过，快照+时间点，那么当下一定会有一段时间内的改变是没有记录的；行话说就是数据恢复的完整性不能保证；

另外一点就是fork的问题了，当数据集比较大时，fork的过程是非常耗时的，能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

也得考虑内存使用的问题，在fork时，数据被克隆了一份，可能会超出内存容量限制。

1.1.2.   更多实现细节

fork一个与主进程一样的进程来完成持久化；

持久化数据保存在dump.rdb文件中；

具体过程：

1. redis forks. we now have a child and a parent process.
2. the child starts to write the dataset to a temporary RDB file.
3. when the cild is done writing the new RDB file, it replaces the ols one.

1.1.3.   配置或命令操作

1. 配置

在config文件中配置

save 900 1

save 300 10

save 60 10000

#   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

可以多个策略同时生效

1. 命令

save：会阻塞请求；

bgsave：后台save，不会阻塞当前请求；

1.2.    AOF

AOF:append only file，AOF记录每一次服务器收到的操作请求，在重启时会重演所有操作请求。

可以同时指定RDB和AOF，但当重启时会使用AOF恢复数据。

1.2.1.   优劣

1. 优点：

更durable/?，简单来说就是备份策略更灵活，性能也有保障（fsync是用一个后台线程执行的），默认每秒进行写入也能保持高性能；

AOF日志文件是添加模式的，所以没有偏移和同步问题，如果突然断电，这个特性非常有用；另外如果日志末尾只有半截命令，也很容易处理；

当日志文件太大时，redis会自动使用一个等效的优化后的AOF文件替换它；

AOF日志文件可读性比较高；

1. 缺点

AOF文件通常比等效的RDB文件大；

AOF可能比RDB慢（取决于具体设置）；

1.2.2.   配置或命令操作

在配置文件中设置打开aof

appendonly yes

日志重写：日志重写的原理很简单，对一个key操作100次，当然日志会记录100次操作，但对于重建来说，前面的99次都是没有意义的，可以删除。

策略选择：

1. # appendfsync always 每条命令都记录一次，慢，安全；
2. appendfsync everysec每秒进行记录；
3. # appendfsync no 不写日志；

默认策略是每秒写

如果AOF文件被破坏了怎么办？

Make a backup copy of your AOF file.

Fix the original file using the redis-check-aof tool that ships with Redis:

$ redis-check-aof --fix

Optionally use diff -u to check what is the difference between two files.

Restart the server with the fixed file.

AOF运作机制：

1. redis forks, so now we have a child and a parent process.
2. the child starts writing the new AOF in a temporary file.
3. the parent accumulates all the new changes in an in-memory buffer(but at the same time it writes the new changes in the old append-only-file, so it rewriting fails, we are save).
4. when the child is done rewriting the file, the parent gets a signal, and appends the in-memory buffer at the end of the file generated by the child.
5. profit! now redis automically renames the old file into the new one, and starts appending new data to the new file.

2.      主从

目前推荐及常用的主从模式是主写，从读；

特性如下：

1. Redis 使用异步复制，slave 和 master 之间异步地确认处理的数据量
2. 一个 master 可以拥有多个 slave
3. slave 可以接受其他 slave 的连接。除了多个 slave 可以连接到同一个 master 之外， slave 之间也可以像层叠状的结构（cascading-like structure）连接到其他 slave 。自 Redis 4.0 起，所有的 sub-slave 将会从 master 收到完全一样的复制流。
4. Redis 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时，可以继续处理查询请求。
5. 复制在 slave 侧大部分也是非阻塞的。当 slave 进行初次同步时，它可以使用旧数据集处理查询请求，假设你在 redis.conf 中配置了让 Redis 这样做的话。否则，你可以配置如果复制流断开， Redis slave 会返回一个 error 给客户端。但是，在初次同步之后，旧数据集必须被删除，同时加载新的数据集。 slave 在这个短暂的时间窗口内（如果数据集很大，会持续较长时间），会阻塞到来的连接请求。自 Redis 4.0 开始，可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行，但是，加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave 。
6. 复制既可以被用在可伸缩性，以便只读查询可以有多个 slave 进行（例如 O(N) 复杂度的慢操作可以被下放到 slave ），或者仅用于数据安全。
7. 可以使用复制来避免 master 将全部数据集写入磁盘造成的开销：一种典型的技术是配置你的 master Redis.conf 以避免对磁盘进行持久化，然后连接一个 slave ，其配置为不定期保存或是启用 AOF。但是，这个设置必须小心处理，因为重新启动的 master 程序将从一个空数据集开始：如果一个 slave 试图与它同步，那么这个 slave 也会被清空。

2.1.    主从配置

主从配置非常简单

在从库进行配置

slaveof <masterip> <masterport> # 主库地址，端口

masterauth <password> # 如果主库有密码

bind 0.0.0.0

port 6379 # 端口得改了

logfile "6379.log" # 日志也得改

dbfilename "dump-6379.rdb" # 持久化文件

daemonize yes

rdbcompression yes

同时启动三个服务，可以看到3个进程；

分别连接三个服务：

redis-cli –p 6379

redis-cli –p 6381

redis-cli –p 6382

在从库可以发现与主库的数据一致；

2.2.    主从同步原理

同步的开始：从服务器在连接时它发送了一个SYNC命令，不管它是第一次连接还是再次连接都没有关系。

接下来可能进行全量同步或部分同步。

全量同步：

从服务器向主服务器发送SYNC命令；

收到SYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令；

当主服务器的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。

主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。

部分同步：

每一个 Redis master 都有一个 replication ID ：这是一个较大的伪随机字符串，标记了一个给定的数据集。每个 master 也持有一个偏移量，master 将自己产生的复制流发送给 slave 时，发送多少个字节的数据，自身的偏移量就会增加多少，目的是当有新的操作修改自己的数据集时，它可以以此更新 slave 的状态。复制偏移量即使在没有一个 slave 连接到 master 时，也会自增，所以基本上每一对给定的

Replication ID, offset

都会标识一个 master 数据集的确切版本。

当 slave 连接到 master 时，它们使用 PSYNC 命令来发送它们记录的旧的 master replication ID 和它们至今为止处理的偏移量。通过这种方式， master 能够仅发送 slave 所需的增量部分。但是如果 master 的缓冲区中没有足够的命令积压缓冲记录，或者如果 slave 引用了不再知道的历史记录（replication ID），则会转而进行一个全量重同步：在这种情况下， slave 会得到一个完整的数据集副本，从头开始。

这部分不用深究，了解即可，简单来说会根据id和offset组成的标识来决定同步哪一部分，如果id或offset超限、找不到，则进行全量同步。

另外从同步发起方而言可以分为两种同步：

1. sync：由从服务器触发；
2. command propagate：由主服务器触发，当数据改变时触发，同步更新从库的数据；

心跳检测：

在命令传播阶段，从服务器默认每秒向主服务器发送命令：REPLCONF ACK <replication_offset>

其中replication_offset是从服务器当前的复制偏移量。

发送REPLCONF ACK命令对于主从服务器有三个作用：

1. 检测主从服务器的网络连接状态；
2. 辅助实现min-slaves选项；
3. 检测命令丢失。

2.3.    主从模式优缺点

1. 优点：高可用，读写分离
2. 缺点：延时

主库宕机后，从库仍可以读取；

有一个情况需要注意，在主库未持久化的情况下主库宕机，然后重新拉起服务，会导致从服务器丢失数据；原因是主库拉起后，因为没有持久化，所以没有数据，从库对此进行同步，会删除数据。

3.      哨兵sentinel

主从模式解决了数据备份和单例的性能问题，但新的问题是对具体的应用端而言，它一般只会访问一个从库，如果该从库宕机，应用仍无法访问数据库。

另外，如果主库下线，需要人工干预指定新的主库。

为了解决这两个问题，2.8版以后推出了哨兵sentinel。

哨兵的逻辑就是监控，如果发现主机不可连接，则根据规则在从库中选一个主库出来。

4.      cluster

哨兵解决了状态监控和主库选择的问题，但并未解决单主机性能极限问题。

集群主要用于解决单主机性能极限问题。

集群的关键有三点：

1. 数据分片：数据存储范围的划分
2. 数据读取：怎么知道数据在哪台服务器上，怎么去读它
3. 数据一致性：

数据分片：

Redis Cluster does not use consistent hashing, but a different form of sharding where every key is conceptually part of what we call an hash slot.

在redis 集群中有16384个hash slot，计算key属于哪个hash slot的方法是对key使用CRC16算法，然后对16384取余。

Every node in a Redis Cluster is responsible for a subset of the hash slots, so for example you may have a cluster with 3 nodes, where:

Node A contains hash slots from 0 to 5500.

Node B contains hash slots from 5501 to 11000.

Node C contains hash slots from 11001 to 16383.

数据读取：

To perform their tasks all the cluster nodes are connected using a TCP bus and a binary protocol, called the Redis Cluster Bus. Every node is connected to every other node in the cluster using the cluster bus. Nodes use a gossip protocol to propagate information about the cluster in order to discover new nodes, to send ping packets to make sure all the other nodes are working properly, and to send cluster messages needed to signal specific conditions. The cluster bus is also used in order to propagate Pub/Sub messages across the cluster and to orchestrate manual failovers when requested by users (manual failovers are failovers which are not initiated by the Redis Cluster failure detector, but by the system administrator directly).

节点不能代理请求，所以clients may be redirected to other nodes using redirection errors -MOVED and -ASK.

理论上可以访问集群中的任意一个节点并通过重定向定位到真正提供数据的节点，但是，明确访问数据真正存放的节点会提高效率。

数据一致性：

与主从类似，多份数据一定会面对的问题是一致性问题；这里与主从下的一致性问题是类似的。

redis集群没有提供强一致性。

其它特性或问题：

多键操作：

集群下，不同的key可能会分布于多个服务器中，如果同时操作这些key会带来问题。

Redis Cluster supports multiple key operations as long as all the keys involved into a single command execution (or whole transaction, or Lua script execution) all belong to the same hash slot. The user can force multiple keys to be part of the same hash slot by using a concept called hash tags.

如果一条命令/脚本中涉及到的key属于一个hash slot，则这条命令可以在cluster环境下执行。

当然有时需要指定key在同一主机内，为此redis支持强制多个key存在于一个hash slot内，这需要hash tags。

高可用：

为了保证可用性，redis集群使用了主从，为每一个节点配置了一个从节点。

例如：集群中包含节点ABC及它们的从节点abc，如果A挂了，会切换到a，但如果A和a都挂了，集群就挂了。

另外如果集群一半以上的主节点挂掉，无论是否有从节点，集群都不可用。