redis的场景应用多角度简单分析

redis的应用场景不少，无论是在数据存储仍是分布式锁等方面，本篇文章主要对主从、哨兵、分片集群作一个简单的分析，不会讲的太深。

redis的应用场景不少，无论是在数据存储仍是分布式锁等方面，本篇文章主要对主从、哨兵、分片集群作一个简单的分析，不会讲的太深。

主从模式

主从模式的应用场景有点相似于数据库的主从集群，主从每每是为了读写分离、backup 等目的才使用的，所谓主从模式简单的说就是有多个节点，里面包含主节点和从节点，结构以下图：

 

从节点在保持链接后每隔一个时间节点会主动的和主节点通讯并发送同步请求，然后进行同步。

 

 

其实在整个流程中，最须要主要的就是数据间的同步，主要的同步方式有两种也就是全量同步和增量同步。

 

全量同步：全量同步通常使用在从节点刚接入主节点时进行全量复制，固然你也能够根据你的需求进行主动的全量同步

增量同步：Redis增量复制是指从节点初始化后开始正常工做时主服务器发生的写操做同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令，通常使用缓冲区、队列(先进先出)等方式辅助进行增量的同步。

哨兵模式

哨兵模式是为了保证redis的高可用产生的架构，简单地说就是经过构建1个或多个哨兵对节点进行监控，若是master发生故障下线以后，哨兵之间会进行投票，在2.8以后使用的是Raft算法进行master选举，关于这个算法其实这个算法也应用于zookeeper和某些网络拓扑中，简单说就是在选举的过程可通讯节点达成共识后那个投票选举master，然后进行故障转移操做。

 

哨兵是做为一个进程单独运行在redis中，哨兵之间也是经过该进程进行通讯的，这一点和zookeeper的原理也是相似的，假设一个6节点3个哨兵的集群的结构应该以下图：

 

 

那么哨兵是如何监控master下线的呢?

 

前面也有看到哨兵之间会进行集群的检测和哨兵之间的互相监测，可是哨兵不用作什么配置，由于哨兵巧妙的利用了master的发布/订阅机制去自动发现其它也监控了统一master的sentinel节点，在监测master方面通常分为两种：

主观下线(Subjectively Down， 简称 SDOWN)指的是单个 Sentinel 实例对服务器作出的下线判断。

客观下线(Objectively Down， 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器作出 SDOWN 判断， 而且经过命令互相交流以后， 得出的服务器下线判断。 一个 Sentinel 能够经过向另外一个 Sentinel 发送命令来询问对方是否定为给定的服务器已下线。

分片集群

在上面的部分无论redis主从，仍是高可用的 sentinel 哨兵模式。咱们所作的这些工做只是保证了数据备份以及高可用，目前为止咱们的程序一直都是向1台redis写数据，其余的redis只是备份而已。在实际使用中通常分片集群使用较多，我为何要特地强调是分片集群呢，其实上面所说的主从和哨兵都是集群可是他们都是备份式的集群，实际数据是由一台进行控制的，所谓分片实际上是将不一样的数据按照必定的分布规则分布在不一样的机器上

 

在redis中，咱们的应用在存取数据的时候须要根据必定的算法(一致性hash)进行计算和存取 ，那么在redis中如何实现数据分片的呢? 首先Redis至少存在三个数据分片，每一个分片称为master，假设整个cluster有N个节点，那么每一个节点都和其余N-1个节点保持链接和心跳，节点之间相互通讯主要确认节点是否存活、节点的数据版本、投票选择新的master等

 

 

那么咱们最终的集群结构大体以下：

 

 

 

本文地址：https://www.linuxprobe.com/application-scenarios-redis.html