本文探讨了常规分页查询缓存存在的问题，如冗余数据、缓存命中率低和数据一致性挑战。提出了一种基于SortedSet的解决方案，利用ZSetOperations避免并发写入时的重复数据，确保数据一致性。然而，这种方式可能导致缓存空间浪费和系统处理能力下降。总结指出，选择合适的缓存策略应结合具体应用场景。
常规分页查询缓存方案
我们都知道，通过缓存查询的结果，可以极大的提升系统的服务能力，以及降低底层服务或者是数据库的压力。
对于有分页条件的缓存，我们也可以按照不同的分页条件来缓存多个key，比如分页查询产品列表,page=1&limit=10和page=1&limit=5这两次请求可以这样缓存查询结果
productList:page:1:limit:10
productList:page:1:limit:5
这个是一种常见方案，但是存在着一些问题：
缓存的value存在冗余，productList:page:1:limit:10缓存的内容其实是包括了productList:page:1:limit:5中的内容(缓存两个key的时候，数据未发生变化的情况下)
仅仅是改变了查询条件的分页条件，就会导致缓存未命中，降低了缓存的命中率
为了保证数据一致性，需要清理缓存的时候，很难处理，redis的keys命令对性能影响很大，会导致redis很大的延迟，生产环境一般来说禁止该命令。自己手动拼缓存key，你可能根本不知道拼到哪一个page为止。
放弃数据一致性，通过设置失效时间来自动失效，可能会出现查询第一页命中了缓存，查询第二页的时候未命中缓存，但此时数据已经发生了改变，导致第二页查询返回的和第一页相同的结果。
以上，在分页条件下这样使用常规方案总感觉有诸多困扰，诸多麻烦，那是不是就应该放弃使用缓存？
基于SortedSet的分页查询缓存方案
首先想到的解决方法是使用@see Li
最低0.47元/天 解锁文章
扫一扫
1002
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
