Redis技术点小结

一、主从模式
为了保证在部分节点故障或网络不通时集群依然能正常工作，集群使用了主从模型。
例如节点01(主)[04(从) ] / 02(主)[05(从) ] / 03(主)[06(从) ]，
04 节点是 01 节点的从节点，如果 01 节点故障，集群会将 04 从节点升级为主节点（哨兵），从而让集群继续正常工作。
但是，如果 01 和 04 同时挂掉，那么这个 Redis 集群就不能继续正常运作了。

Redis 集群不能保证一致性。比如一个已经向客户端确认写成功的操作，可能会在某些不确定因素的条件下导致操作数据丢失,我们从Redis写数据的流程来看原因：
1）客户端向主节点 01 发起写的操作
2)主节点 01 响应客户端写操作成功
3)主节点 01 向它的从节点 04 同步该写的动作。
从上面写的流程来看，主节点 01 并没有等从节点 04 写完之后再回复客户端的写操作结果。而是先响应客户端后再将写的动作同步到从节点 04，所以，如果主节点 01 在通知客户端写操作成功之后，但同步给从节点 04 之前，主节点 01 挂了，未将写操作结果同步到从节点，那么当 04 从节点提为主节点时，该写操作就会永远丢失。

二、集群分片：
Redis 集群不是使用一致性哈希，而是使用哈希槽。整个 redis 集群有 16384 个哈希槽。
例如上例中集群有 3 个节点，则：
1）、节点 01 存储的哈希槽范围是：0 ~ 5460
2）、节点 02 存储的哈希槽范围是：5461 ~10922
3）、节点 03 存储的哈希槽范围是：10923~16383

这样的分布方式方便节点的添加和删除。
比如，需要新增一个节点 07，只需要把 01、02、03 中的部分哈希槽数据移到 07 节点。
同样，如果希望在集群中删除01节点，只需要把 01 节点的哈希槽的数据移到 02 和 03 节点，当 01 节点的数据全部被移走后，01 节点就可以完全从集群中删除。
因为把哈希槽从一个节点移到另一个节点是不需要停机的，所以，增加或删除节点，或更改节点上的哈希槽，都是不需要停机的。

如果多个key都属于一个哈希槽，集群支持通过一个命令、事务或lua脚本同时操作这些key。通过“哈希标签”的概念，用户可以让多个key分配到同一个哈希槽。

三、数据备份与恢复
目前Redis持久化的方式有两种： RDB 和 AOF.。
RDB就是Snapshot快照存储，是默认的持久化方式，即按照一定的策略周期性的将数据保存到磁盘。
下面是默认的快照设置：

save 900 1 #当有一条Keys数据被改变时，900秒刷新到Disk一次
save 300 10 #当有10条Keys数据被改变时，300秒刷新到Disk一次
save 60 10000 #当有10000条Keys数据被改变时，60秒刷新到Disk一次。
第一次Slave向Master同步的实现是：
Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。
第二次以及以后的同步实现是：
Master将变量的快照直接实时依次发送给各个Slave。
但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。

AOF(Append-Only File)比RDB方式有更好的持久化性。
由于在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中
appendonly yes #启用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。

到底选择什么呢？下面是来自官方的建议：
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
在我们目前的线上环境中，由于数据都设置有过期时间，采用AOF的方式会不太实用，过于频繁的写操作会使AOF文件增长到异常的庞大，大大超过了我们实际的数据量，这也会导致在进行数据恢复时耗用大量的时间。
因此，可以在Slave上仅开启Snapshot来进行本地化，同时可以考虑将save中的频率调高一些或者调用一个计划任务来进行定期bgsave的快照存储，来尽可能的保障本地化数据的完整性。
在这样的架构下，如果仅仅是Master挂掉，Slave完整，数据恢复可达到100%。

其他：
快照存储命令：
SAVE 保存是阻塞主进程，客户端无法连接redis，等SAVE完成后，主进程才开始工作，客户端可以连接
BGSAVE 是fork一个save的子进程，在执行save过程中，不影响主进程，客户端可以正常链接redis，等子进程fork执行save完成后，通知主进程，子进程关闭。很明显BGSAVE方式比较适合线上的维护操作，两种方式的使用一定要了解清楚在谨慎选择。

参考文章地址：
https://blog.csdn.net/Hello_World_QWP/article/details/78257428?locationNum=6&fps=1
https://www.cnblogs.com/whoisaline/p/6403270.html