Redis中的AFK原理

回顾Redis：Redis是单机、单进程的，一般常用于缓存和数据使用。然而我们要进行Redis集群，搭建高可用Redis方式。

---

Redis 特点：

单机、单进程、单实例

正因为是单机的，所以会有一下问题：

1：单点故障

2：数据容量有限

3：压力（CPU计算压力和socket连接压力）

而假如在面试的时候有被问到设计到“单机”的相关问题，就可以往AKF上面引入

单机劣势

了解AKF：

    AKF是从X、Y、Z三个轴方向去尝试解决上述3个问题

    从X角度，可以使用多台Redis，做第一台Redis的副本，这样就可以解决【单点故障问题】：

    随着发展，这些多台机器也搭建起来了，那这些钱可千万不能浪费呀，能压榨就压榨。客户端可以对主Redis进行增删改，对副Redis进行读   取，就实现了读写分离：

    基于X轴的解决方案，是全量镜像的，什么意思呢？意思就是：X轴上的主Redis和副Redis的容量是一样的，比如主Redis有10G，其他其他的副Redis同样也是10G，那这样的话，问题2【数据容量有限】的问题就出来了。数据有时候会远超10G的！

    从Y轴角度，对库中的数据按照业务进行划分不同的实例去存储：

    这样，不同的数据就会存到不同的Redis中去，如此就可以解决【数据容量有限】的问题。是不是有点像微服务拆分的原则？而AKF正式微服务拆分四项原则中的第一条，而且AKF不仅仅只限定于微服务，如数据库，Tomcat都可以。 了解微服务拆分四项原则：https://www.cnblogs.com/guanghe/p/10978349.html

    基于Y轴一般是按照业务、功能等来划分数据，这是只针对于Y轴来说，但Y轴上的每个节点也要解决【单点故障问题】，所以就需要X轴、Y轴同时部署Redis实例矩阵。

    从Z轴角度，再对Y轴实例（某个业务）的数据进行再次拆分

    假设Y轴上的某个节点存放的是“用户信息”，那么从Z轴的角度来讲，Z轴上的每个节点可以存放100万个用户，不同的用户出现在固定的库里。一般Z轴是按照优先级，或者特定的逻辑再进行拆分，Z轴的出现，是为了确保解决【数据容量有限】和【压力】的问题。

    经过X、Y、Z轴拆分之后，每台实例的数据量已经足够小，当数据量足够小的时候，更能够发挥单机的性能，再也没有了容量的限制。而且，主Redis都还有多台副Redis，就不会出现单点故障问题。而且当数据量足够小的时候，访问量自然不会大。

    AFK三轴拆分后，引入的数据一致性问题

    当客户端对Redis进行写的时候，主Redis先不返回客户端是否写入成功，而是先去通知副Redis同步复制写入，主Redis在阻塞等待着，直到数据全部一致，主Redis再返回客户端写入成功：【强一致性】

这是通过同步方式达成的强一致性，但是强一致性的缺陷也很明显，只要有一个Redis的网络通信不好，就会导致所有的写入失败，所以强一致性极容易破坏可用性。简单说，我用你了，但你不太好用，或者根本不能用。

    只要主Redis写入成功，就直接和客户端说返回成功了，然后副Redis异步复制写入Redis数据；【弱一致性】

这是通过异步方式达成弱一致性，但是弱一致性的缺陷在于，有可能主Redis写入成功，但是副Redis没有成功写入，就导致副Redis丢失部分数据。

    为了解决弱一致性问题，可以在主Redis和众多副Redis钟搭建kafka，jnode等中间件去解决问题。主Redis和kafka是阻塞的，主Redis必须等Kafka返回成功才可以向客户端返回成功。而Kafka中的数据副Redis自己从中去取，然后写入库中。这个叫【最终一致性】。

最终一致性