【鱼皮的打工日记】20220627

今天是全面复工第一天，也是近乎完美的一天！非常开心~

首先是之前反反复复改了两周的需求终于验证 OK 了。这个需求虽然早都做完了，但因为种种原因，总是有一点小 Bug 需要调来调去，一直卡在我的待完成需求中。工作之后最怕这种验证周期比较长的需求，当你以为完成的时候产品突然发现了问题，那你又要边做新需求边处理这些历史包袱。

其次是在产品的帮助下，口遁掉了一个新需求。本来我都排好时间准备去开发新需求了，但是今天跟产品讨论过后，发现其实不用开发新功能，让用户使用系统的现有功能也能满足需求（就是对用户来说稍微麻烦一点），于是我就省事儿了。因为最近产品同事也很忙，所以现在产品和我终于站到了同一艘船上，轻松了很多~

于是，我今天也终于有空去落实一下我之前想到的系统优化方案了，花了几个小时，把几个接口的平均响应时间缩短了 2 - 4 倍。这里简单分享几种我用到的后端接口的优化方式：

1. 减少重复的数据库查询。比如接口处理过程中调用了方法 A 和方法 B，在方法 A 中已经查出用户 1 了，那么在方法 B 中就不用再查一遍用户 1，而是可以把已经查询出的用户 1 作为参数传递给方法 B，或者在 ThreadLocal 中临时缓存一下。
2. 并发处理。比如有 2 个数据库查询 A 和 B，分别耗时 3 秒。如果同步执行，先查完 A 再查 B，要花 6 秒；但如果让两个查询并发执行，3 秒钟就能处理完。
3. 非核心操作异步化。比如接口处理结束前需要往数据库中插入一条操作记录，这个步骤是非核心操作（少了这步会影响系统使用），因此可以开一个子线程异步执行（或者用消息队列等中间件实现异步），不用等待它结束就能立即响应了。
4. 减少数据量。无论是最后返回给前端的数据、还是对缓存进行读写的数据，一般都是越小越好，可以减少网络传输、数据处理的耗时。举个例子，原本我是用 JDK 自带的序列化库来对从数据库中查询出的数据进行序列化、并塞到缓存中，数据大小大概 5 M，700 ms 左右读写完成；但今天我尝试用专业的、开源的序列化库 Kryo 来替换掉 JDK 的序列化库，Kryo 的性能更高、数据压缩能力更强，实测同样的数据条数大概只用了 2 M 多的空间（缩小了 1 倍多），并且只用了 200 多 ms 就读写完成了。但是要注意替换序列化库后，要把原本缓存中的老序列化数据清理掉，否则会冲突。
5. 合并查询。比如要查询 id 为 1、2、3 的用户，你可以执行 3 次根据 id 查询用户，但这样查询时间会随着要查询的 id 数线性增长；所以可以直接合并为批量查询：id in (1, 2, 3)，可以减少对数据库的请求次数，减少全表扫描的次数等，更快地查出数据。

有的时候，就是一些简单的操作和想法，就能提高应用的性能，大家也可以用上面提到的这些方法去优化自己的后端程序（前端也可以借鉴，比如合并请求），简历上能写的内容这不就来了么~

这两天加入星球的小伙伴比较多，今天没忙过来，直播回放也来不及发了。写完今天的打工日记也快 1 点了，明天再回答一下大家的问题吧，大家晚安，继续加油！