项目之前做过一个大屏数据展示的单页,需要展示实时的订单数、订单金额,还有设备、商铺方面的排行榜。因为前、后端开发对于 SQL 数据查询阻塞缺乏认知(也是因为懒),将单页中的所有数据都通过一个接口返回,前端每 10s 刷新一次数据。

后来发现了数据查询的阻塞问题,后端使用了 redis 缓存查询结果 1 个小时。这本来是可以缓解一些数据阻塞问题,因为按照理想状态,只要第一次查询到了数据,后续 1 个小时内都不会再有新的、相同的数据查询。唯一忽视的问题是,前端是 10s 刷新一次数据,如果数据不能够在限定时间内查询到,那么就会造成可怕的后果。

前端请求是有超时时间的,在这次的问题里发现,请求返回了 504。这意味着每 10s 一次,大概有 10 几次的请求,都没有等到查询结果就结束了。程序上应该是在 sql 返回结果前就结束了,这样 redis 永远拿不到缓存,即缓存没有起作用。

针对现有的问题,大概想到以下几种优化方法:

1. 降低实时数据的即时性。

前端降低查询的频次间隔,改为 5 分钟或 10 分钟一次刷新数据。针对存在不停刷新页面导致的不间断请求情况,后台设置 redis 标识字段,表示查询进行中。每次开始查询后,设置为进行中,查询结束之后才可以再次查询。针对前一次查询进行中的二次查询,直接返回空数据,或错误提示让前端耐心等待。

2. 拆分查询请求,区分需要即时查询的数据和普通时效的数据

可以将请求根据时效性拆分成多个查询请求,这样不仅降低了查询请求时间,还能针对不同时效的数据做不同级别的缓存。同时针对一些查全表的统计数据,可以做二级缓冲表,按年月生成记录,然后对二级表做统计。

文章目录