Redis Replication 实现原理
对于 Master/Slave 模式，在我们常用的Mysql中你一定有或多或少的了解，应该知道它的一些价值，比如灾备、读写分离。就灾备一项就足以使我们必须使用它，因为一旦服务器软硬件故障，可能造成数据永不可恢复。你可能会说，可以提前做好数据文件备份，但是要远比修改一个 IP 更加复杂与时间开销更大。在Master/Slave 模式下还可以结合LVS/Keepalived 实现故障自动转移，使其具体业务方无感知。
在 Redis 2.8 版本之前，Master/Slave 之前只支持全量同步（full resync），从 2.8版本开始支持了部分重同步（partial resynchronization），使得在短暂的网络中断恢复后，不需要进行全量数据同步，而是只同步最近新增的数据即可。那么如何理解这个“短暂”，其实是取决于配置参数与实际场景，下面将带大家一起抽丝剥茧，找出真相。
Redis Cluster 实现原理
1. 简介
Redis Cluster 是 Redis 官方提供的集群模式。在Redis 3.0 版本开始支持，是在原有的 Redis 版本中增加了集群相关的实现，是同一个项目。Redis Cluster 方式各个节点其实是一样的，都是Redis节点，本身支持执行Redis的所有命令，也是数据的存储节点，只是额外支持一些 Cluster 命令。但是 Redis Sentinel 模式中，Sentinel 则是一个全新的角色，并不是数据的存储节点，不允许执行常规的 set / get / inc 等操作，主要运用于故障检测、故障发现、故障转移这些场景。
在之前的一篇文章中记录了关于 Redis Cluster 的学习笔记，其中是按照程序执行顺序编排的，也包括了一些细节方面的说明，对于研究 Redis 源码的同学可能有帮助，基本每一小节内容对应源码中的一小段程序。而这篇文章将是以一个使用者的角度去理解 Redis Cluster，所以更加宏观一些，某些细节可能就不会提到。关于细节可以参考：Redis Cluster 学习笔记
Redis Sentinel 高可用原理
现在 B/S C/S 架构的软件系统设计时，我们通常需要把服务端设计为高可用系统，比如 3个9（99.9%），4个9（99.99%），5个9（99.999%）。这是由于随着用户请求量的增加，服务端系统需要处理的事务会增加，进而可能会导致服务端系统无法快速、正确响应用户请求，使得用户体验变得非常糟糕。最终可能会使得用户流失，对广告、会员等这部分收入产生严重影响。另外，Redis作为基础组件，一旦出现故障，可能会使得好多业务出现异常。因此高可用是非常有必要的，也是一个软件开发者应该具备的基本能力之一。
Redis RDB 文件存储实现
redis通过把内存数据保存为rdb文件来实现快照，是整个redis内核中不可缺少的一部分，为实现服务高可用提供了强有力的支撑。有以下2点作用：1. 持久化 （比 aof 恢复速度更快，也占用更小的磁盘空间，因此作为默认的持久化方式）
2. 主从同步 （开启主从后，需要首先把master上的历史数据同步到slave，这时slave就会拉取master的rdb文件，然后解析加载rdb文件到内存）
