【闲聊杂谈】Redis中的AFK原理

当我们谈论到单机单实例，一般会有哪些问题？

①单点故障

②数据容量有限

③压力（CPU计算压力和socket连接压力）

而AKF，就是以x、y、z三轴多方位的去解决这些问题。

从X轴角度，可以使用多台Redis，做一台Redis的副本

客户端只要访问主要主Redis，而主Redis将数据同步给副Redis，这样就解决了【①单点故障】的问题。

而随着发展，反正多台机器也搭起来了，那这钱别浪费呀，能压榨就压榨。客户端可以对主Redis进行增删改，对副Redis们进行读取，就是读写分裂。

但是，这真的能解决【②数据容量有限】的问题吗？要知道，一般基于X轴都是全量镜像。意思就是X轴上的主Redis和副Redis的容量是一样的，假设主Redis有10G的数据，副Redis也是10G的数据，随便一个拿出来等于是整个Redis库中所有存的数据，所以一般是不能解决【②数据容量有限】的问题。而且，虽然客户端连接多台，对于【③压力】问题也只是解决了一部分，但没有全部解决。

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

这样，不同的数据就会存到Y轴上的不同Redis中，如此就可以解决【②数据容量有限】的问题。是不是有点像微服务拆分的原则，而AKF正是微服务拆分四项原则中的第一条，而且AKF不仅只限定于微服务。

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

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

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

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

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

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

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

②只要主Redis写入成功，就直接和客户端返回成功，然后副Reduis异步复制写入主Redis数据；

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

③为了解决弱一致性带来的数据丢失问题，可以在主Redis和众多的副Redis中搭建kafka，主Redis和kafka是同步阻塞的， 主Redis必须等kafka返回成功才可以向客户端返回成功。而kafka中的数据副Redis自己从中去取，然后写入库中。这个叫：最终一致性。

 好了，数据一致性问题解决后，还会存在别的问题，我们后面继续说。

今天的文章【闲聊杂谈】Redis中的AFK原理分享到此就结束了，感谢您的阅读。