1、高可用的设计
单点故障
集群(负载均衡技术)
硬件负载:F5, Netscalar
软件负载:apach, nginx, lvs, Haproxy
负载均衡算法: 随机、hash、轮询、最小连接数
2、热备
zookeeper / redis-sentinel / etcd
Zad(paxos) Raft 算法/ Raft(etcd、nacos、redis-sentine) / gossip
3、多机房部署
同城,异地
跨机房的状态同步
应用的可用性
微服务集群部署
4、容错性
fail fast
Java集合(Collection)中的一种错误机制。当多个线程对同一个集合的内容进行操作时,就可能会产生fail-fast事件。例如:当某一个线程A通过iterator去遍历某集合的过程中,若该集合的 内容被其他线程所改变了;那么线程A访问集合时,就会抛出ConcurrentModificationException异常,产生fail-fast事件。
服务隔离
代码容错处理
5、接口的设计
数据的严谨性,数据的校验
幂等性,事物处理(添加数据)
6、自我保护能力
10000 tps --> 20000 tps
【熔断(降级)、限流(降级)、缓存、主动降级】
7、监控
系统只有的监控(CPU、内存、磁盘)
应用层面的分析
log4j-->系统的执行情况:ELK --> 错误码设计
告警
发邮件、短信、电话通知 | AlertManager
应用监控:应用吞吐量、访问量(卖点,数据上报)、cat 、链路监控【A->B->C->D】zipkin / sleum /pinpoint
系统资源:Metrics / InfluxDB / Grafana / Prometheus /
8、高并发(单位时间内能够同时处理的请求数量)
RT(Response Time) 响应时间
Throughput(吞吐量):单位时间请求数量
QPS (TPS): 每秒你响应的请求数量 【并发数 / 平均响应时间】 --> jemeter 压力测试 | abtest 灰度发布
并发数(用户)
9、用户体验 --> 响应时间
瀑布流设计
支付-->第三方
对接多个支付渠道--> 支付路由(针对于限额、针对分流...)
异步化
10、架构层面
微服务--> 服务拆分 | 性能瓶颈、计算资源 (阿里去IOE)
多节点组成一个超级计算机
SLA --> 针对核心服务提供更大规模的集群
数据库层面
数据分片(分库分表)
读写分离(读库,写库)
存储层面
机构化存储
非机构化存储
服务的无状态设计(堆机器提升性能的方式):集群多台机器 session 共享问题
分布式缓存(热点数据做缓存)--> 设计目的就是为了抗高并发
容量规划 (什么时候应该加机器? 当前的吞吐量是多少?如果要承载多少容量,需要增加多少机器? )
常用名称(PV: Page view | UV : User view)
线上压测 某一个集群 或者某一个节点, 来得到一个临界值
目标: 最大的复制状态(服务器级别的),CUP的使用率、 内存的使用率、磁盘IO延时
最大能够接受的请求阀值(QPS, TPS, ART, 错误率)
指标的收集: 压力测试(生产线上的压测)--> 等到更加精准的数据
趋势预测:往年的数据,今年的数据增长做预判
异步化架构 -> 异步队列:实时性要求不是很高的场景
冗余: 增加副本
CDN 内容分发网络
11、代码层面
不要在循环里面调用RPC
HashMap --> 初始化大小是16, 而实际存储数据预计 100 ~ 100W, 会导致不断扩容
数据的预热设计: 线程池
数据库层面: 查询语句的优化 (EXPLAIN :sql)
异步化(线程池的使用)
内存的使用
12、中间件层面的优化
配置 --> NIO --> AIO
13、客户端层面的优化
减少请求数量 --> 合并请求
缓存数据
14、存储层面的优化
硬件层面: 磁盘读写,顺序读写
缓存
15、服务的无状态化
扩容(水平扩容)
session 回话 --> redis
数据的存储 -> A节点上存储 --> 第三方节点存储
对象存储 -->A节点上存储 --> 第三方节点存储
缓存 --> A节点上存储 --> 第三方节点存储
16、服务负载均衡
集群的好处: 流量分发、 扩容和缩容
负载均衡
DNS 轮询 :
二层负载 (Mac地址)
三层负载(IP负载)
四层负载(IP负载 + port) --> nginx
upstream {
ip:port
}
七层负载(应用层负载,http协议中的东西,根据请求中的URI惊喜负载)
location * URI
nginx / Apache
17、应用层负载
实现负载均衡的组件: Ribbon 、 Gateway\Dubbo(负载) 、Spring Cloud LoadBalancer
18、服务的幂等性
解释: 多次请求对于数据的变化和一次请求带来的数据变化,保持一致
幂等性: get 操作是天然的幂等
非幂等性: update 跟新余额,每次扣 -10块,如果调用 10次,口粗100 快
状态机的幂等:一个数据在整个生命周期中锁经历的状态
数据库的位置约束:
Token
同一个用户的请求被发起多次请求,(服务调用者的重试、Mq的重试). 数据的影响只产生一次,基于服务调用者的重试
19、锁
synchronized, lock 解决单进程多线程的问题
跨进程的范文
分布式锁
etcd
zookeeper
数据库
redis
无锁化的设计【CAP -> CP、AP】--> 考虑场景考虑, 具体场景具体分析
C:一致性
A:可用性
P:分区容错性