随着互联网、移动互联网、物联网的普及，对于有一定规模的系统来说高并发设计是势在必行的，本文来总结一下高并发设计的目标，首先看一下高并发的定义。
高并发定义
高并发是指系统在单位时间内处理更多的用户并发请求，也就是承担更大的流量，它是一切系统架构设计的背景和前提。每秒一次请求和每秒一万次请求，两种场景下分别做到毫秒级响应和五个九（99.999%）的可用性，设计难度和复杂度都不是一个量级的。
高并发设计的目标
- 高性能
- 高可用
- 可扩展
一、如何提升性能
性能优化原则
- 性能问题不能盲从，一定是问题导向
- 遵循二八原则，用20%的精力解决80%的性能问题，抓住主要矛盾，优化主要瓶颈点
- 要有数据支撑，缩短了多少响应时间，提高了多少吞吐量
- 优化过程是持续的，明确目标，制定优化方案，持续不断地找到性能瓶颈，直到达到目标为止
性能度量指标
- 一般来说，度量性能的指标是指系统接口的响应时间，单次的响应时间是没有意义的，需要有一段时间内的特征值
- 平均值：敏感度比较差
- 最大值：过于敏感
- 分位值：把一段时间内响应时间从小到大排序，假如有100个请求，排在第90位的就是90分位值，排除偶发情况外，能很好地反映这段时间的性能情况，分位值越大对慢请求的影响越敏感
- 响应时间控制在多少比较合适
- 200ms是第一个分界点，200ms之内用户是感觉不到延迟的
- 1s是第二个分界点，1s之内用户能感受到一些延迟，还是接受的，超过1s之后用户有明显的等待，等待时间越长用户体验越差，所以健康系统响应时间的99分位值应该控制在200ms以内，不超过1s的请求占比要达到99.99%以上
性能优化思路
- 提高系统的处理核心数
多线程，增加系统的并行处理能力 - 缩短单次请求的响应时间
CPU密集型：选用更高效的算法或减少运算次数
IO密集型：大部分业务系统都属于IO密集型，比如数据库系统、缓存系统、Web系统，这些系统的瓶颈可能在内部也可能在依赖的其它系统，需要具体问题具体分析
二、怎样做到高可用
- 成熟系统的可用性需要从系统设计和系统运维两方面做保障，缺一不可
系统设计
- 无损方案
- 故障转移Faliover
- 有损方案
- 超时控制
不让请求一直保持，而是在经过一段时间后让请求失败，释放资源给接下的请求 - 降级
保证核心服务的稳定而牺牲非核心服务的做法 - 限流
对并发请求进行限速来保护系统
系统运维
- 灰度发布
按照一定比例逐步推到线上 - 故障演练
对系统进行一些破坏性的手段，观察出现故障时系统的表现，从而发现潜在的可用性问题。故障演练是以系统可以抵御一些异常为前提的，如果系统还没有做到这一点，需要另外搭建一套和线上一模一样的测试环境来演练，避免对生产系统造成影响。 - 混沌工程
在线上系统随机关闭节点来模拟故障，让工程师了解在出现此类问题时会有什么样的影响
DevOps
- Dev：冗余和取舍，冗余指的是有备用节点，集群来顶替出故障的服务，取舍指的是丢卒保车，保障主题服务安全
- Ops：注重如何避免故障的发生，关注变更管理以及如何做故障演练
三、如何让系统易于扩展
- 数据库、缓存、依赖的第三方、负载均衡、交换机带宽都是系统扩展时需要考虑的因素
高可扩展性的设计思路
- 拆分是提升系统扩展性最重要的一个思路
- 存储层的扩展性
- 存储拆分首先考虑业务维度
- 长时间运行后，单一业务数据库在容量和并发请求上会超过单机限制，此时可以对数据库做水平拆分（分库分表），不能随意增加节点，一旦增加节点需要手动迁移数据，成本很高，基于长远考虑需要一次性增加足够多的节点以避免频繁扩容
- 拆分后尽量不要用事物，分布式事物两阶段提交的协调成本会随着资源的扩展不断提高，最终达到无法承受的程度
- 业务层的扩展性
可以从三个维度考虑业务层的拆分方案：业务维度、重要性维度、请求来源维度
- 把相同业务的服务拆分成单独集群
- 根据业务接口的重要程度，把业务分为核心集群和非核心集群
- 根据接口调用方做不同业务集群的拆分
总结
高并发设计是为了使系统能应对大流量请求，设计方案需要考虑高性能、高可用、可扩展三个方面，优化之前需要有指标数据支撑，确立目标后，循序渐进，以解决系统中存在的问题为目标，持续优化系统实现。