m0_74139794的博客

​ 对于Master宕机后的冷处理方式是无法实现高可用的。Redis从2.6版本开始提供了高可用的解决方案–Sentinel哨兵机制。在集群中再引入一个节点，该节点充当Sentinel哨兵，用于监视Master的运行状态，并在Master宕机后自动指定一个Slave作为新的Master。整个过程无需人工操作，完全由哨兵自动完成。​ 不过，此时的 Sentinel 哨兵又成为了一个单点故障点：若哨兵发生宕机，整个集群将瘫 痪。

​ Redis2.8版本之前，首次通信成功后。slave会向master发送sync数据同步请求。然后master就会将其所有数据全部发送给slave，由slave保存到其本地持久化文件中。这个过程称为全量复制。​ 但在这里存在一个问题，在全量复制过程中会存在网络抖动而导致数据复制过程中断。当网络恢复后，slave与master重新建立连接，此时slave会重新发送sync请求，然后重新进行全量复制。​ 由于全量复制整个过程是非常消耗时间的，所以出现网络抖动的概率很高。

​ 在 slave 数据同步过程中，master 的主进程仍在不断地接受着客户端的写操作，且不仅将新的数据写入到了 master 内存，同时也写入到了同步缓存。当 master 的持久化文件中的数据发送完毕后，master 会再将同步缓存中新的数据发送给 slave，由 slave 将其写入到本地持久化文件中。如果验证成功，则向 slave 发送连接成功响应。​ 当 slave 与 master 的数据同步完成后，slave 就会读取本地的持久化文件，将其恢复到本地内存，然后就可以对外提供读服务了。

​ Redis的主从集群是一个”一主多从“的读写分离集群.集群中的Master节点负责客户端的读写请求，而Slave节点负责客户端读请求。之所以要将集群搭建为读写分离模式，主要是因为，对于数据库集群，写操作压力一般较小，读压力更大。所以只有一个节点负责处理写请求操作即可。

RDB文件小数据恢复快。

Redis的key允许有多个单词形成层级结构，多个单词之间用’:'隔开。product相关的key：project:product:1。user相关的key：project:user:1。

Redis是一个key-value的数据库，多样：（未列全）

AOF，Append Only File，是指Redis将每一次写操作都以日志的形式记录到一个AOF文件中的持久化技术。当需要恢复内存数据时，将这些写操作重新执行一次，便会恢复到之前的内存数据状态。

RDB是redis默认的持久化策略，在RDB模式下，可以将redis在内存中的数据库状态保存到磁盘里面（以内存快照的形式），避免数据意外丢失。RDB持久化功能既可以手动执行，也可以通过配置文件定期执行。RDB通过生成一个经过压缩的二进制文件，保存数据库状态，可以通过该文件进行还原。

​ Redis分布式系统，官方称为Redis Cluster, Redis集群（这个集群和前面的主从复制集群不同，这个集群可以理解为是多个主从复制集群所组成的集群），其实是Redis3.0开始推出得分布式解决方案。（下面讲到的节点本质都是在Redis分布式系统中的一个主从复制集群）

Redis集群-哨兵模式

Redis注册复用-读写分离的搭建

Python操作Redis事务

python连接Redis的两种连接方式

Windows下连接Redis

非常详细的Redis安装