如何通过技术架构思维解决高并发问题？
高福来
讲述：丁婵大小：2.54M时长：05:32
高并发对于开发者来讲并不陌生，面对高并发的问题，有什么解决之道呢？滴滴小桔车服营销基础负责人高福来认为可以通过技术架构的思维来解决这个实际场景问题，也就是技术架构 = 解决业务上的技术问题 + 技术方案 + 技术组件 。以下是他的观点。
高并发的本质问题是有限的资源应对大量的请求，根据技术架构的思维来解决这个问题，大致可以从以下四个角度来思考：
资源能力强弱：之前资源处理能力弱，能不能变强呢？
资源少的问题：能不能增加资源呢？
请求多的问题：能不能减少请求呢？
处理速度：如果能处理得更快，处理的请求就会更多。
注意这里有一个词“资源”，它包含两个方面的含义：一是表示硬件资源，如机器节点数、内存大小等；二是业务资源，如秒杀场景下的商品数量。所以资源少的问题并不是能用增加资源就解决的，秒杀的商品数量本来就是有限的。
假设我们的场景就是大用户量访问，但不是秒杀场景。接下来就从上面提到的四个角度来一一分析。
1. 资源能力强弱
有一种最简单的方法是提升资源能力，就是提升机器的性能，但有一定的成本。比如 MySQL 数据存储在机械硬盘上和存储在固态硬盘上，处理速度有很大区别。在不优化任何代码的情况下，后者性能提高一倍。当然这里必须指明的是业务上存在的大量 IO 读写，所以换成固态硬盘能起到立竿见影的效果。
2. 资源少的问题
因为本文的例子不是秒杀场景，所以我们可以通过增加机器节点来应对，假如有 1w 个请求，一台机器处理 100 个请求，那么 100 台机器搞定，如果只有 10 台机器，那一台机器就要处理 1000 个请求，这种方法叫机器水平扩展。
当然要做到水平扩展，必须是无状态的。 无状态简单理解就是请求之间没有记忆功能，但有时一个请求又涉及到多个操作，如下单、库存、支付等，用户信息肯定要携带，如何做到无状态呢？常见有几种做法：
stick 粘滞：对同一个用户请求转发到同一台机器上
集中式存储：如 session 共享就集中存储在一个集群上，每台机器去集群上 get 信息就行
token：相比集中式存储，token 就显得比较轻巧，它是不需要额外的存储，利用的是加密、解密的思想，在请求中就携带了相关信息，所以就不需要再去查了。
3. 请求多的问题
既然请求过多，怎么做到请求少呢？一般有几个思路处理：一是错峰处理，避免集中请求；二是排队，整体集群的能力是一定的，所有的请求先入队列，集群从队列中取请求就行；三是限流，这是稳定性常用的手段。
4. 处理速度
一般的请求轨迹：前端访问 -> 前置逻辑判断 -> 业务处理 -> 数据存储 -> 结果响应返回。其中前置逻辑判断、CPU 处理、IO 是耗时关键点，把这几个点降下来，整体速度就会明显提升。
其一，前置判断逻辑：这个过程一般是查询，每次查询不管是访问 db 或者是文件，都会有 IO 消耗，如何避免呢？存在缓存中可以提高访问速度。访问速度快慢顺序为：本地内存 > 远程缓存 > db，但要注意一点，如果使用到了缓存，一定要考虑缓存数据的一致性，一致性问题包括多级缓存和数据库中的一致性。
其二，CPU 处理：在业务处理过程中，包括了很多步骤，如果操作步骤没有依赖关系的，完全可以并行处理，最后通过 Java 中的 Future 获取各个步骤的结果；还有一种是操作过程中并不是实时要处理的，如发通知等，完全可以异步执行，这样也能节省时间。
其三，IO 处理： IO 速度相对内存而言是慢的，IO 有两种情况，一是读，另一种是写。如果是读，自然想到通过缓存来提速，也可以把请求打散到不同的机器，如 MySQL 的主从模式，可以从不同的从服务器上读数据；写数据的时候可以延迟写，在高并发的场景下，不要直接与 IO 打交道，可以放要处理的数据放在消息队列中再慢慢处理落地到数据库中。
通过上面的分析可以看出，我们在应对高并发时可以从多个不同的角度来考虑，只要思路打开了就会形成系统性的解决方案。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
冰心有道理
收起评论