对于具有寻呼条件的缓存，根据不同的寻呼条件缓存多个密钥，如在寻呼查询产品列表、page=1limit=10和page=1limit=5的两次请求中以这种方式缓存查询结果
product list : page :13360 limit :10
产品列表： page :1: limit :5
这是常见的方案，但也有一些问题。
缓存中的value具有冗馀，并且product list : page : limit :10缓存的内容实际上包含product list : page 336013360 limit :5的内容(例如
只需更改查询条件的分页条件，缓存就不会命中，缓存命中率也会降低
如果需要清理缓存以确保数据完整性，则很难处理。 redis的keys命令对性能有很大影响，会导致redis的延迟。 在生产环境中一般禁止该命令。 如果自己组高速缓存键，可能不知道要组到哪个page。
放弃数据一致性，通过设置过期日期自动禁用。 查询的第一页命中缓存，查询第二页时未命中缓存，但此时数据已更改，因此第二页查询可能返回与第一页相同的结果。
以上，在分页条件下这样使用普通计划总是感到很多烦恼、很多麻烦，应该放弃使用缓存吗？
基于SortedSet的页面查询缓存方案
首先，可能的解决方案是使用一个key，不使用@see ListOperations基于分页条件使用多个key，将所有数据缓存在redis中而不进行分页，然后根据分页条件使用range 这可能在缓存禁用时同时引起问题
因此，考虑到使用set处理同时执行时的重复数据，@see ZSetOperations
代码逻辑如下：
range(key，start，limit ) )根据分页条件获取缓存，命中后直接返回
缓存未命中、查询了数据库(无分页条件)或调用了底层接口(无分页) )。
添加(密钥，值缓存)写缓存、expire配置缓存时间
如果需要清理缓存，请直接删除密钥。 如果是因为添加或删除数据，则可以使用添加(密钥、值、得分)或移除(移动)密钥、值)
redis会按score分数的升序对地图中的数据进行排序。 通常，score分数是sql语句中order by filedA的filedA值，以确保数据的一致性
但是，这种方法也有问题。
此key缓存中的value确实是热数据，但可能只有少数数据经常使用，而其余数据可能根本没有使用。 例如，数据可能有100页，实际上只使用了前10页。 这还会浪费缓存空间，甚至会影响使用redis虚拟内存的情况
sql查询将从原始分页查询更改为无分页查询，禁用缓存后，系统的处理能力将比以前降低。 特别是对于聪明的店员。