01.redis主从

1.1 主从原理

  • 1、和MySQL主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。
  • 2、为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构。
  • 3、Redis主从复制可以根据是否是全量分为全量同步和增量同步。
  • 注：redis主节点Master挂掉时，运维让从节点Slave接管（redis主从默认无法自动切换，需要运维手动切换）

1.2 主从复制优点

  • 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离；
  • 为了分载 Master 的读操作压力，Slave 服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成；

1.3 主从复制缺点

  • Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败
  • 需要等待机器重启或者手动切换前端的IP才能恢复（也就是要人工介入）；
  • 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性；

02.哨兵模式

1.2.1 sentinel作用

  • 1.当用Redis做主从方案时，假如master宕机，Redis本身无法自动进行主备切换

  • 2.而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

1.2.2 sentinel原理

  • 1.sentinel负责持续监控主节点的健康，当主节挂掉时，自动选择一个最优的从节点切换成主节点

  • 2.从节点来连接集群时会首先连接sentinel，通过sentinel来查询主节点的地址

  • 3.当主节点发生故障时，sentinel会将最新的主节点地址告诉客户端，可以实现无需重启自动切换redis

1.2.3 Sentinel支持集群

  • 1.只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后sentinel本身也有单点问题

  • 2.如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

1.2.4 Sentinel版本

  • 1.Sentinel当前稳定版本称为Sentinel 2，Redis2.8和Redis3.0附带稳定的哨兵版本

  • 2.安装完redis-3.2.8后，redis-3.2.8/src/redis-sentinel启动程序 redis-3.2.8/sentinel.conf是配置文件。

1.3.5 哨兵模式的优缺点

  • 优点：

    • 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
    • 主从可以自动切换，系统更健壮，可用性更高(可以看作自动版的主从复制)。

  • 缺点：

    • Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

03.codis集群

1.3.1 为什么会出现codis

  • 1.在大数据高并发场景下，单个redis实例往往会无法应对

  • 2.首先redis内存不易过大，内存太大会导致rdb文件过大，导致主从同步时间过长

  • 3.其次在CPU利用率中上，单个redis实例只能利用单核，数据量太大，压力就会特别大

1.3.2 什么是codis

  • 1.codis是redis集群解决方案之一，codis是GO语言开发的代理中间件
  • 2.当客户端向codis发送指令时，codis负责将指令转发给后面的redis实例来执行，并将返回结果转发给客户端
  • 3.Codis是由国人前豌豆荚大神开发的，采用中心化方式的集群方案。
  • 4.因为需要代理层Proxy来进行所有请求的转发，所以对Proxy的性能要求很高

1.3.3 codis部署方案

  • 1.单个codis代理支撑的QPS比较有限，通过启动多个codis代理可以显著增加整体QPS

  • 2.多codis还能起到容灾功能，挂掉一个codis代理还有很多codis代理可以继续服务

1.3.4 codis分片的原理

  • 1.codis负责将特定key转发到特定redis实例，codis默认将所有key划分为1024个槽位

  • 2.首先会对客户端传来的key进行crc32计算hash值，然后将hash后的整数值对1024进行取模，这个余数就是对应的key槽位

  • 3.每个槽位都会唯一映射到后面的多个redis实例之一，codis会在内存中维护槽位和redis实例的映射关系

  • 4.这样有了上面key对应的槽位，那么它应该转发到那个redis实例就很明确了

  • 5.槽位数量默认是1024，如果集群中节点较多，建议将这个数值大一些，比如2048,4096

1.3.5 不同codis槽位如何同步

  • 1.如果codis槽位值存在内存中，那么不同的codis实例间的槽位关系得不到同步

  • 2.所以codis还需要一个分布式配置存储的数据库专门来持久化槽位关系

  • 3.codis将槽位关系存储在zookeeper中，并且提供一个dashboard可以来观察和修改槽位关系

04.Cluster集群模式

4.1 什么是redis集群

  • Redis Cluster是一种服务器 Sharding 技术，3.0版本开始正式提供。
  • Redis 的哨兵模式基本已经可以实现高可用，读写分离
  • 但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存
  • 所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储
  • 也就是说每台 Redis 节点上存储不同的内容。

4.2 cordis集群模式弊端

  • codis采用中间加一层Proxy的中心化模式时，这就对Proxy的要求很高

  • 因为它一旦出现故障，那么操作这个Proxy的所有客户端都无法处理

  • 要想实现Proxy的高可用，还需要另外的机制来实现，例如Keepalive。

  • 而且增加一层Proxy进行转发，必然会有一定的性能损耗

  • 那么除了客户端分片和上面提到的中心化的方案之外，还有比较好的解决方案么？

4.3 Cluster集群模式

  • Redis官方推出的Redis Cluster另辟蹊径，它没有采用中心化模式的Proxy方案

  • 而是把请求转发逻辑一部分放在客户端，一部分放在了服务端，它们之间互相配合完成请求的处理。

  • Redis Cluster采用16384个槽位进行路由规则的转发。

  • 在这个图中，每一个蓝色的圈都代表着一个 redis 的服务器节点。

  • 它们任何两个节点之间都是相互连通的。

  • 客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点，对其进行存取和其他操作。

  • Redis 集群有16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽。

  • 集群的每个节点负责一部分hash槽，举个例子，比如当前集群有3个节点，那么：

    • 节点 A 包含 0 到 5460 号哈希槽
    • 节点 B 包含 5461 到 10922 号哈希槽
    • 节点 C 包含 10923 到 16383 号哈希槽

__END__