redis单实例布置项目主要会出现下面三个方面的问题：
- 单点故障。如果这个redis实例挂掉，就需要重启，或者重新布置实例。这需要一定的时间，在这个时间之内，所有的请求都会透穿到数据库。甚至在一些极端的情况下，整个物理机出现故障了，就需要把硬盘取下来，安装到别的物理机上。无论是上述哪种情况，都极为消耗时间，对整个系统稳定运行的威胁较大。
- 内存不够。一台redis的内存本身是有限的。如果需要往redis布置10个g的数据，但是内存只有4个g，或8个g。所以内存大小本身也是有限制的。
-
访问压力大。无论是socket io，而是CPU本身的计算，压力都比较大。
那么如何解决这些问题呢？
有一个理论叫做AKF，即从x，y，z三个维度来进行服务的拆分。
（1）x轴方向：可以选择主备模式，即一主多备，一台redis作为主，其他的多台redis作为备。“备”里存的是“主”的全量镜像数据，如下图：
aa.png
这种情况下，就算主redis挂掉了，但是因为备redis里存的是全量数据，所以可以直接绕过出故障的主，而去访问备，由此可见，可以解决单点故障的问题。
另外，既然这么多redis都已经准备好了，所以的操作都压在一台redis上，明显造成了其他redis资源的浪费。所以一般都会让主redis进行增删改的操作，让其他的备redis进行查询的操作，所以可以解决一部分访问压力的问题。
由于存的是全量的数据，比如主redis里存了10个g的数据，所以每个备redis里必须也存10个g的数据，所以并没能解决内存不够的问题。
（2）y轴方向：从以上分析可以看出，x轴方向上的主备模式能够解决单点故障的问题，以及一部分访问压力的问题，但是没能够解决内存限制的问题，所以y轴方向的布置主要解决的就是这个问题。
y轴方向上主要是根据业务功能的模块儿进行拆分，比如购物系统中的订单模块数据放到一个redis，支付模块儿的数据放到一个redis，商品信息模块儿放到一个redis，等等。如下图：
image.png
按照业务的功能模块儿进行拆分之后，本来10个g的数据，可以现在y轴上的每个redis只需存放3个g或者4个g的数据，所以解决了内存限制的问题。由于每个redis上的数据分属不同的模块儿，所以访问压力的问题也得到了部分解决。每个模块儿在x轴上都有备份，所以单点故障的问题也得到了解决。
（3）z轴方向：根据以上分析，x轴+y轴的拆分模式基本上已经解决了单实例三个主要的痛点问题。但是有些情况，比如我的每个redis只能存10个g的数据，但是下单的人比较多，订单数据里需要存放20个g的数据，所以需要把本来存放订单数据的redis再进行z轴上的拆分，如下图：
image.png
可见，原来的订单数据在z轴上分为了两个小模块儿，每个小模块儿作为主redis，都可以在x轴上有备redis。
AKF拆分有效的解决了单点故障，内存限制，访问压力三个问题，但是在实践中，仍然会存在一些问题的考量。比如在主备数据同步的过程中，怎么保证数据的一致性问题，下节再作分析。
