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 、 GatewayDubbo(负载) 、Spring Cloud LoadBalancer
18、服务的幂等性
解释： 多次请求对于数据的变化和一次请求带来的数据变化，保持一致
幂等性： get 操作是天然的幂等
非幂等性： update 跟新余额，每次扣 -10块，如果调用 10次，口粗100 快
状态机的幂等：一个数据在整个生命周期中锁经历的状态
数据库的位置约束：
Token
同一个用户的请求被发起多次请求,（服务调用者的重试、Mq的重试）. 数据的影响只产生一次，基于服务调用者的重试
19、锁
synchronized, lock 解决单进程多线程的问题
跨进程的范文
分布式锁
etcd
zookeeper
数据库
redis
无锁化的设计【CAP -> CP、AP】--> 考虑场景考虑, 具体场景具体分析
C：一致性
A：可用性
P：分区容错性