共计 1163 个字符，预计需要花费 3 分钟才能阅读完成。
作者：等不到的口琴 \
链接：https://www.cnblogs.com/Coura…
当咱们搭建集群的时候, 首先要想明确须要解决哪些问题, 搞清楚这个之前, 想想单节点、单实例、单机有哪些问题?
- 单点故障
- 容量无限
- 可反对的连贯无限(性能有余)
- ……
为了解决这些问题, 咱们须要对服务器进行集群, 一变多, 具体怎们裁减服务器呢?
这儿引入一个概念, 微服务设计准则之一——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 轴拆分: 基于数据拆分。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.Spring Boot 2.6 正式公布，一大波新个性。。
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
