目录

一、概述

1、Redis架构

2、AKF

3、CAP原则

---

一、概述

1、Redis架构

Redis 有哪些架构模式？讲讲各自的特点

单机版

特点：简单

问题：

1、内存容量有限 2、处理能力有限 3、无法高可用。

主从复制

Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。

特点：

1、master/slave 角色

2、master/slave 数据相同

3、降低 master 读压力在转交从库

问题：

无法保证高可用

没有解决 master 写的压力

哨兵

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点：

1、保证高可用

2、监控各个节点

3、自动故障迁移

缺点：主从模式，切换需要时间丢数据

没有解决 master 写的压力

集群（proxy 型）：

Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

特点：

1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

集群（直连型）：

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

特点：

1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。

2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。

4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本

5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。

缺点：

1、资源隔离性较差，容易出现相互影响的情况。

2、数据通过异步复制,不保证数据的强一致性

2、AKF

单一Redis存在的问题

1. 单点故障：只有一台Redis的话，如果它出现故障了，那么就相当于整个服务都不可用了
2. 缓存容量：单台Redis的缓存容量有限，在多数据的场景下不适合使用
3. 访问压力：单台Redis在高并发的生产环境下是会承受很大压力的，有可能压力过高而崩溃

 AKF（X-Y-Z）问题：
1.X轴：主从复制的全量同步解决了单点故障问题，也就是AKF理论中的X轴。
2.Y轴：按照不同的业务使用不同的redis服务。订单、用户、支付等都使用不同的服务。也就是AKF理论中的Y轴。解决Redis缓存容量不够大
3.Z轴：解决单业务中的数据膨胀问题，使用分片模式。使用哈希取摩等散列算法进行散列。例如用户信息、订单信息、商品详情等日请求数据量特别大的问题。
同业务分治需要解决的问题：客户端散列、代理层散列（Twemproxy）、redis集群散列（包含散列路由、无主模型）

3、CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency   /kənˈsɪstənsi/）、可用性（Availability /əˌveɪlə'bɪləti/）、分区容错性（Partition tolerance /pɑːˈtɪʃn ˈtɒlərəns/）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
        一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
        可用性（A）：保证每个请求不管成功或者失败都有响应。
        分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

（C：强一致性，A：高可用，P：分区容错性，三者只能选其二，高并发下P必选）

Redis/MongDB是满足CP原则。

RDBMS满足CA原则。

干我们这行，啥时候懈怠，就意味着长进的停止，长进的停止就意味着被淘汰，只能往前冲，直到凤凰涅槃的一天！