php本身是没有分页概念的,分页是URL传参,然后通过mysql查询语句到数据库获取数据,然后实现的分页,url上的参数,通过PHP的$_GET都是可以获取到的.
存储在一个序列集合中,存储数据ID就好了,然后可以正序,倒序,查询,但是你想要加上条件查询,需要做很多的索引.
productList:page:1:limit:10
这个是一种常见方案,但是存在着一些问题:
仅仅是改变了查询条件的分页条件,就会导致缓存未命中,降低了缓存的命中率
为了保证数据一致性,需要清理缓存的时候,很难处理,redis的keys命令对性能影响很大,会导致redis很大的延迟,生产环境一般来说禁止该命令.自己手动拼缓存key,你可能根本不知道拼到哪一个page为止.
放弃数据一致性,通过设置失效时间来自动失效,可能会出现查询第一页命中了缓存,查询第二页的时候未命中缓存,但此时数据已经发生了改变,导致第二页查询返回的和第一页相同的结果.
以上,在分页条件下这样使用常规方案总感觉有诸多困扰,诸多麻烦,那是不是就应该放弃使用缓存?
基于SortedSet的分页查询缓存方案
所以想到通过使用set来处理并发时的重复数据,@see ZSetOperationsK, V
代码逻辑如下:
range(key,start,limit)按照分页条件获取缓存,命中则直接返回
缓存未命中,查询(没有分页条件)数据库或是调用(没有分页)底层接口
add(key,valueScoreMapvalue,score)写入缓存,expire设置缓存时间
当需要清理缓存时,直接删除key,如果是因为数据新增和删除,可以add(key,value,score)或remove(key,value)
redis中会按照score分值升序排列map中的数据,一般的,score分值是sql语句的order by filedA的filedA的值,这样能保证数据一致性
但是这种方式也存在一定问题:
这个key缓存的value确实是热数据,但可能只有少数数据被频繁使用其余的可能根本就未被使用,比如数据有100页,实际可能只会用到前10页,这也会导致缓存空间的浪费,如果使用了redis虚拟内存,也会有一定影响
sql查询由原来的分页查询变成了不分页查询,缓存失效后,系统的处理能力较之前会有下降,尤其是对于大表.
//把SQL语句拆分掉.
$sql = 'select * from table where id0';
//定义一个$where = '';
//再定义一个数组存条件做分页用
$param = array();
$name = trim($_REQUEST['name']);
if(!empty($name))[
$where .= 'name='.$name;
$param['name'] = $name;
}
//...更多的条件依次往上加
$sql = $sql . $where;//这样就把条件带到SQL里去了
//分页用的$url 同时和$param重组
$str = '';
foreach($param as $k=$v){
$str .= ''.$k.'='.$v; //配置一个参数字符串
//带参数的URL重组
$url = $url . '?page='.$page . $str;
这样SQL语句和要分页的URL都含有参数了.
或者用SESSION 但不推荐
统计和分页查询都加上相同条件就行了:
$count = M('')-where('条件')-count();
$list= M('')-where('条件')-limit(分页)-select();
附上tp手册的条件查询分页方式: