分布式系统
2022-06-27 10:32:33 1 举报AI智能生成
高可用系统高可用系统高可用系统高可用系统高可用系统高可用系统高可用系统
作者其他创作
大纲/内容
负载均衡算法
失败重试机制
健康检查机制
动态负载均衡
负载均衡
计数器
令牌桶
信号量
限流算法
应用级限流
分布式限流
接入层限流
限流
降级预警
自动降级／开关降级
读服务／写服务降级
多级降级
配置中心
使用Hystrix降级／熔断
降级
进程/线程隔离
集群／机房隔离
读写隔离
动静隔离
爬虫／热点隔离
使用Hystrix隔离
基于Servlet的请求隔离
隔离
缓存回收策略：空间／容量／时间
缓存回收算法：FIFO／LRU／LFU
Java堆／Java堆外／磁盘缓存
Guava／Ehcache／MapDB
缓存使用模式：Cache-Aside／Cache-As-SoR／CopyPattern
应用缓存
浏览器缓存
HttpClient客户端缓存
Nginx代理层缓存
HTTP缓存
分布式缓存
热点数据与更新缓存
更新缓存与原子性
缓存崩溃与快速修复
多级缓存
数据库连接池
HttpClient连接池
线程池
池化
代理层超时重试
Web容器超时
中间件客户端超时与重试
数据库客户端超时
NoSQL客户端超时
业务超时
前段Ajax超时
超时与重试
事务回滚
代码库回滚
部署版本回滚
数据库版本回滚
静态资源版本回滚
回滚
系统压测： 压测方案：压测接口／并发量／压测策略／压测指标 压测报告：机器负载／QPS／响应时间／成功率 压测方式：线下／线上压测 读写／仿真／引流／隔离集群／熔断压测 单机／集群／离散／全链路压测
系统优化和容灾： 单机调优 架构优化／系统扩容 跨机房容灾
应急预警： 网络接入层：DNS／LVS／HaProxy 应用接入层：Nginx／OpenResty WEB应用层：Tomcat 服务层：Dubbo 数据层：Redis／DB
监控报警： 服务监控／系统监控／JVM监控／接口监控 报警策略：监控时间段／报警阀值／通知方式
压测与预警
同步阻塞调用
异步Future
异步Callback
异步编排CompletableFuture
请求缓存／请求合并
异步并发
单体应用垂直扩容
单体应用水平扩容
应用拆分
数据库拆分 水平／垂直拆分
使用sharding jdbc 分库分表／读写分离
数据异构
任务系统扩容Elastic-Job
扩容
异步处理／系统解耦数据同步／流量削峰
缓冲队列／任务队列／消息队列请求队列／数据总线队列
Disruptor+Redies队列
基于Canal实现数据异构
队列
快速失败策略
切换到备份服务
失效转移
A: Atomicity 原子性
C: Consistency 一致性
I: Isolation 隔离性
D: Durability 持久性
ACID(酸) MVCC实现
BA: Basically Available 基本可用
BASE(碱) 解决了CAP提出的分布式系统的一致性和可用性不可兼得的问题
酸碱平衡理论
A: Availablity 可用性
P: Partition tolerance 分区容忍性
CAP 分布式系统
应用程序，参与者
事务管理器，协调者
资源管理器，参与者
通信资源管理器，参与者
模型角色
定义应用程序与事务管理器的接口
TX
定义事务管理器与资源管理器的接口
XA
JEE分布式事务处理模型规范
协调者向参与者发起指令，参与者评估自己的状态，如果评估指令可以完成，则写redo或undo日志(Write-AheadLog)的一种，然后锁定资源，执行操作，但是不提交。
准备阶段
如果每个参与者明确返回准备成功，协调者向参与者发起提交指令，参与者提交资源变更事务，释放资源。如果有一个参与者明确返回准备失败，则协调者向参与者发起终止指令，参与者取消已经变更的事务，执行undo日志，释放资源。
提交阶段
每一次指令都必须明确收到响应才能进行下一步，否则阻塞，占用的资源一直锁定，不会释放。
阻塞
如果协调者宕机，参与者没有协调者只会，则一直阻塞。尽管会有新的被选举出来的协调者，但如果协调者在发送一条提交指令后宕机，而提交指令仅被一个参与者接收，并且参与者接收后也宕机，则新的协调者无法处理这种情况。
单节点故障
协调者发送提交指令，有的参与者接收到并执行了事务，有的参与者没有接收到事务就没执行事务，导致多个参与者之间的不一致。
脑裂
缺点
两阶段提交
协调者询问参与者是否可以完成指令，协调者只需要回答是或者不是，不需要做真正的操作，这个阶段超时会导致终止
询问阶段
增加了询问阶段，保证尽可能早的发现无法执行操作的指令
增加超时设置，一旦超时，协调者和参与者都会继续提交事务，默认成功。从概率统计的结果显示默认成功的正确性大。
与两阶段的不同
三阶段提交
Try
Confirm
Cancel
具有一定的自我修复能力
特点
TCC
DTS 分布式事务处理模型
任何服务都需要提供一个查询执行操作状态的接口，服务使用方可以通过查询接口得知数据当前状态，然后做不同的处理。
1. 每个服务操作都有一个唯一ID标识
2. 自我判断，单条还是批量查询，并做好吞吐量，熔断，隔离，限流等方案
注意事项
1. 查询模式
1. 自动恢复
2. 通知运营来操作，当然首先要有相应的功能
3. 技术运营，比如修改数据状态，修改代码上线等，尽量避免，不推荐❌
2. 补偿模式
3. 异步确保模式
关键需要一个自始至终唯一的ID
4. 定期校验模式
记录消息状态在DB，发送成功后标记为已发送。定时轮训未发送的消息发送出去。
1. 消息的可靠发送
2. 消息处理器的幂等性
5. 可靠消息模式
读的顺序是先读缓存，后读数据库，写的顺序是献血数据库，后写缓存。
6. 缓存一致性模式
保证最终一致性的模式
使用场景: 实时性要求高，大规模，高并发的短小操作，不适合用于后段负载较高的场景。
方案: 通过查询模式解决
1. 两状态(成功/失败)同步接口
方案: 最大努力将用户请求的操作处理成功
2. 三状态(成功/失败/处理中)同步接口
超时解决方案
1. 同步调用模式
使用场景: 适用于非核心链路上的负载较高的处理环节，这个环节通常耗时较长，并对实时性要求不高。比如商品卖成功，需要给商户打钱，就可以采用接口异步调用模式。
方案: 查询模式补齐状态
1. 异步调用接口超时
方案: 调用方查询补齐状态
2. 异步调用内部超时
方案: 开发子系统专门处理回调通知
3. 异步调用回调超时
2. 接口异步调用模式
使用场景: 上游不关心下游的处理结果，解耦，对流量可以起到消峰的功能，多应用与非核心链路上负载较高的处理环节中。
方案: 重复发送直到成功
1. 生产者发送消息超时
方案: 1. 消息可丢则消费了就不管了并发量高性能好 2. 持久化消息状态，记录状态，准确性高，不丢消息
2. 消费着消费超时
3. 消息队列异步处理模式
调用方补偿？被调用方补偿？
4. 超时补偿原则
微服务的交互模式
超时处理的模式
理论
3. 如果业务规则限制，无法将相关数据分到同一个分片上，则需要实现最终一致性，记录事务的中间状态，若不一致则通过系统自动化，补偿机制修复。
实践经验
分布式系统一致性
运行高效，性价比高
高性能
持续可用性，缩短宕机时间，出错恢复，可靠性
可用性
垂直伸缩，水平伸缩
可伸缩性
可插拔，组件重用
可扩展性
数据安全，加密，熔断，防攻击
安全性
快速发现，定位，解决
可监控
可灰度，可预览，可Mock，可拆解
可测试性
容错性，可恢复性
鲁棒性
易于维护，监控，运营和扩展
可维护性
可移植，解耦
可重用性
负载均衡策略
高可用策略
I/O模型 (BIO/NIO..)
线程池模型
线程池线程数量
是否多业务混合部署
部署结构
每天的请求量
各接口访问峰值
平均的请求响应时间
最大的请求响应时间
在线的用户量
请求的大小
网卡I/O流量
磁盘I/O负载
内存使用情况
CPU使用情况
容量和性能
请求内容是否包含大对象
GC收集器的选型和配置
其他指标
应用服务器
复制模型
失效转移策略
容灾策略
归档策略
读写分离策略
分库分表策略
静态数据和半静态数据是否使用缓存
缓存数据预热策略
当前数据容量
每天的数据增量
每秒的读/写峰值
每秒的事务峰值
查询是否走索引
是否有大数据量的查询和范围查询
是否多表关联查询
是否用被关锁，可以改成乐观锁？是否可用数据库内置行级锁？
事务和一致性级别
数据库
复制模式/失效转移/持久策略/淘汰策略/线程模型/预热方法/哈希分片策略
缓存内容大小/缓存内容的数量/内容的过期时间/数据结构/每秒的读写峰值/
容量与性能
冷热数据比例/是否可能发生缓存穿透/是否有大对象/是否用缓存实现分布式锁/缓存分片方法(客户端/代理/集群)
缓存
复制模型/失效转移/持久策略
每天的数据增量/消息持久的过期时间/每秒读写峰值/每条消息大小/平均延迟/最大延迟/消费者线程池模型/哈希分片策略/消息的可靠投递/消费者处理流程和持久机制
消息队列
服务质量具体指标
ab
jmeter
mysqlslap
sysbench
dd
hprof
压测工具
服务化系统容量评估和性能保障
项目名称
业务描述
业务背景
架构描述
系统调用平均值，请求响应时间等
当前系统容量
当前系统调用量的峰值，最小，最大请求响应时间
技术背景
现状
要改造的内容
要实现的新需求
业务需求
预估系统容量
预估系统调用量峰值，最小和最大值
性能需求
需求
一句话概括方案的亮点
概述
中间件架构
模块划分
模块通信
信息流
时序图
逻辑架构
数据结构
数据分布
拆分策略
缓存策略
查询策略
数据一致性策略
数据架构
异常处理容灾策略灰度发布上线方案回滚方案
详细说明对方案的具体描述可结合图来说明从如下几个方面进行说明
给出方案的基准数据，并按照性能需求评估需要使用的资源数量
单机并发量
单机容量
单机吞吐量的峰值
按照预估的性能需求，预估资源数量，服务器，缓存，存储，队列等
性能评估
优点
方案的优缺点
方案1
同方案1类似
方案2
方案对比
方案描述
标识所选方案的风险，提出此风险发生时的应对策略。。。例如上线失败快速回滚等
风险评估
列出具体工作的安排时间，评估开发，测试细化任务的时间，形成可实施的任务计划列表
要求一定可以量化，如果事情预估可能问题较多，需要做好buffer
工作量评估
技术评审提纲
提升线上问题感知能力
目标
DNS监控
线路监控
CDN监控
防火墙
网络服务
cpu.busy.avg
CPU
mem.memused.nocache.percent
内存
disk.used
磁盘
net.if.in.errors
网络
disk.io.util(%)
磁盘IO
sys.dmesg.oom
进程
实例异常
容器
服务器
资源层
内存使用率
每分钟GC次数
每次GC耗时P995
GC吞吐率
YGC
GC次数
GCP995
FGC
内存回收
每分钟内存增长统计
堆内存使用率
方法区
等待线程
阻塞线程
线程各种状态指标
线程总数
活跃线程数
线程监控
Metaspace
JVM
业务异常
系统异常
代码
499 > 1S
5xx
200等
NG域名统计
SLA可用性
QPS
TP99/TP95/AVG
耗时
Nginx域名总耗时
Nginx后端耗时
带宽流量
接入层
异常
核心接口SLA
平均响应时间
响应时间
接口延迟
每分钟500个数
每分钟失败次数
接口HTTP/RPC
基础监控
请求数监控
请求耗时TP99/TP95/AVG
异常情况
服务依赖方
Tomcat
消费堆积报警Lag
消费失败告警
kafka
消息堆积报警Lag
消费失败报警
rocketMQ
MQ
容量使用率
分钟逐出个数
Redis
ES
连接数
慢查询
磁盘占用
数据量
buffer
主从同步延迟
Threads Running
Innodb行锁等待
每秒磁盘中索引扫描行
每秒死锁次数
mysql
中间件
系统监控
同比/环比
预警阈值
数据计算是否正确
数据逻辑
数据一致性
数据监控
用户量
页面访问时间
功能监控
业务监控
类型
现有监控
缺失监控
核心监控覆盖
范围
技术侧
产品侧
业务方
谁关注监控
监控告警
高可用
0 条评论
回复 删除
下一页
