高并发三要素
系统设计人员的首要责任和终极目标，我们需要考虑三个系统的核心要素分别是系统的性能、可用性和扩展性。
1、高性能
我们通常以吞吐量，响应时间来衡量一个系统的性能状况。
当我们的请求响应时间在200ms内对于用户来说是无感知的，在1s内还属于可接受范围，当超过1s用户体验就开始明天变差。
系统性能度量指标
- 平均响应时间
平均响应时间=时间段/处理的总请求量，一般来说平均时间的参考意义不大，因为平均时间往往会因为少数的慢请求而导致整个平均时间加大，就像我们的平均工资一样会因为几个富豪就拉高了整体的平均工资水平。 - 最大响应时间
一般只有系统严格的硬性标准要求最大响应时间为多少才会采用最大响应时间最为衡量系统性能的标准，而一般的系统都不会使用此方式。 - 分位响应时间
比如9分位的请求值是500ms 就是指系统90%的请求是在500ms内的，通常我们根据系统的要求不同而指定不同分位值的标准，一般要求比较高的系统都会要求在99分位值的请求控制在200ms内。
提升系统性能方式 - 提升机器配置
增加带宽让网络通道可允许更大数量的并发请求，增加CPU 可以提升并行处理任务的能力，增加内存可以增加读取数据量。 - 提升单次请求响应时间
CPU密集型功能或系统，可以通过算法进行优化。
IO密集型功能或系统，通过提升应用的IO速度来优化,比如基于存储介质从硬盘到内存的思路，我们可以使用缓存来优化数据检索，缓存又可以从应用缓存、第三方缓存、代理缓存、CDN缓存、客户端缓存着手。同时也基于IO模型优化，可根据系统选择阻塞、非阻塞、同步、异步的IO模型。 - 增加处理请求的节点
我们可以通过分流的方式采用集群、拆分术服务来增加可处理请求的应用，这样处理请求的机器增加了，系统单位时间内的吞吐量也会得到显著提升。
性能优化原则 - 契合业务：以问题为导向，和业务不能冲突。
- 避免过度优化：二八原则，用20%的精力解决80%的问题。
- 要有数据支撑：优化减少了多少时间，提升了多大的吞吐量。
2、高可用
系统的可用性是指系统无故障对外提供服务的时间。系统无法提供正常服务的时间越长就说明系统的可用性越低，通常系统的可用性分为下面几个级别：
保证系统高可用方式
- 故障转移
这种方式通常需要通过冗余节点来实现，通常表现方式为(对节点进行集群（比如应用集群、缓存集群、代理集群），或者对节点同步一个相同的副本（比如数据库主从备份）。
但也带来另外一个问题，非对等的节点之间的检测问题（比如数据库的主从、redis的集群），这些场景都有一个特性，会有一个master节点然后附带几个slave节点，master节点挂掉之后slave节点顶上来成为master节点提供服务,这个场景中就需要一套机制来监控master的存活状态然后实现自主选主的功能（比如心跳机制、一致性哈希算法）。 - 流量控制
根据自己的可承受范围，把那些不重要的、耗时长的请求直接拒绝。
超时控制：超时控制是为了避免耗时的请求一直持续，导致资源被耗尽，最后造成系统的不可用。
降级限流：降级是通过关闭一些系统的非主要流程，从而减少资源的损耗，限制流通过保证系统的可用性。
3、高扩展
系统的扩展性是系统能否应对系统业务发展的核心，互联网项目流向时刻可能面临着爆发式的增长，同时业务也随时会根据市场做出改变，系统在面对这些时候如何能做到处变不惊这就体现在我们系统的可扩展性上。
横向扩展
横向扩展的核心思路就是“加”，通过加节点的方式分摊流量，根据业务请求量来动态的添加或者删除节点对系统进行扩展，对应于系统中加节点的体现方式就是集群，通过集群来分摊流量是我们常见的方式。
数据库层面：数据库集群
缓存层面：缓存集群。
应用层面：应用集群。
纵向扩展
纵向扩展的核心思路就是“拆”，通过拆节点的方式来减少每个节点的流量或者数据量，同时通过拆的方式减少系统功能的耦合度，让其职责更加清晰单一增加功能的复用性，不仅从流量上提升扩展性，并且从业务需求的可扩展性上提供保障。
数据库层面：数据库分库分表。
缓存层面：缓存分片。
应用层面：应用代码分层、分模块、拆服务。