奇葩不懂爱
| 导读 | redis的应用场景很多，不管是在数据存储还是分布式锁等方面，本篇文章主要对主从、哨兵、分片集群做一个简单的分析，不会讲的太深。 |
redis的应用场景很多，不管是在数据存储还是分布式锁等方面，本篇文章主要对主从、哨兵、分片集群做一个简单的分析，不会讲的太深。
主从模式的应用场景有点类似于数据库的主从集群，主从往往是为了读写分离、backup 等目的才使用的，所谓主从模式简单的说就是有多个节点，里面包含主节点和从节点，结构如下图：
全量同步：全量同步一般使用在从节点刚接入主节点时进行全量复制，当然你也可以根据你的需求进行主动的全量同步
增量同步：Redis增量复制是指从节点初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令，一般使用缓冲区、队列(先进先出)等方式辅助进行增量的同步。
哨兵模式是为了保证redis的高可用产生的架构，简单地说就是通过构建1个或多个哨兵对节点进行监控，如果master发生故障下线之后，哨兵之间会进行投票，在2.8之后使用的是Raft算法进行master选举，关于这个算法其实这个算法也应用于zookeeper和某些网络拓扑中，简单说就是在选举的过程可通信节点达成共识后那个投票选举master，而后进行故障转移操作。
前面也有看到哨兵之间会进行集群的检测和哨兵之间的互相监测，但是哨兵不用做什么配置，因为哨兵巧妙的利用了master的发布/订阅机制去自动发现其它也监控了统一master的sentinel节点，在监测master方面一般分为两种：
主观下线(Subjectively Down， 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线(Objectively Down， 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过命令互相交流之后， 得出的服务器下线判断。 一个 Sentinel 可以通过向另一个 Sentinel 发送命令来询问对方是否认为给定的服务器已下线。
在上面的部分不管redis主从，还是高可用的 sentinel 哨兵模式。我们所做的这些工作只是保证了数据备份以及高可用，目前为止我们的程序一直都是向1台redis写数据，其他的redis只是备份而已。在实际使用中一般分片集群使用较多，我为什么要特意强调是分片集群呢，其实上面所说的主从和哨兵都是集群但是他们都是备份式的集群，实际数据是由一台进行控制的，所谓分片其实是将不同的数据按照一定的分布规则分布在不同的机器上
