redis主从 | 哨兵 | 集群

    首先,redis作为一个高性能的key-value数据库,它有以下三个特点:

1, redis支持持久化, 即内存中数据可以持久化到磁盘,断电开机后可重新加载

2, 支持key-value类型的数据, 同时提供list, set, zset,hash等数据结构的存储

3, 支持数据备份,也就是master-slave模式的数据备份

 

主从

    在redis中, 为了保证数据库的高可用和提升读写性能,架构采用主从模式复制来进行数据的读写分离.常见的一主多从,主库用于数据写操作,从库完成读任务. 因为在互联网业务中,往往都是读多写少的. 而主从库之间肯定也会基于某种机制来保证数据同步.

    从数据库一般是只读的,它接受来自主数据库的同步数据.

 

哨兵

    如果主数据库出现故障,开发者可以手动选择将一个从数据库升级为主数据库,以保证数据服务的正常运行,但是这种人工介入的方式比较麻烦而且难以及时, 而哨兵的作用就是将这过程实现自动化,即实现系统监控和故障恢复.

    哨兵监控的是主数据库,它通过主数据库可以找到其他从数据库.

 

集群

    当redis以集群形式工作时,一致性哈希算法是一种比较好的方案.

    理由很简单,hash算法是一种很高效的算法,如果采用普通的hash算法(常量取模)会出现数据迁移困难. 比如说集群中有8个redis服务器,则数据存放时(假设通过id信息)对8取模确定存放在哪台服务器上,数据查找时也用同样的方式, 如果此时要新增一个服务器节点时,则原来的规则需要被打破,所有数据的存放位置需要调整,这样一来会有很大的开销. 为了避免这种服务器数量变量带来的数据迁移代价, 我们采用一致性哈希算法来尽可能减少开销

    一致性哈希算法可以有效解决分布式存储结构下动态增加和删除节点带来的问题

    首先，我们把全量的缓存空间当做一个环形存储结构。环形空间总共分成2^32个缓存区，在Redis中则是把缓存key分配到16384个slot。

 

    每一个缓存key都可以通过Hash算法转化为一个32位的二进制数，也就对应着环形空间的某一个缓存区。我们把所有的缓存key映射到环形空间的不同位置。

.    我们的每一个缓存节点（Shard）也遵循同样的Hash算法，比如利用IP做Hash，映射到环形空间当中。

    如何让key和节点对应起来呢？很简单，每一个key的顺时针方向最近节点，就是key所归属的存储节点。所以图中key1存储于node1，key2，key3存储于node2，key4存储于node3。

    当缓存集群的节点有所增加的时候，整个环形空间的映射仍然会保持一致性哈希的顺时针规则，所以有一小部分key的归属会受到影响。

    有哪些key会受到影响呢？图中加入了新节点node4，处于node1和node2之间，按照顺时针规则，从node1到node4之间的缓存不再归属于node2，而是归属于新节点node4。因此受影响的key只有key2。

    最终把key2的缓存数据从node2迁移到node4，就形成了新的符合一致性哈希规则的缓存结构。

 

    当缓存集群的节点需要删除的时候（比如节点挂掉），整个环形空间的映射同样会保持一致性哈希的顺时针规则，同样有一小部分key的归属会受到影响。

     有哪些key会受到影响呢？图中删除了原节点node3，按照顺时针规则，原本node3所拥有的缓存数据就需要“托付”给node3的顺时针后继节点node1。因此受影响的key只有key4。

    最终把key4的缓存数据从node3迁移到node1，就形成了新的符合一致性哈希规则的缓存结构。

 

    当服务器节点很少的时候, 可能会出现数据分布不均衡情况,比如所有数据都被映射到了node1上, 为了避免节点少带来的不均衡问题, 引入了虚拟节点概念

    虚拟节点其实就是基于实际物理节点映射出N个子节点, 然后把子节点映射到环形空间上.

    比如 服务器节点node1的IP是192.168.1.11, 那么node1节点在环形空间的位置为hash('192.168.1.11'), 此时基于node1映射两个虚拟节点node1-1和node1-2 , 那么node1-1虚拟节点在环形空间的位置可以利用hash('192.168.1.11#1')计算

    映射虚拟节点后环形空间上则没有原物理节点node1, 这样通过增加节点数量来维持数据的相对均衡.