高并发相关

Q：衡量高并发系统的指标

A：总用户量、活跃用户量、平峰和高峰时的QPS和TPS等关键数据。

Q：高并发系统设计的目标

A：宏观角度：高性能、高可用、高可扩展

1.高性能：性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。同时也反映了用户体验。

2.高可用：表示系统可以正常服务的时间。

3.高可扩展：表示系统的扩展能力，流量高峰时能否在短时间内完成扩容，更平稳地承接峰值流量。

微观角度：性能指标、可用性指标、可扩展性指标

1.性能指标：可以度量目前存在的性能问题，同时作为性能优化的评估依据。一般来说，会采用一段时间内的接口相应时间作为指标。

1.1 平均响应时间：最常用，但是缺陷很明显，对于慢请求不敏感。

1.2 TP90、TP99等分位值：将响应时间按照从小到大排序，TP90表示排在第90分位的响应时间，分位值越大，对慢请求越敏感。

1.3 吞吐量：和响应时间呈反比，比如响应时间是1ms，则吞吐量为每秒1000次。

通常，设定性能目标时会兼顾吞吐量和响应时间，比如这样表述：在每秒1万次请求下，AVG控制在50ms以下，TP99控制在100ms一下。对于高并发系统，AVG和TP分位值必须同时要考虑。

另外，从用户体验角度来看，200毫秒被认为是第一个分界点，用户感觉不到延迟，1秒是第二个分界点，用户能感受到延迟，但是可以接受。

因此，对于一个健康的高并发系统，TP99应该控制在200毫秒以内，TP999或者TP9999应该控制在1秒以内。

2.可用性指标：高可用性是指系统具有较高的无故障运行能力，可用性 = 正常运行时间 / 系统总运行时间，一般使用几个9来描述系统的可用性。

可用性	年故障时间	日故障时间
90%（1个9）	36.5天	2.4小时
99%（2个9）	3.65天	14.4分钟
99.9%（3个9）	8小时	1.44分钟
99.99%（4个9）	52分钟	8.6秒
99.999%（5个9）	5分钟	0.86秒

对于高并发系统来说，最基本的要求是：保证3个9或者4个9。

3.可扩展性指标：面对突发流量，不可能临时改造架构，最快的方式就是增加机器来线性提高系统的处理能力。

对于业务集群裸着基础组件来说，扩展性 = 性能提升比例 / 机器增加比例，理想的扩展能力是：资源增加几倍，性能提升几倍。通常来说，扩展能力要维持在70%以上。

但是从高并发系统的整体架构角度来看，扩展的目标不仅仅是服务设计成无状态就行了，因为当流量增加10倍，业务服务可以快速扩容10倍，但是数据库可能就成为了新的瓶颈。

像MySQL这种有状态的存储服务通常是扩展的技术难点，如果架构上没提前做好规划（垂直和水平拆分），就会涉及到大量数据的迁移。

因此，高扩展性需要考虑：服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依赖的第三方等，当并发达到某一个量级后，上述每个因素都可能成为扩展的瓶颈点。

高并发的实践方案

Q：通用的设计方法

A：1.纵向扩展：目标是提升单机的处理能力。

1.1 提升单机的硬件性能：通过增加内存、CPU核数、存储容量、或者将磁盘升级成SSD等堆硬件的方式来提升。

1.2 提升单机的软件性能：使用缓存减少IO次数，使用并发或者异步的方式增加吞吐量。

2.横向扩展：单机性能总会存在极限，所以最终还需要引入横向扩展，通过集群部署以进一步提高并发处理能力。

2.1 分层架构：这是横向扩展的前提，因为高并发系统往往业务复杂，通过分层处理可以简化复杂问题，更容易做到横向扩展。

2.2 各层进行水平扩展：无状态水平扩容，有状态做分片路由。业务集群通常能设计成无状态的，而数据库和缓存往往是有状态的，因此需要设计分区键做好存储分片，当然也可以通过主从同步、读写分离的方案提升读性能。

具体的实践方案

A：高性能、高可用、高扩展3个方面的可落地实践方案。

1.高性能的实践方案

1.1 集群部署，通过负载均衡减轻单机压力。

1.2 多级缓存，包括静态数据使用CDN，本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。

1.3 分库分表和索引优化，以及借助搜索引擎解决复杂查询问题。

1.4 考虑NoSQL数据库的使用，比如HBase、TiDB等，但是团队必须熟悉这些组件，且有较强的运维能力。

1.5 异步化，将次要流程通过多线程、MQ、甚至延时任务进行异步处理。

1.6 限流，需要先考虑业务是否允许限流（比如秒杀场景是允许的），包括前端限流、Nginx接入层的限流、服务端的限流。

1.7 对流量进行削峰填谷，通过MQ承接流量。

1.8 并发处理，通过多线程将串行逻辑并行化。

1.9 预计算，比如抢红包场景，可以提前计算好红包金额缓存起来，发红包时直接使用即可。

1.10 缓存预热，通过异步任务提前预热数据到本地缓存或者分布式缓存中。

1.11 减少IO次数，比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。

1.12 减少IO时的数据包大小，包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。

1.13 程序逻辑优化，比如将大概率阻断执行流程的判断逻辑前置、for循环的计算逻辑优化，或者采用更高效的算法。

1.14 各种池化技术的使用和池大小的设置，包括HTTP请求池、线程池（考虑CPU密集型还是IO密集型设置核心参数）、数据库和Redis连接池等。

1.15 JVM优化，包括新生代和老年代的大小、GC算法的选择等，尽可能减少GC频率和耗时。

1.16 锁选择，读多写少的场景用乐观锁，或者考虑通过分段锁的方式减少锁冲突。

上述方案无外乎从计算和IO两个维度考虑所有可能的优化点，需要有配套的监控系统实时了解当前的性能表现，并支撑你进行性能瓶颈分析，然后再遵循二八原则，抓主要矛盾进行优化。

2.高可用的实践方案

2.1 对等节点的故障转移，Nginx和服务治理框架均支持一个节点失败后访问另一个节点。

2.2 非对等节点的故障转移，通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。

2.3 接口层面的超时设置、重试策略和幂等设计。

2.4 降级处理：保证核心服务，牺牲非核心服务，必要时进行熔断，或者核心链路出问题时，有备选链路。

2.5 限流处理：对超过系统处理能力的请求直接拒绝或者返回错误码。

2.6 MQ场景的消息可靠性保证，包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。

2.7 灰度发布，能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。

2.8 监控报警：全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

2.9 灾备演练：类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。

高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。

3.高扩展的实践方案

3.1 合理的分层架构：比如互联网最常见的分层架构（用户层->反向代理层->web层->业务服务层->缓存层->存储层），另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（需要评估性能，会存在网络多一跳的情况）。

3.2 存储层的拆分：按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。

3.3 业务层的拆分：最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如 To C 和 To B、APP 和 H5）.

高并发设计需要秉承架构设计的3个原则：简单、合适和演进，过早的优化是万恶之源，不能脱离业务的实际情况，更不要过度设计，合适的方案就是最完美的。

参考链接：https://www.zhihu.com/question/421237964/answer/1795200233