分布式系统思维导图模板_ProcessOn思维导图、流程图

负载均衡

负载均衡算法

失败重试机制

健康检查机制

动态负载均衡

限流

限流算法

计数器

令牌桶

信号量

应用级限流

分布式限流

接入层限流

降级

降级预警

自动降级／开关降级

读服务／写服务降级

多级降级

配置中心

使用Hystrix降级／熔断

隔离

进程/线程隔离

集群／机房隔离

读写隔离

动静隔离

爬虫／热点隔离

使用Hystrix隔离

基于Servlet的请求隔离

应用缓存

缓存回收策略：空间／容量／时间

缓存回收算法：FIFO／LRU／LFU

Java堆／Java堆外／磁盘缓存

Guava／Ehcache／MapDB

缓存使用模式：Cache-Aside／Cache-As-SoR／CopyPattern

HTTP缓存

浏览器缓存

HttpClient客户端缓存

Nginx代理层缓存

多级缓存

分布式缓存

热点数据与更新缓存

更新缓存与原子性

缓存崩溃与快速修复

池化

数据库连接池

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实现数据异构

失效转移

快速失败策略

切换到备份服务

分布式系统一致性

理论

酸碱平衡理论

ACID(酸) MVCC实现

A: Atomicity 原子性

C: Consistency 一致性

I: Isolation 隔离性

D: Durability 持久性

BASE(碱)
解决了CAP提出的
分布式系统的一致性
和可用性不可兼得的问题

BA: Basically Available 基本可用

S: Soft State 软状态,状态可以在一段时间内不同步

E: Eventually Consistent 最终一致性,在一定的时间窗口内达到即可

CAP 分布式系统

C: Consistency 一致性

A: Availablity 可用性

P: Partition tolerance 分区容忍性

DTS 分布式事务处理模型

模型角色

应用程序，参与者

事务管理器，协调者

资源管理器，参与者

通信资源管理器，参与者

JEE分布式事务处理模型规范

TX

定义应用程序与事务管理器的接口

XA

定义事务管理器与资源管理器的接口

两阶段提交

准备阶段

协调者向参与者发起指令，参与者评估自己的状态，如果评估指令可以完成，则写redo或undo日志(Write-AheadLog)的一种，然后锁定资源，执行操作，但是不提交。

提交阶段

如果每个参与者明确返回准备成功，协调者向参与者发起提交指令，参与者提交资源变更事务，释放资源。如果有一个参与者明确返回准备失败，则协调者向参与者发起终止指令，参与者取消已经变更的事务，执行undo日志，释放资源。

缺点

阻塞

每一次指令都必须明确收到响应才能进行下一步，否则阻塞，占用的资源一直锁定，不会释放。

单节点故障

如果协调者宕机，参与者没有协调者只会，则一直阻塞。尽管会有新的被选举出来的协调者，但如果协调者在发送一条提交指令后宕机，而提交指令仅被一个参与者接收，并且参与者接收后也宕机，则新的协调者无法处理这种情况。

脑裂

协调者发送提交指令，有的参与者接收到并执行了事务，有的参与者没有接收到事务就没执行事务，导致多个参与者之间的不一致。

三阶段提交

询问阶段

协调者询问参与者是否可以完成指令，协调者只需要回答是或者不是，不需要做真正的操作，这个阶段超时会导致终止

准备阶段

提交阶段

与两阶段的不同

增加了询问阶段，保证尽可能早的发现无法执行操作的指令

增加超时设置，一旦超时，协调者和参与者都会继续提交事务，默认成功。从概率统计的结果显示默认成功的正确性大。

TCC

Try

Confirm

Cancel

特点

具有一定的自我修复能力

保证最终一致性的模式

1. 查询模式

任何服务都需要提供一个查询执行操作状态的接口，服务使用方可以通过查询接口得知数据当前状态，然后做不同的处理。

注意事项

1. 每个服务操作都有一个唯一ID标识

2. 自我判断，单条还是批量查询，并做好吞吐量，熔断，隔离，限流等方案

2. 补偿模式

1. 自动恢复

2. 通知运营来操作，当然首先要有相应的功能

