乐趣区

关于java:Redis-集群别乱搭这才是正确的姿势

作者:等不到的口琴 \
链接: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 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

退出移动版