【随笔记】Redis（二）架构模式面试知识点

由简入繁，水滴石穿。

Redis 的架构模式

单机版

直接说，就是只有一个redis，坏了就没得用那种。

• 特点：简单，很简单。
• 缺点：
  • 存储容量有限制，取决于所在服务器的能力
  • 处理能力有限，也取决于所在服务器的能力
  • 高可用性无，没有高可用，坏了就没得用

主从复制

高端点的单机版，Redis的复制（replication）功能允许用户根据一个Redis服务器来创建多个任意的复制品，其中被复制的服务器就是主服务器（master），而通过复制出来的服务器就是从服务器（slave）。只要主从服务器之间的网络连接正常，主从服务器之间就具有相同的数据，主服务器会一直将自身数据同步给从服务器，保证主从服务器上面的数据相同。

• 特点：
  • master、slave两个角色
  • master、slave数据是相同的
  • 可以降低master读数据压力，可以将读操作交给slave
• 缺陷：
  • 没有高可用，master宕机后还是没得用
  • slave为master减轻读压力，但是master还是存在写压力

哨兵模式

高端模式，解决了高可用、自动进行故障转移。

• 监控（monitoring）：Sentinel会不断检查主服务器和从服务器是否正常工作；
• 提醒（Notification）：当被监控的某个Redis服务器出现问题，Sentinel可以通过API向管理员或者其他程序发送通知；
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作，Sentinel会进行一次自动故障迁移。
• 特点：
  • 高可用
  • 监控所有节点
  • 可以自动故障迁移
• 缺点：
  • 主从模式切换时间中，数据会丢失
  • master写压力没有解决

集群模式（Proxy）

高端玩法。使用Twitter开源的Twemproxy，一个Redis和Memcache快速/轻量级代理服务器，他是一个快速的单线程代理程序，支持Memcached ASCII协议和Redis协议。

• 特点鲜明：
  • 1.支持多种hash算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins；
  • 2.支持自动删除失败节点。
  • 3.后端Sharding分配逻辑对业务透明，业务的读写方式和操作单个Redis一致；
• 缺点：
  • 维护高可用的成本增加，因为同样要维护proxy的高可用

集群模式（直连）

Redis 3.0后版本支持Redis-cluster集群，采用的是无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。

• 特点：
  • 无中心架构，少了proxy代理层
  • 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布
  • 可扩展性，节点可以动态增加或者减少
  • 高可用性，当有节点不可用时，集群仍然可用，可以增加slave做备份数据副本
  • 实现故障自动failover，节点之间通过gossip协议交换状态信息，通投票机制完成slave到master的角色提升
• 缺点：
  • 资源隔离性差，很容易出现相互影响
  • 数据通过异步复制，强一致性不能保证

高可用

从上面的几种Redis架构中可以看到，Redis的高可用主要由Cluster集群模式、sentinel哨兵模式，当主服务器挂掉后，会从节点中选择出一个新的主服务器，并调整其他从服务器Slave关联到新的master上。

选举策略一般分三种：

• Slave的Priority设置的越低，优先级就越高；
• 相同情况slave复制的数据越多，优先级越高；
• runid越小，越容易被选中升为master；

如果使用Sentinel模式，为了保证Sentinel的高可用，通常会部署3个Sentinel。那么多个Sentinel之间通过Raft协议来保证自身的高可用。

关于Raft协议，这个协议是大师提出的，非常的牛，解决了很多分布式一致性的问题，这个理解起来也不容易，我也没怎么看这个算法。

Sentinel用三个实例去保证健壮性，虽然不能保证数据不丢失，但是在高可用上是可以保证的。

• 监控：负责监控集群内的Redis Master和Slave进程是否正常工作；
• 消息通知：如果发现某一个Redis实例出现问题，可以发送消息通知出去；
• 故障转移：如果Master故障了，可以自动转移到slave上；
• 配置中心：故障转移后，能通知client去新的Master；