分布式系统CAP----高可用（故障依然可用）

最新推荐文章于 2024-10-14 08:29:07 发布

小小梦里花007

最新推荐文章于 2024-10-14 08:29:07 发布

阅读量1.2k

点赞数

分类专栏：运行过程类文章标签：分布式队列

原文链接：https://www.cnblogs.com/javawxid/p/12812001.html

版权

运行过程类专栏收录该内容

52 篇文章 3 订阅

订阅专栏

一、高可用目标

二、解题思路

三、实现方法

3.1、服务----双机热备、集群和数据分区、异地多活

3.1.1、双机热备----主备，主从，双主

3.1.2、集群和数据分区----集群、数据分区

3.1.3、异地多活

3.2、服务----优先核心业务

3.2、服务（优先核心还不行呢？要么限流，要么扩容或加负载）

3.3、高可用的数据

一、高可用目标

即在集群中一部分节点故障后，集群整体依然能响应客户端的读写请求；

那么高可用就得保证服务器硬件故障服务依然可用；

网友总结：高可用的“大杀器”是----限流，降级（熔断，拒绝服务，超时设置）

什么是限流？

服务器能处理的请求数有限，如果请求量特别大，我们需要做限流（要么就让请求等待，要么就把请求给扔了）；

我自己理解：

同一时刻（第1毫秒）给我1000W的请求让我处理，我处理不了，我同一时刻只能处理100W的请求，那么我可以这样限流：1000W请求在【第1毫秒】到了，但我只让100W的请求进来处理，其他的等着，然后【第2毫秒】再进来100W，然后【第3毫秒】再进来100W，然后【第4毫秒】再进来100W。。。

二、解题思路

对于服务而言，一旦某个服务器宕机，就将服务切换到其他可用的服务器上；

对于数据而言，如果某个磁盘损坏，就从备份的磁盘（事先就做好了数据的同步复制）读取数据。

故障真发生避免不了了，要有所取舍，保证核心业务，高优先级业务；

三、实现方法

3.1、服务----双机热备、集群和数据分区、异地多活

此块引用自：

原文链接：https://blog.csdn.net/AWEI1024/article/details/109343547

3.1.1、双机热备----主备，主从，双主

主备

主从

双主

3.1.2、集群和数据分区----集群、数据分区

集群

数据分区

3.1.3、异地多活

更高的可用性，意味着更高的成本，更高的复杂度。对于大公司而言，往往还会进行异地多活的架构。

异地多活常见方式有：

同城跨区
跨城
跨国
跨洲

3.2、服务----优先核心业务

　　高可用的服务模块为业务产品提供基础公共服务，在大型站点中这些服务通常都独立分布式部署，被具体应用远程调用。

　　在具体实践中，有以下几点高可用的服务策略可以参考：

　　①分级管理：核心应用和服务具有更高的优先级，比如用户及时付款比能否评价商品更重要；

　　②超时设置：设置服务调用的超时时间，一旦超时后，通信框架抛出异常，应用程序则根据服务调度策略选择重试or请求转移到其他服务器上；

　　③异步调用：通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况（不是所有服务都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务调用成功后才能继续进行下一步的操作的应用也不适合异步调用。）

④服务降级：网站访问高峰期间，为了保证核心应用的正常运行，需要对服务降级。

　　降级有两种手段：一是拒绝服务，拒绝较低优先级的应用的调用，减少服务调用并发数，确保核心应用的正常运行；二是关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为核心应用服务让出资源；

　　⑤幂等性设计：保证服务重复调用和调用一次产生的结果相同；

3.2、服务（优先核心还不行呢？要么限流，要么扩容或加负载）

①限流：手动实现负载均衡，图形验证码，容器限流，限流总资源数，从代码级限流某个接口的总并发/请求数，Nginx限流，消息队列，redis限流

②缓存

③自动扩容收缩

这里需要注意的是，如果在现有集群环境下，负载压力仍然很大怎么办？使用Docker+K8s(Kubernetes)构建Docker集群环境。当QPS超过阈值后，自动扩容。比如扩容两个虚拟机，将登录子系统从四节点扩容到6节点，然后修改nginx配置文件。在流量高峰期过后，再触发自动收缩技术，减少虚拟机，减少资源的消耗。