高可用架构补充篇

​

点击蓝色 乔志勇笔记 关注我哟

加个星标，第一时间获取推送的文章哦

一、计算高可用架构

1、主备模式 分冷备和温备

2、主从模式 需要按业务设计任务分配器

3、高可用集群模式

可以完成故障自动切换

1）负载均衡集群

任务分配器实现分配策略的选择和服务器的探活

2）非对称集群

任务分配器需要考虑服务器的角色

例如zk的每个节点都包含任务分配器，follow节点收到写请求转发给leader，读自己处理。

leader节点故障后zk停止服务选取新的leader

二、业务高可用架构

（1）接口级故障处理方案

核心思想：优先保证核心业务和优先保证绝大部分用户

1、服务端降级

按照业务的优先级，停掉部分或者全部功能呢

方式：

1）系统后门降级

难以批量操作

2）独立降级系统

2、客户端熔断

设计要点：统一采样、阈值调优

3、服务端限流

1）基于请求限流(外部)

限制总量、限制时间量

2）基于资源限流(内部)

常见的内部资源有：连接数、文件句柄、线程数、请求队列

4、服务端排队策略

具体设计：

排队模块：基于rocketmq消息队列，每个商品保存一个队列，队列大小稍微大于商品数量，保证先进先出

服务模块：处理业务逻辑，异步返回处理结果

调度模块：根据服务模块的处理能力，动态调节服务模块向排队模块拉取请求的速度

（2）异地多活解决方案

1、同城异区

应对机房级别故障的最优架构，两个机房搭建告诉网络连接，

架构设计上可以将两个机房当做本地机房来设计，无须额外考虑

2、跨城异地

应对极端灾难性事件，架构设计上需解决数据不一致对业务的影响。

新闻类，微博类业务可以采用跨城异地多活

设计技巧：

1）保证核心业务的异地多活

2）保证核心数据最终一致性

3）采用多种手段同步数据

4）只保证绝大部分用户的异地多活

设计步骤：

1）业务分级

2）数据分类

3）数据同步

4）异常处理

3、跨国异地

应用场景决定了对架构设计要求不高

应用场景：

1）为不同地区用户提供服务 ，跨地区账号无法通用

2）只读类业务做多活，例如谷歌搜索引擎

限时分享面试&学习福利资源

好资料第一时间分享，中华石杉老师的分布式面试突击视频教程，最清晰整体的微服务全面解读的PDF，体系化的Java路线资料整理的Github，亿级电商架构的视频实战课程，你值得拥有

获取方式: 关注公众号乔志勇笔记, 后台回复"学习资料" ！！！