3. 技术运营，比如修改数据状态，修改代码上线等，尽量避免，不推荐❌

3. 异步确保模式

4. 定期校验模式

关键需要一个自始至终唯一的ID

5. 可靠消息模式

1. 消息的可靠发送

记录消息状态在DB，发送成功后标记为已发送。定时轮训未发送的消息发送出去。

2. 消息处理器的幂等性

6. 缓存一致性模式

读的顺序是先读缓存，后读数据库，写的顺序是献血数据库，后写缓存。

超时处理的模式

微服务的交互模式

1. 同步调用模式

使用场景: 实时性要求高，大规模，高并发的短小操作，不适合用于后段负载较高的场景。

超时解决方案

1. 两状态(成功/失败)同步接口

方案: 通过查询模式解决

2. 三状态(成功/失败/处理中)同步接口

方案: 最大努力将用户请求的操作处理成功

2. 接口异步调用模式

使用场景: 适用于非核心链路上的负载较高的处理环节，这个环节通常耗时较长，并对实时性要求不高。比如商品卖成功，需要给商户打钱，就可以采用接口异步调用模式。

超时解决方案

1. 异步调用接口超时

方案: 查询模式补齐状态

2. 异步调用内部超时

方案: 调用方查询补齐状态

3. 异步调用回调超时

方案: 开发子系统专门处理回调通知

3. 消息队列异步处理模式

使用场景: 上游不关心下游的处理结果，解耦，对流量可以起到消峰的功能，多应用与非核心链路上负载较高的处理环节中。

超时解决方案

1. 生产者发送消息超时

方案: 重复发送直到成功

2. 消费着消费超时

方案: 1. 消息可丢则消费了就不管了并发量高性能好 2. 持久化消息状态，记录状态，准确性高，不丢消息

4. 超时补偿原则

调用方补偿？被调用方补偿？

如果被调用方明确响应给调用方, 成功/超时或着其他状态. 如果调用方接收到成功，而被调用方内部调用其他服务失败了，则由被调用方补偿。反之调用方补偿。注意接口幂等性，发生超时等异常都算是没有明确的响应。

实践经验

1. 数据量小时通过单个数据库的ACID特性控制即可，或者使用强悍的硬件加上专业的关系型数据库(Oracle,DB2,MySQL)解决

2. 量稍微大些时，如果用Oracle,DB2或者硬件成本过高，采用廉价硬件运行MySQL进行水平伸缩和分片，将相关数据分到数据库的同一个片上，依然能通过数据库的ACID特性保证事务。

3. 如果业务规则限制，无法将相关数据分到同一个分片上，则需要实现最终一致性，记录事务的中间状态，若不一致则通过系统自动化，补偿机制修复。

服务化系统容量评估和性能保障

高性能

运行高效，性价比高

可用性

持续可用性，缩短宕机时间，出错恢复，可靠性

可伸缩性

垂直伸缩，水平伸缩

可扩展性

可插拔，组件重用

安全性

数据安全，加密，熔断，防攻击

可监控

快速发现，定位，解决

可测试性

可灰度，可预览，可Mock，可拆解

鲁棒性

容错性，可恢复性

可维护性

易于维护，监控，运营和扩展

可重用性

可移植，解耦

服务质量具体指标

应用服务器

部署结构

负载均衡策略

高可用策略

I/O模型 (BIO/NIO..)

线程池模型

线程池线程数量

是否多业务混合部署

容量和性能

每天的请求量

各接口访问峰值

平均的请求响应时间

最大的请求响应时间

在线的用户量

请求的大小

网卡I/O流量

磁盘I/O负载

内存使用情况

CPU使用情况

其他指标

请求内容是否包含大对象

GC收集器的选型和配置

数据库

部署结构

复制模型

失效转移策略

容灾策略

归档策略

读写分离策略

分库分表策略

静态数据和半静态数据是否使用缓存

缓存数据预热策略

容量和性能

当前数据容量

每天的数据增量

每秒的读/写峰值

每秒的事务峰值

其他指标

查询是否走索引

是否有大数据量的查询和范围查询

是否多表关联查询

是否用被关锁，可以改成乐观锁？是否可用数据库内置行级锁？

