Redis集群拆分原则之AKF

当咱们搭建集群的时候,首先要想明白须要解决哪些问题,搞清楚这个以前,想一想单节点、单实例、单机有哪些问题?

• 单点故障
• 容量有限
• 可支持的链接有限(性能不足)
• ......

为了解决这些问题,咱们须要对服务器进行集群,一变多,具体怎们扩充服务器呢?

这儿引入一个概念,微服务设计原则之一——AKF原则

微服务拆分原则之AKF

首先来看单节点的单点故障这个问题,既然单节点容易挂,那么就能够进行复制,一变多,这儿设计到三个概念,主从、主主、主备,也是三种方式,简单来讲,主主至关于多台服务器同时对外提供读写:

主从,主机能够读写,可是通常只对外提供写,从机对外提供读:

主备,主机提供读写,备机不对外提供服务,当主机挂了的时候,备机经过选举产生主机对外提供服务。

X轴拆分

能够看到的是,这几种拆分一台机器能够当作另外一台机器的镜像,基本具备全量数据,这种拆分模式就是AKF拆分模式之一:X轴拆分

上图就是AKF拆分示意图,为了解决单点故障,因此弄几台全量数据的机器作备份,例如以前说到的主主、主备等,特色是任何两台包含的数据是差很少的,一台能够当作另外一台的镜像。

Y轴拆分

这时候又有新的问题,例如一台服务器中,可能某些功能被频繁访问,涉及到的数据频繁读写,其余数据基本不怎么访问,这时候能够将这部分数据独立出来,也就是根据功能、业务继续拆分服务器,这种拆解就是AFK中的Y轴拆分

特色是Y轴纵向来看不一样的Redis负责的功能是不一样的,也就是所包含的数据也是不一样的,另外仅仅扩展出一个Y轴上的业务服务器,又可能会存在单点问题,因此能够结合AFK的X轴拆分原则,继续对刚拆分的Y轴上的点进行X轴拆分。

Z轴拆分

在上面的AFK原则X-Y拆分以后,对服务器显示作了主从主备复制,而后作了业务拆分,不一样的Redis负责不一样的业务请求,这时候还会有一个新的问题,例如对于Y轴上一个Redis,它负责某同样业务,可是这天这个业务的数据访问巨大,贼大,那就只好对数据请求进行AFK的Z轴拆分,例如先分析下数据请求的状况,而后根据访问来源,分为北京的、上海的,这样不一样的Redis虽然是负责不一样的数据,可是负责的业务是同样的。AFK拆分图示:

AFK总结

X轴拆分:水平复制，就是讲单体系统多运行几个实例，作集群加负载均衡的模式,主主、主备、主从。

Y轴拆分:基于不一样的业务拆分

Z轴拆分:基于数据拆分。