本篇着重套论集群配置的一些理论及问题，顺带讨论Redis集群

AKF拆分原则

单机Redis面临的挑战

当一个Redis处于单机状态的时候，这个Redis要面临许多的问题，这些问题在实际生产环境中往往是致命的

1. 单点故障（高可用问题）

   • 当我的Redis只有一个的时候，我的Redis承载了太多的内容，一旦它故障挂掉了，那么就会面临程序崩溃的风险，这会使得公司面临风险，大大影响收益

   • 面对这种问题，我们可以采用“主备”模式

     

   • 一个Redis作为主机，剩余数个Redis作为备机，每一个Redis备机都有Redis主机的全量数据，这被称为全量备份；当Redis主机崩溃的时候就可以把备机提出来当作主机

   • 但是，我们都已经花钱买了备机了，让这些备机一直等待上位当主机，啥事也不干有点亏本，所以我们还可以采用“主从”模式

     

   • 客户端在访问数据的时候，对主机可以进行所有的增删改查操作，但是对于从机只能进行查操作，这样就分流了主机的查询压力，把备机也一起使用上了

   • 主从和主备本质上都是“一变多”过程，这样可以将原本单机不可靠的redis变得可靠，可用性大大提升（请记住，集群的目的是为了解决可用性，让原本单机可用性低的程序变成高可用程序）

2. 单机Redis容量受限（存储空间有限）

   • 当我公司内部的数据量变大的时候，一个Redis就会面临巨大的数据存储要求，这给单机本来就不大的Redis带来压力，一般都会按照业务流程拆分数据，分别放入不同的Redis中

     

   • 沿着y轴，将所有的公司数据竖切成不同类型，订单信息单独存放、用户信息单独存放、库存信息也单独存放，这样就可以分摊数据量过大带来的压力

   • 但是，随着公司数据的不断扩张，有一天，某个redis有可能会无法承担整个公司的单独的收据模块，需要将本就被切分的数据再次切分

     

   • 因为公司的用户量实在太大，一个redis存放已经带来了压力，所以我们将用户按照编号做了切分前10w个用户放在第一组redis中，10w到20w放在第二组redis中，我们自己在设计好访问逻辑，确保0-10w的用户可以访问第一组redis，10w到20w的用户可以访问第二组redis

3. 单个redis的压力过大（连接压力）

   • 我们的单机redis会面临连接压力过大的问题，但是我们按照AKF原则拆分的redis集群就可以解决这个问题，刚刚上述的x轴、y轴、z轴切分业务就是AKF拆分的一个实战

AKF拆分原则介绍

• AKF可扩展架构立方体是《架构即未来》一书中提到的一种可扩展架构，这个立方体一共有三种维度
  1. x轴：无差别的克隆复制数据和服务，让工作均匀的分布在每一个克隆服务上
  2. y轴：关注应用中职责的划分，如用户模块、订单模块
  3. z轴：关注服务和数据的优先级划分，例如按照地域划分
• 三个维度划分的比较
  1. x轴扩展：
     • 优点：成本最低，易于实现
     • 缺点：受指令集多少和数据大小约束，如果一个服务过于臃肿，单个服务就需要极长时间相应，那么x轴扩展不一定可以带来多大的性能提升（有点像集群）
     • 适用场景：发展初期，业务复杂度低，需要增加系统容量
  2. y轴扩展：
     • 优点：可以解决指令集和数据集的约束，解决代码复杂度问题，实现故障隔离
     • 缺点：成本较高
     • 适用场景：业务复杂，数据量大，代码耦合度高，团队规模大
  3. z轴扩展：
     • 优点：能够解决数据集约束，降低故障风险，实现渐进式交付，带来最大扩展性
     • 缺点：成本昂贵
     • 适用场景：用户指数级快速增长

提高单机Redis可用性详细分析

同步阻塞强一致性架构

• 当客户端向服务器发起一条请求的时候，redis主机采用同步阻塞的方式等待所有备机都完成请求后再向客户端发起执行成功命令

  

