文章目录
- 哨兵模式
- 官方Redis Cluster
- Jedis（客户端分片）
- Codis（代理分片）
哨兵模式
- 优点
哨兵模式是基于主从模式的，解决可主从模式中master故障不可以自动切换故障的问题。 - 缺点
（1）是一种中心化的集群实现方案：始终只有一个Redis主机来接收和处理写请求，写操作受单机瓶颈影响。
（2）集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
（3）Redis主机宕机后，哨兵模式正在投票选举的情况之外，因为投票选举结束之前，谁也不知道主机和从机是谁，此时Redis也会开启保护机制，禁止写操作，直到选举出了新的Redis主机。
官方Redis Cluster
- 采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的
- 采用虚拟哈希槽分区而非一致性hash算法，预先分配一些卡槽，所有的键根据哈希函数映射到这些槽内，每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据
- 客户端发送请求任一master，slot未命中，server返回slot所在节点。client再次访问
Jedis（客户端分片）
- 客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis）
- 通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集
Codis（代理分片）
- Codis引入了Redis Server Group，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。当一个主CodisRedis挂掉时，Codis不会自动把一个从CodisRedis提升为主CodisRedis，这涉及数据的一致性问题（Redis本身的数据同步是采用主从异步复制，当数据在主CodisRedis写入成功时，从CodisRedis是否已读入这个数据是没法保证的），需要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。
- Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有固定的编号，范围是1 ~ 1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。
