架构思维第四篇

Posted 2022-01-20 hanruikai

什么是技术架构

系统架构 = 解决特定问题 + 要素 + 连接，结合这个公式，给技术架构下一个定义：技术架构 = 解决业务上的技术问题 + 技术方案 + 技术组件

高并发技术架构

 

本质问题

有限的资源处理大量的请求

系统性思考

根据我们的思维，我们可以大致从以下几个角度来思考：

• 资源能力强弱：之前资源处理能力弱，能不能变强呢？

• 资源少的问题：能不能增加资源呢？

• 请求多的问题：能不能减少请求呢？

• 处理速度：如果能处理得更快，处理的请求就会更多。

注意上面有一个词资源，这里的资源包含两个方面的含义：一是表示硬件资源，如机器节点数、内存大小等；二是业务资源，如秒杀场景下的商品数量。所以资源少的问题并不能简单地增加资源就能解决，秒杀就是那么少的商品数量。

应对方法

资源不足-水平扩展实例

资源能力弱-调优

请求多-排队、限流、错峰处理

处理速度：

一般的请求轨迹：前端访问 -> 前置逻辑判断 -> 业务处理 -> 数据存储 -> 结果响应返回。

这里有几个点：网络开销、CPU 处理、IO，把这几个耗时关键点降下来，整体效果就比较明显。

• 网络开销：能不能没有网络开销呢？有的，完全可以静态化放在 CDN 上，双 11 晚会承接页就是放在 CDN 上，只有实际变化的数据才会请求后端，其它的数据都是静态化的，处理速度非常快，当时的 QPS 达到 10W。有的不能完全没有网络开销，可以合并请求减少请求访问，能一次访问获取到结果的，不要再发一次请求，可以不发请求的就一定不要发请求。虽然每次请求就 10 几 ms，在量大的情况下，这就是压死骆驼的一根稻草。

• 前置判断逻辑：这个过程一般是查询，每次查询不管是访问 db 或者是文件，都会有 IO 消耗，如何避免呢？存在缓存中可以提高访问速度，访问速度快慢顺序：本地内存 > 远程缓存 > db，但要注意一点，如果使用到了缓存，一定要考虑缓存数据的一致性，一致性问题包括多级缓存和缓存和数据库中的一致性。

• CPU 处理：在业务处理过程中，包括了很多步骤，如果操作步骤没有依赖关系的，完全可以并行处理，最后通过 java 中的 Future 获取各个步骤的结果；还有一种是操作过程中并不是实时要处理的，如发通知等，完全可以异步执行，这样也能节省时间。

• IO 处理：IO 速度相对内存而言是慢的，IO 有两种情况，一是读，另一种是写，如果是读，自然想到通过缓存来提速，也可以把请求打散到不同的机器，如 mysql 的主从模式，可以从不同的从服务器上读数据；写数据的时候可以延迟写，在高并发的场景下，不要直接与 IO 打交道，可以放要处理的数据放在消息队列中再慢慢处理落地到数据库中。