互联网高并发设计手段

高并发设计主要关注的是系统性能，包括两个部分，1是吞吐量，2是响应延迟。

性能优化目标：

1. 缩短响应延迟
2. 提高并发数(吞吐量)
3. 让系统处于合理状态

并发数、QPS、平均响应时间三者之间关系

 

从上图可以看出，

一开始，随着并发数的增加，资源利用率，吞吐量都是线性增长，逐渐达到一个峰值，响应时间变化不大
随着并发数继续增加，资源逐渐耗尽，没有资源可以再分配，服务器响应时间开始增加，甚至没有响应，吞吐量开始下降

优化手段

1 系统时间是瓶颈 ，利用空间换时间
比如，缓存复用计算结果，降低时间开销，因为时间较内存容量更加昂贵

2 系统大小是瓶颈，利用时间换空间
比如，网络传输是瓶颈，增减系统时间换取传输的空间，使用http的gzip压缩算法。
比如，app的请求分类接口，使用版本号判断哪些数据更新，只下载更新的数据

3 找到系统瓶颈
分析系统业务流程，找到关键路径并分解优化
比如，一个服务集群4w的QPS，调用量前5的接口贡献了3.5w的QPS，对关键路径的代码优化收益最大，当然系统剩下的部分也不能忽视，比如剩下5k的QPS的接口若性能有问题也可能把整体服务性能拖垮优化层次 从整体到细节
1 架构设计层次
关注系统控制，数据流程;
如何拆分系统，如何是各部分系统整体负载更加均衡，充分发挥硬件设施性能优势，减少系统内部开销等;
a)分布式系统微服务化
b)分库分表，读写分离，数据分片
c)无状态化设计，动态水平弹性扩展
d)调用链路梳理，热点数据尽量靠近用户
e)分布式cache，多级多类型缓存
f)容量规划
g)提前拒绝，保证柔性可用

2 算法逻辑层次
关注算法选择是否高效，算法逻辑优化，空间时间优化任务并行处理，使用无锁数据结构等;
a)增量式算法，复用之前的计算结果，比如一个报表服务，要从全量数据中生成报表数据量很大，但是每次增量数据较少，则可以考虑只计算增量数据和之前计算结果合并
b)并发和锁的优化，读多写少的业务场景，基于CAS的lockFree比mutex性能更好        
c)空间换时间;ThreadLocal
d)时间换空间;采用压缩算法，更复杂的逻辑减少数据传输
e)并行执行，比如一段逻辑调用多个rpc接口，而这些接口之间并没有数据依赖，则可以考虑并行调用，降低响应时间
f)异步执行，分析业务流程中的主次流程，把次要流程拆分出来异步执行，更进一步可以拆分到单独的模块去执行，比如使用消息队列，彻底和核心业务流程解耦，提高核心流程的稳定性以及降低响应时间

3 优化代码层次
关注代码细节优化，代码实现是否合理，是否创建了过多对象，循环遍历是否高效，cache使用是否合理，是否重用计算结构等
a)循环遍历是否合理高效，不要在循环里调rpc接口，查询分布式缓存，执行sql等，应该先调批量接口组装好数据，再循环处理
b)代码逻辑避免生成过多对象或无效对象
c)ArrayList，HashMap初始容量设置是否合理，注意扩容代价
d)对数据对象是否合理重用，比如通过rpc查到的数据能复用则必须复用
e)根据数据访问特性选择合适数据结构，比如读多写少，考虑CopyOnWriteArrayList(写时Copy副本)
f)拼接字符串的时候使用String相加还是使用StringBuilder进行append(在StringBuilder的容量预分配的情况下，StringBuilder的性能比String相加高15倍左右)
g)是否正确初始化数据，有些全局共享的数据，饿汉模式，在用户访问前先初始化好

4 数据库代码层次
a)数据库建表语句能尽量小的数据结构，比如表示状态的字段，如状态值在255以内使用unsigned tinyint，IP使用int而非varchar
b)避免使用select *查询数据，只查询需要的字段，避免浪费数据IO，内存，cpu，网络传输
c)分析查询场景建立合适的索引，分析字段的可选择性，索引长度，对长的varchar使用前缀索引
d)字段尽量为not null类型，，mysql手册说明允许null的字段需要额外的存储空间去处理NULL，并且很难查询优化

案例 电商秒杀系统

特点：
a)大量并发，在某一刻99%的用户涌入
b)有效请求数很低，可以认为有效请求和库存一致，可能99%以上的流量都是无效的
c)库存数据一致性要求严格，不能超卖

架构思路
a)数据分层次校验，上层尽量把无效请求过滤掉
b)上层可以是不精确的过滤
c)层层限流，最后一层做一致性校验，扣减库存

架构设计
a)HTML，JS，CSS等静态文件存放CDN，缓存到用户端(APP，浏览器)
b)非实时动态数据(秒杀期间如商品标题，商品描述，图片URL列表,店铺信息，秒杀活动等)，这些数据缓存在用户访问链路中靠近用户的位置，粗过滤一部分流量，比如用户是否有秒杀资格，秒杀是否已结束等，这些数据实时性要求不高
c)实时数据如用户营销数据(如红包，折扣)，商品库存等再过滤一批用户
d)经过多层过滤，最终落到数据库的流量已经很少，最终再数据库层面使用事务保证扣减库存准确性

 

（新建的群1039047324，欢迎对技术感兴趣的朋友加入，群内可以接私活，聊技术，分享工作中容易踩的坑，以及如何避免踩坑，分享最新架构视频)