高并发
是一个容量的概念，服务可以接受的最大任务数量。根据二八定律（80/20定律）架构需要考虑那部分20%的突发流量，但并不是每个系统都是20%，需要根据特定样本数据分析
- 超时，重试，熔断，限流，双发，负载均衡，自动弹性伸缩
- 空间换时间（多级缓存架构-需考虑每层的命中率）
- 时间换空间 压缩（解决带宽问题）
- 异步
- 服务拆分+业务隔离
- 并行化
高性能
是一个速度的概念，单位时间内可以处理的任务数量
衡量的指标
响应时间RT（Response Time）
- 用户平均请求等待时间
我们最常用的指标，即平均响应时间(AVG)，该指标能够体现服务接口的平均处理能力。
服务器平均请求等待时间=所有请求数所花费的时间/总请求数
用户平均请求等待时间=服务器平均请求等待时间*并发数
除非服务在一段时间内出现了严重的问题，否则平均响应时间都会比较平缓。
因为高并发应用请求量都特别大，所以长尾请求的影响会被很快平均，
导致很多用户的请求变慢，但这不能体现在平均耗时指标中。
为了解决这个问题，另外一个比较常用的指标，就是百分位数。
- 百分位数
超过N%的请求都在X时间内返回。比如TP90=50ms，意思是超过90th的请求，都在50ms
内返回。我们一般分为 TP50、TP90、TP95、TP99、TP99.9等多个段，
对高百分位的值要求越高，对系统响应能力的稳定性要求越高，目标就是要干掉严重影响系统的长尾请求
并发数量
就是系统同时能处理多少用户请求；针对响应时间进行设计，一般来说是万能的。因为响应时间减少，同一时间能够处理的请求必然会增加。值得注意的是，即使是一个秒杀系统，经过层层过滤处理，最终到达某个节点的并发数，也会比较小
吞吐量
就是单位时间内系统处理的请求数量，是一个使用广泛的性能评价指标
- 从业务角度：吞吐量可以用请求数/s、页面数/s等来进行衡量计算
- 从网络角度：吞吐量可以用字节数/s来进行衡量计算
- 从应用角度：吞吐量指标反映的是服务器成熟的压力，即系统的负载能力 一个系统的吞吐量一般与一个请求处理对CPU的消耗、带宽的消耗、IO和内存资源的消耗情况等紧密相连。Throughput更关心数据量，系统的吞吐能力，QPS更关心每秒查询的数量
秒开率
通常而言，可以根据业务情况设定不同的页面打开标准，比如低于1 秒内的数据占比是秒开率。
- 名词解释
QPS（Queries Per Second）每秒查询的数量
TPS（Transactions Per Second 每秒事务的数量）
HPS（Http Per Second每秒的HTTP请求数量）
PV（Page View 页面浏览量）
DAU（日活）
QPS=并发数/用户平均请求等待时间
QPS=1/服务器平均请求处理时间
并发数=QPS*用户平均请求等待时间
A服务同时调用B服务+C服务，QPS=2，TPS=1
单个接口请求，单机，QPS = TPS。
Throughput = (number of requests) / (total time)
number of requests=总请求数
total time = 测试结束时间 - 测试开始时间
测试结束时间 = MAX(请求开始时间 + Elapsed Time)
测试开始时间 = MIN(请求开始时间)
一般情况下，我们认为：
响应速度是串行执行的优化，通过优化执行步骤解决问题；
吞吐量是并行执行的优化，通过合理利用计算资源达到目标。
我们平常的优化主要侧重于响应速度，因为一旦响应速度提升了，那么整个吞吐量自然也会跟着提升。
但对于高并发的互联网应用来说，响应速度和吞吐量两者都需要。
这些应用都会标榜为高吞吐、高并发的场景，用户对系统的延迟忍耐度很差，
我们需要使用有限的硬件资源，从中找到一个平衡点。
- 换算示例
ab -n100 -c10 http://localhost:11000/test/a #-n总请求次数 -c并发数
Document Path: /test/a
Document Length: 27 bytes
Concurrency Level: 10
Time taken for tests: 6.007 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 16600 bytes
HTML transferred: 2700 bytes
Requests per second: 16.65 [#/sec] (mean) #吞吐率，指某个并发用户数下单位时间内处理的请求数
Time per request: 600.674 [ms] (mean) #用户平均请求等待时间
Time per request: 60.067 [ms] (mean, across all concurrent requests) #服务器平均请求处理时间
Transfer rate: 2.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 503 517 41.8 508 918
Waiting: 502 514 35.2 507 849
Total: 503 517 41.8 508 918
Percentage of the requests served within a certain time (ms) #每秒请求时间分布情况
50% 508
66% 512
75% 516
80% 523
90% 533
95% 538
98% 546
99% 918
100% 918 (longest request)
服务器平均请求等待时间=所有请求数所花费的时间/总请求数=6.007/100=0.06007s
用户平均请求等待时间=服务器平均请求等待时间*并发数=0.06007s*10=0.6007s
QPS=并发数/用户平均请求等待时间=10/0.6007s=16.65个/s
QPS=1/服务器平均请求处理时间=1/0.06007s=16.65个/s
并发数=QPS*用户平均请求等待时间=16.65个/s*0.6007s=10
Throughput=(总请求数量)/(总时间)=100/6.007s=16.65个/s
高可用
衡量手段
7x24 小时无中断无异常的服务提供
| 描述 | N个9 | 可用性级别 | 年度停机时间 |
|---|---|---|---|
| 基本可用 | 2个9 | 99% | 87.6小时 |
| 较高可用 | 3个9 | 99.9% | 8.8小时 |
| 具备自动恢复能力可用 | 4个9 | 99.99% | 53分钟 |
| 极高可用 | 5个9 | 99.999% | 5分钟 |
优化手段
冗余（机器（混合云），服务（无状态）），解决单点问题，解决脑裂问题。
故障切换。冷，热备份
限流，降级，熔断，弹性设计
柔性化，兜底（获取通用商品不用个性化推荐，如果也没有可以读取一些静态文字进行展示，包容下一层的错误）
隔离（秒杀单独服务器）
应急预案，演练
自动化监控，告警（业务监控，硬件监控，服务监控（sql，调用次数，延迟，错误率），各个端监控，埋点监控）
同城多活(尽量同城，服务器延迟小)，异地多活，两地三中心
高安全
前端代码安全：
代码混淆，加入无关联代码，反调试
后端代码，服务器安全：
服务器等级保护，风控，黑白名单，反爬虫，waf防火墙（Ddos），加密, https HTTP2 http3 防刷、限量和防重，验证码，sql安全，社会工程学安全，地址隐藏
其它：
办公室电脑人员，电脑，邮件，聊天工具消息往来安全，开发工具，中间件，弱口令
常用优化手段及思想
尽早返回原则
第一段在用户和浏览器端，主要负责发出请求，及接受响应数据进行计算渲染显示给用户；
第二段在网络上，负责对请求数据、响应数据的传输；
第三段在网站服务器端，负责对请求数据进行处理（执行程序、访问数据库、文件等）并将结果返回
第一路径：
js，css压缩合并(varinish)，去除无用注释（基于安全考虑）
图片：有损格式用JPEG，无损格式用Webp格式
流媒体，静态资源走CDN，图片走适合大小
浏览器缓存，app缓存
第二路径：
带宽（即根据一次响应数据的大小，乘以PV数，除以对应的高峰时间段，从而大致估算出网站带宽的需求）
互联互通
第三路径：
代码最佳实践优化
业务流程最佳
异步，MQ
并行化，分而治之，无锁化编程，协程
文件静态化
应用层缓存，分布式缓存（多级缓存）
数据库优化（换商业数据库，分库分表，冷热数据分离，读写分离，NoSql-海量数据，NewSql，Hbase）
硬件升级（CPU、内存、带宽，SD磁盘阵列，服务器数量，机房，硬件负载）
高性能rpc框架，序列化框架
NIO，连接池化
高性能nginx，http2，http3,gzip/br以及参数优化
总结10年开发管理历程心得：
面向失败设计，架构师要把自己当成一个悲观主义者，
需要在一开始的系统设计阶段就考虑各种失败以及被外部攻击场景，
把面向失败当成系统设计的一部分，随时有Plan A,Plan B。
世界上解决一个计算机问题最简单的方法:“恰好”不需要解决它。
可以通过优化业务流程，合理的设计来规避问题。
冗余思维（大部分问题都可以通过加一个中间层解决）
分治思维（将一个大任务拆分成很多个小的任务来解决）
空间时间互换思维
并发思维
设计模式思维
池化思维
悲观主义思维
