性能优化方法论系列三性能优化的核心思想

Posted 2022-07-12 明明如月学长

3.4 其他

3.4.1 随机读写转顺序读写

随机 IO 读写速度和顺序 IO 读写速度差距较大。

因此有可能的话，尽量将随机读写转为顺序读写。

3.4.2 就近原则

前面讲到使用缓存达到空间换时间的效果。

但有时候还可以采用 “就近原则” ，使用“更近”的数据，调用“更近”的服务。

一般来说，同一个虚拟机 > 同一台服务器 > 同一个集群 > 同一个机房 > 同一个城市 > 同国其他城市 > 跨国。

Dubbo 从 2.2.0 开始，每个服务默认都会在本地暴露。在引用服务的时候，默认优先引用本地服务。如果希望引用远程服务可以使用一下配置强制引用远程服务^[8]。 本质上也是采用 “就近原则”，优先调用本地服务，从而减少不必要的网络 时。

3.4.3 选择合适的数据结构和算法

不同数据结构有各自的优势和劣势，有各自的适用场景。

如去重，尤其是数据量较大时，可以利用 Set 的元素唯一性的特性，快速对一个集合进行去重操作，避免使用 List 的 contains 方法进行遍历、对比、去重。

有些场景下可以使用 BitSet 、Bag 等数据结构性能会更好。

再比如 HashMap 在哈希冲突时先拉链，冲突超过 8 个转为红黑树。当冲突较严重时，红黑树的性能显然比链表更高，这其实就是根据情况结合不同的数据结构的优势实现性能优化的典型案例。

大家都知道不同算法的时间复杂度不同，不同算法的耗时有巨大的差异，在实际开发中涉及到算法部分一定要注意时间复杂度问题。

在工作中就遇到过有人用 List 去重，当数据量较大时，很容易超时。

有些场景下可以选择使用布隆过滤器等算法优化性能。

3.4.4 加限制条件（技术层面）

此外，添加一些限制条件也是性能优化的重要思想。

以 Redis 的动态字符串为例。

其内部实现思想和 Java 中的 ArrayList 非常相似，采用预先分配冗余空间的方式来减少内存的频繁分配。

不同的是，当字符串小于 1 M 时，扩容一倍；如果超过 1M ，每次扩容 1M 的空间，最大长度为 512 M。

这里的最大长度限制就是为了保证不因单个 key 不至于过大，导致慢查询。

3.4.5 CPU 密集型和 IO 密集型

对于 CPU 密集型任务，可以通过增加机器和提高机器配置，使用大数据框架，升级架构等方式来解决。

对于 IO 密集型操作，可以侧重考虑通过并行、异步、合并、预处理等方法进行性能优化。

3.4.6 根据技术特点去优化

具体到某个技术都有会辅助性能优化的命令或工具，需要大家自己去掌握。

不同的工具性能优化也有自己的特点，如 mysql 设计好索引、HBase 设计好 rowkey 规则等，需要针对性地学习。

如 MySQL 可以使用 explain 指令分析语句性能进行分析。

如 HBase rowkey 的设计可以参考阿里云数据库 HBase 开发指南中的一些建议。

还有很多技术需要通过调整参数来优化，这些也需要通过官方文档、相关的权威图书、相关的技术专栏等针对性优化。

3.4.7 全链路优化

很多时候性能优化不能只把眼光局限于当前系统，需要考虑全链路，考虑前端和后端，当前系统和下游系统等。

有些性能优化问题，需要前端和后端通力合作，一起改进。

比如前端在某个页面执行了一些没有必要的调用；前端加载的资源速度过慢，可以考虑合并资源或者使用 CDN 加速等。

有些性能优化问题，需要后端和其下游通力合作，一起改进。

如果下游只提供某个功能的单个接口，而我们有批量执行的诉求，可能需要推动下游提供批量接口。

如果下游接口有性能问题，可能还需要推动下游进行优化。

3.4.8 多种手段相结合

不同的数据结构和算法、不同中间件、不同的框架和架构，都有最适合的使用场景，都有各自的优势和劣势。在实践中，往往需要多种性能优化思想结合在一起来解决问题。

如某个业务将 MySQL 、 Redis 和 Es 多种存储方式结合一起使用，发挥各自的优势；如从技术层面和产品层面相结合进行优化。

在实际进行性能优化时要结合具体的场景，进行权衡之后做出选择。

比如有些数据可以存到 MySQL 表中，有些热点数据或大文本可以存到缓存中，需要进行模糊搜索的条件可以放到搜索引擎中。

比如在设计某个功能时，需要多表联查，此时可以通过在一个表中冗余另外一个表的字段来避免联查操作；还可以通过 ES 等技术做一个大宽表来避免 DB 层多表联查，来提高性能。

比如将单库改成读写分离架构，或者改成分库分表架构，将单体应用拆分成多个微服务等。

3.5 产品层面

不是所有的性能优化都是要通过技术手段来实现，如果技术手段不容易解决，可以考虑从产品设计层面来实现。

3.5.1 加限制条件

如果从技术层面性能优化不好做，可以和产品协商，让产品做出一些妥协，加上一些限制条件，很多问题就迎刃而解

比如产品层面可以限制用户上传的图片、文件大小，限制录入的文本大小等。

比如提供不同的版本，默认选择性能较好的版本。如视频网站提供不同的清晰度，默认展示普通清晰度的视频或者根据用户网速选择最优的清晰度。

还可以和产品同学进行交流，砍掉某些不合理的搜索条件等来获得更好的性能体验。

如微信发送图片时，即使发送时你选择原图，对方接收到的一般都是预览图，只有打开后选择“下载原图”，才会真正去下载原图到本地。

此外，微信对视频或其他类型的文件传输也有大小的限制。

这些都是通过加限制条件来辅助性能优化在产品层面的体现。

3.5.2 砍需求

优秀的开发也要有一些产品思维，要懂得权衡某些设计的利弊，权衡投入产出比等。

可能下面这句话不是很“正能量”，但的确是解决问题的一个思路，哈哈。

当有些产品提出一些不太合理的奇葩需求，而且这种需求容易投入产出比不高，从技术层面不好解决而且对用户的价值并不是很大时，可以考虑说服产品砍掉需求。

---

创作不易，如果本文对你有帮助，欢迎点赞、收藏加关注，你的支持和鼓励，是我创作的最大动力。