事务和一致性级别

缓存

部署结构

复制模式/失效转移/持久策略/淘汰策略/线程模型/预热方法/哈希分片策略

容量与性能

缓存内容大小/缓存内容的数量/内容的过期时间/数据结构/每秒的读写峰值/

其他指标

冷热数据比例/是否可能发生缓存穿透/是否有大对象/是否用缓存实现分布式锁/缓存分片方法(客户端/代理/集群)

消息队列

部署结构

复制模型/失效转移/持久策略

容量与性能

每天的数据增量/消息持久的过期时间/每秒读写峰值/每条消息大小/平均延迟/最大延迟/消费者线程池模型/哈希分片策略/消息的可靠投递/消费者处理流程和持久机制

压测工具

ab

jmeter

mysqlslap

sysbench

dd

hprof

技术评审提纲

现状

业务背景

项目名称

业务描述

技术背景

架构描述

当前系统容量

系统调用平均值，请求响应时间等

当前系统调用量的峰值，最小，最大请求响应时间

需求

业务需求

要改造的内容

要实现的新需求

性能需求

预估系统容量

预估系统调用量峰值，最小和最大值

方案描述

方案1

概述

一句话概括方案的亮点

详细说明
对方案的具体描述可结合图来说明
从如下几个方面进行说明

中间件架构

应用服务器

数据库

缓存

消息队列

逻辑架构

模块划分

模块通信

信息流

时序图

数据架构

数据结构

数据分布

拆分策略

缓存策略

读写分离策略

查询策略

数据一致性策略

异常处理
容灾策略
灰度发布
上线方案
回滚方案

性能评估

给出方案的基准数据，并按照性能需求评估需要使用的资源数量

单机并发量

单机容量

单机吞吐量的峰值

按照预估的性能需求，预估资源数量，服务器，缓存，存储，队列等

方案的优缺点

优点

缺点

方案2

同方案1类似

方案对比

风险评估

标识所选方案的风险，提出此风险发生时的应对策略。。。例如上线失败快速回滚等

工作量评估

列出具体工作的安排时间，评估开发，测试细化任务的时间，形成可实施的任务计划列表

要求一定可以量化，如果事情预估可能问题较多，需要做好buffer

监控告警

目标

提升线上问题感知能力

类型

系统监控

资源层

网络服务

DNS监控

线路监控

CDN监控

防火墙

负载均衡

服务器

CPU

cpu.busy.avg

内存

mem.memused.nocache.percent

磁盘

disk.used

网络

net.if.in.errors

磁盘IO

disk.io.util(%)

进程

sys.dmesg.oom

容器

实例异常

基础监控

JVM

内存

内存使用率

内存回收

YGC

每分钟GC次数

每次GC耗时P995

GC吞吐率

FGC

GC次数

GCP995

GC吞吐率

每分钟内存增长统计

堆内存使用率

方法区

线程监控

等待线程

阻塞线程

线程各种状态指标

线程总数

活跃线程数

Metaspace

代码

业务异常

系统异常

接入层

SLA可用性

NG域名统计

499 > 1S

5xx

200等

QPS

耗时

TP99/TP95/AVG

Nginx域名总耗时

Nginx后端耗时

网络

带宽流量

接口HTTP/RPC

异常

核心接口SLA

接口延迟

平均响应时间

响应时间

每分钟500个数

每分钟失败次数

服务依赖方

请求数监控

请求耗时TP99/TP95/AVG

异常情况

中间件

Tomcat

MQ

kafka

消费堆积报警Lag

消费失败告警

rocketMQ

消息堆积报警Lag

消费失败报警

Redis

容量使用率

分钟逐出个数

ES

mysql

连接数

慢查询

阻塞线程

数据量

磁盘占用

内存使用率

buffer

主从同步延迟

Threads Running

Innodb行锁等待

每秒磁盘中索引扫描行

每秒死锁次数

业务监控

数据监控

数据量

同比/环比

预警阈值

数据逻辑

数据计算是否正确

数据一致性

功能监控

用户量

页面访问时间

范围

现有监控

缺失监控

核心监控覆盖

谁关注监控

技术侧

产品侧

业务方