软件开发的三高指标：高并发、高性能、高可用。
高并发方面要求QPS 大于 10万；高性能方面要求请求延迟小于 100 ms；高可用方面要高于 99.99%
一、高并发：
高并发是现在互联网分布式框架设计必须要考虑的因素之一，它是可以保证系统能同时并发处理很多请求，对于高并发来说，它的指标有：
1、响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间
2、吞吐量：吞吐量指每秒能处理多少请求数量
3、每秒查询率（QPS，Queries Per Second）：每秒响应请求数，和吞吐量差不多
4、并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数
提高QPS的架构策略
Redis、MQ、多线程
负载均衡：
高并发首选方案就是集群化部署，一台服务器承载的QPS有限，多台服务器叠加效果就会有明显提升。
集群化部署，就需要考虑如何将流量转发到服务器集群，这里就需要用到负载均衡，如LVS（Linux Virtual Server）和nginx。
常用的负载均衡算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法等。
业务实战：对于千万级流量的秒杀业务，一台LVS扛不住流量洪峰，通常需要 10 台左右，其上面用DDNS（Dynamic DNS）做域名解析负载均衡。搭配高性能网卡，单台LVS能够提供百万以上并发能力。
注意， LVS 负责网络四层协议转发，无法按 HTTP 协议中的请求路径做负载均衡，所以还需要 Nginx
池化技术：
复用单个连接无法承载高并发，如果每次请求都新建连接、关闭连接，考虑到TCP的三次握手、四次挥手，需要花费大量开销。
池化技术的核心是资源的“预分配”和“循环利用”，常用的池化技术有线程池、连接池、进程池、对象池、内存池、协程池。
连接池的几个重要参数：最小连接数、空闲连接数、最大连接数
流量漏斗（风控拦截）：
以上的几种方式是正向方式提升系统QPS，我们也可以逆向思维，做减法，拦截非法请求，将核心能力留给正常业务请求。
互联网高并发流量并不都是纯净的，也有很多恶意流量（比如黑客攻击、恶意爬虫、黄牛、秒杀器等），我们需要设计流量拦截器，将哪些非法的、无资格的、低优先级的流量过滤掉（风控掉），减轻系统的并发压力。
拦截器分层:
网关和 WAF（Web Application Firewall，Web 应用防火墙）
采用封禁攻击者来源 IP、拒绝带有非法参数的请求、按来源 IP 限流、按用户 ID 限流等方法
风控分析。借助大数据能力分析订单等历史业务数据，对同ip多个账号下单、或者下单后支付时间过快等行为有效识别，并给账号打标记，提供给业务团队使用
下游的每个tomcat实例应用本地内存缓存化，将一些库存存储在本地一份，做前置校验。当然，为了尽量保持数据的一致性，有定时任务，从 Redis 中定时拉取最新的库存数据，并更新到本地内存缓存中
二、高性能：
高性能指程序处理速度非常快，所占内存少，且CPU占用率低。高性能的指标经常和高并发的指标紧密相关，想要提升性能，那么就要提高系统并发能力，两者互相捆绑在一起。
有哪些因素会影响系统的性能？
业务代码的逻辑设计，算法实现是否高效、架构设计
业务系统CPU、内存、磁盘等性能
下游系统的性能
业务链路的长度
请求/响应数据包大小
用户网络环境
怎么样提高性能呢？
1、避免因为IO阻塞让CPU闲置，导致CPU的浪费。
当系统处理大量磁盘IO操作的时候，由于CPU和内存的速度远高于磁盘，可能导致CPU耗费太多时间等待磁盘返回处理的结果。对于这部分在IO上的开销，称为"iowait"。
磁盘有个性能指标：IOPS，即每秒读写次数，性能较好的固态硬盘，IOPS 大概在 3 万左右。对于秒杀系统，如果单节点QPS在10万，每次请求产生3条日志，那么日志的写入QPS在 30W/s，磁盘根本扛不住
Linux 有一种特殊的文件系统：tmpfs（临时文件系统），它是一种基于内存的文件系统，由操作系统管理。当我们写磁盘的时候实际是写到内存中，当日志文件达到我们的设置阈值，操作系统会将日志写到磁盘中，并将tmpfs中的日志文件删除
这种批量化、顺序写，大大提升了磁盘的吞吐性能！
2、避免多线程间增加锁来保证同步，导致并行系统串行化
3、避免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上
4、高性能缓存，如Redis。
对热点数据从缓存中读取来提升热点数据的访问性能，避免热点数据每次都从数据库中读取，给数据库带来压力
三、高可用：
可用性：指一个系统处在可用工作状态的时间的比例
高可用：让系统趋近于100%的高度可用
具体衡量指标：
MTBF（Mean Time Between Failure）：平均故障间隔时间，即系统可用时长
MTTR（Mean Time To Repair）：系统从故障到恢复正常所耗费的时间
SLA（Service-Level Agreement）：服务等级协议，用于评估服务可用性等级。计算公式是 MTBF/(MTBF+MTTR)
我们常说的可用性高于99.99%（4个9），是指指标SLA高于99.99%。
技术架构，高可用有哪些策略：
多云架构、异地多活、异地备份
主备切换：如Redis缓存、MySQL数据库，主备节点会实时数据同步、备份。如果主节点不可用，自动切换到备用节点
微服务，无状态化架构、业务集群化部署，有心跳检测，能最短时间检测到不可用的服务
通过熔断、限流，解决流量过载问题，提供过载保护
重视web安全，解决攻击和XSS问题
1、主备切换、缩短故障时间
当系统出现故障时，首要任务不是立马查找原因，考虑到故障的复杂性，定位排查要花些时间，等问题修复好，SLA也降了好几个档。更好的解决方案就是：故障转移
故障转移：当发现故障节点的时候，不是尝试修复它，而是立即把它隔离，同时将流量转移到正常节点上。这样通过故障转移，不仅减少了MTTR提升了SLA，还为修复故障节点赢得了足够的时间。
主备切换大致分为三步：
1）故障自动侦测（auto-detect），采用健康检查，心跳等手段自动侦测故障节点
2）自动转移（failover），当侦测到故障节点后，采用摘除流量、脱离集群等方式隔离故障节点，将流量转移到正常节点
3）自动恢复（failback），当故障节点恢复正常后，自动将其加入集群中，确保集群资源与故障前一致
2、熔断，提供过载保护
所谓过载保护，是指负载超过系统的承载能力时，系统会自动采取保护措施，确保自身不被压垮。
熔断就是在系统濒临崩溃的时候，立即中断服务，从而保障系统稳定避免崩溃。它类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾
例子：熔断触发条件往往跟系统节点的承载能力和服务质量有关，比如 CPU 的使用率超过 90%，请求错误率超过 5%，请求延迟超过 500ms， 它们中的任意一个满足条件就会出现熔断。
3、限流，提供过载保护
限流的原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。但是又有所区别，熔断触发过载保护，该节点会暂停服务，直到恢复。限流，则是只处理自己能力范围之内的请求，超量的请求会被限流
限流算法主要有：计数器限流、滑动窗口限流、令牌桶限流、漏桶限流
4、降级
比如电商大促，业务在峰值时刻，系统抵挡不住全部的流量时，系统的负载、CPU 的使用率都超过了预警水位，可以对一些非核心的功能进行降级，降低系统压力，比如把商品评价、成交记录等功能临时关掉。弃车保帅，保证 创建订单、支付 等核心功能的正常使用
总结下来：降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。
高可用设计理论：
CAP：Consistency、Availability、Partition tolerance，此理论人尽皆知，最终会在CP和AP中权衡，找到满足BASE（Basically Available、Soft state、Eventually consistent）的平衡结果
高可用设计要素：
冗余：确保对系统操作至关重要的任何元素都有一个额外的冗余组件，这些组件可以在发生故障时接管。
监控：从正在运行的系统中收集数据，并检测组件何时发生故障或停止响应。
故障转移：一种手动或自动机制。如果监控显示活动组件发生故障，该机制可以从当前活动的组件切换到冗余组件。
上述三要素逻辑也很清晰：要实现高可用，不管是否存在状态，要先有冗余或备份；当真正出现故障的时候，要有监控手段监控到故障发生；故障发生后，可以通过故障转移组件快速转移到之前的冗余组件中，保证服务不中断。
高可用方案设计需要从哪些角度讨论和思考？
首先，应用侧、支撑侧、运维侧的设计方式方法不同。
应用侧高可用除了可以通过上述提到的冗余、集群、负载均衡等做到快速的故障转移，还包括熔断、限流、容错、降级、应急等保障手段，框架组件的超时及重试策略、异步调用、幂等性设计来补充。
支撑侧（或称基础设施平台）需要一整套高可用相关的监控指标，满足故障的提前预警、快速报警、可视化监控和分析。常见指标包括请求量、请求错误率、平均延时、HTTP状态，以及系统资源消耗相关指标等。
运维侧中关键一点是DevOps，自动化发布、灰度发布、优雅发布、版本控制、健康检查等能力，可以在业务发生故障前和发生故障时，帮助应用最大程度减小服务不可用时长。
END.