• 强一致性带来的弊端

  如果采用强一致性架构会出现一个问题，当备机出现问题时，主机向备机发起同步请求，但是备机一直没有同步成功，达到了超时时间后，主机会像所有的备机发出请求失败，撤回请求的命令，最后反馈给客户端一个失败的回复，那么在客户端看来就是我使用这个服务，最后这个服务却返回一个失败的指令，体现出了服务不可用的特点。

  回到使用主备模型的最初点，我们本来使用主备模型是希望让服务的可用性提升，但是我们因为采用强一致性架构反而使得服务不可用，这是无法忍受的

异步非阻塞弱一致性架构

• 既然使用强一致性会导致服务不可用，那么我们给强一致性降级

• 当用户向redis发起请求的时候，redis主机会执行请求，请求执行完毕后会异步的向备机也发出指令，随后向用户发起请求执行成功的指令

  

• 异步非阻塞的弊端

  如果主机挂了，备机上台顶替，但是因为备机和主机之间的通信有问题，前面有一部分内容没有备份，那么表现在用户方就是数据不一致，这是这个架构的缺陷，但是只要能够忍受数据的部分丢失，这个架构就可以使用

最终一致性架构

• 虽然达不到强一致性，但是我们要保证最终的一致性，也就是备机在上去顶替主机的时候能够保证和主机是一致的

• 当用户向redis发起请求的时候，redis接受请求，然后执行，执行完毕后交给一个绝对可靠的中间件（可以是kafka，但是这个中间件一定是集群式的）让这个中间件去和后面的备机做备份，redis主机只要确认kafka成功得到命令之后就会向客户端返回执行成功命令，而后面备机的同步就交由kafka去执行，只要保证最后的最后数据是一致的就行了

  

主备模型和主从模型的细微区别

1. 主备模型的备一般是不允许访问的，只能访问主，备机就是一直等待主机出现问题然后接替主机

2. 主从模型的从一般是允许访问的，但是一般只能进行查操作，不能进行写操作，主从模型的增删改一般都是交给主，查则是主和从都能进行

3. 主从模型的主一般是需要一个备机的，而主备模型的主一般不需要

   

Redis的主从模型选择的架构

Redis的主从模型选择的架构是异步非阻塞弱一致性模型

redis的官方文档中有一句话是核心：Redis使用默认的异步复制，其特点是低延迟和高性能。

架构师的职责就是选择合适的技术，让合适的技术在合适的地方发光发热，Redis的特性就是高速，我们应该尊重Redis的特点，redis的作者也非常清晰redis的定位，他没有像另外的作者一样给redis自带一个分布式中间件让redis可以直接实现最终一致性，因为如果redis中整合了太多的内容的话，redis的速度就会受到影响。架构师就是要让redis在合适的地方使用，如果非要改变redis的特点来强行匹配强一致性，那还不如直接就使用其他技术

CAP原则

CAP原则简介

CAP原则，又称为CAP定理，即一个分布式系统只能在一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）中做取舍，只能同时满足三者中的其中两者

• 一致性：在分布式系统中所有数据备份在某一时刻中是否是同一个值，即写操作之后的读操作必须返回该值（一致性分为：强一致性、弱一致性、最终一致性）
• 可用性：在集群中一部分节点故障后，集群整体是否能够响应顾客的读写操作（对数据更新必须具备高可用）
• 分区容忍性：以实际效果而言，分区容忍性相当于对通信的时限有要求，如果分布式系统不能在时限内达到数据一致性，那么就出现了分区，此时就必须在C和A中做选择

C和A之间存在矛盾

• 在CAP原则中，C和A之间是存在矛盾的，这就是为什么CAP原则最多选取其中之二的原因
• 如果你想要强一致性，那么就选择没有分区，没有备份，就一台redis；或者选择有分区，但是分区之间同进同退，一台备机出现问题，整个系统就无法提供服务
• 如果你想要可用性，那么就必须要分区，要有集群，这是可用性的基础，然后每一个节点之间的关联不能特别的强，不能一个节点损坏，整个集群都无法使用