老司机使用 Redis 缓存复杂查询 - 推酷
老司机使用 Redis 缓存复杂查询
最近上线了一个复杂的报表, 这个报表后面是一个几百行的 sql 查询，很不幸但又是预料之中, 这个 sql 查询性能非常低下，并且需要在网站的一个访问量非常大的页面显示这个 sql 的查询结果。幸运的是这个查询结果不需要 实时更新，只要每天更新一次即可, 于是为这个 sql 查询加上缓存就成为了一个很好的优化方法。开始我们使用 Rails.cache 来缓存这个查询结果，Rails.cache 的 backend 配置如下:
# config/environments/production.rb
couch_host = YAML.load_file(Rails.root.join(&config/couch.yml&)).symbolize_keys[:host]
config.cache_store = :mem_cache_store, couch_host , { :namespace =& 'rails_cache' }
# config/couch.yml
host: xxx.xxx.xxx.xxx:xxx
从上面的代码可以看出我们使用了
作为 Rails.cache 的 backend, 我开始不太清楚为什么会使用 couchdb, 因为我们的系统中已经使用了 Redis, 并且 Redis 无论是使用舒适度还是性能都不输 couchdb, 后来我打开 Gemfile 发现:
gem 'rails', '3.0.9'
#gem 'redis-rails', '3.1.3'
#gem &redis-store&, &~& 1.0.0&
我们看到 redis-rails 和 redis-store 都被加在了 Gemfile 里，然后又被注释掉了，由此我估计前面的同事也想使用 Redis, 但是由于我们的 Rails 版本过老(现在 Rails 5 都发布了，我们还在使用 Rails 3), 导致 redis-rails 和 redis-store 无法使用，而我们既不想冒升级 Rails 的风险(这个升级的跨度有点大了), 也不愿意花时间去改造 redis-store 使其兼容 Rails 3(每天改 ticket 已经让人心力交瘁了,这个借口让自己无法反驳)。 报表上线之初，没有什么问题，后来随着数据量变大，发现报表展示的速度变慢但由于还可以容忍，也就没有去花时间去研究速度变慢的原因，直到不久运行 couchdb 的机器莫名宕机，造成整个网站 502(前端请求拿不到缓存就会去读数据库，这个查询很耗时就一直挂着，请求量一大数据库就受不住了，导致整个网站不可访问), 这时候我们决定重新设计下这个报表的缓存。我们的设计如下:
使用 Redis 替换 couchdb, 主要原因是对 Redis 熟悉，并且系统中的很多异步队列服务用的是 Redis，非常稳定。
前端请求只能从 Redis 中读取已经被缓存的查询结果，而不能直接读数据库，如果缓存为空则返回空数组，这样做是为了防止数据库被大量的耗时请求拖垮，保证整个网站的可访问性。
缓存的过期时间设置为 999 天，其实就是缓存不过期的意思，并且写一个 rake task 每天运行一次用于更新 Redis 缓存。
这个设计的 2 和 3 步其实就是一个典型的生产&消费模式, rake task 作为生产者每天定时生成一次查询结果存入 Redis, 前端请求作为消费者通过读取 Redis 获得查询结果供页面展示。
有了设计我们并不急于编写代码，而是画一个设计图，一方面是为了梳理下思路看看设计是否会有缺陷，另一方面是为了更好地编写代码。
设计图如下:
通过设计图我们可以看到数据是单向流动的, 这样生产者和消费者是互不干扰的隔离状态, 前端请求不生产数据，只从 Redis 中拿数据，这样情况下前端请求对数据库的访问压力几乎为0。从设计图中我们也可以看出我们的代码大概会 分成三部分:
生产者的代码
Redis的代码(主要是读写 Redis)
消费者的代码
其中生产者和消费者都依赖 Redis 的代码, 因为两者都需要和 Redis 产生交互。
Redis 相关代码
前面说过由于我们使用的 Rails 版本过低, 将 Redis 整合到 Rails.cache 会是一件比较费力费时的事情，所以我们将直接使用 Reids。
首先配置 Redis,
# config/redis_store.yml
host: xxx.xxx.xxx.xxx
driver: hiredis
thread_safe: true
timeout: 200
# config/initializers/redis.rb
$redis = Redis.new(YAML.load_file(&#{Rails.root}/config/redis_store.yml&).symbolize_keys[:cache])
从上面的代码中可以看到我们定义了一个全局变量 $redis 用来访问 Redis。
接下来是将 $redis 封装到一个 service 中，这样做的目的是方便进行测试，也便于使用及以后的扩展。
class ReportCacheService
def initialize(data = {})
# cache key
@key = data[:key]
# 设置过期时间
@expire_in = data[:expire_in]
# 强制更新缓存，用于生产者生产数据
@refresh_cache = data[:refresh_cache]
# block 里面是数据计算的过程
def call(&block)
if @refresh_cache == true
res = read()
if res.nil?
res = block.call
write(res)
value = $redis.get(@key)
if value.present?
JSON.parse(value)
def write(res)
value = res.to_json
value = $redis.set(@key, value)
$redis.expire(@key, @expire_in)
这样我们就完成了 Redis 这部分的代码，接下来是生产者的代码。
生产者代码
我们将和报表相关的业务和逻辑封装到了一个叫 StmReport 的模型中, 我们为 StmReport 定义了一个 class 方法: warm_cache 用于生产报表数据。
# app/models/stm_report.rb
class StmReport
NON_EXPIRED = 999.days.seconds
def self.warm_cache(parasm = {})
# refresh_cache: true 表示强制更新缓存，即生产数据
# 生产的数据的过期时间是 999 天
= ReportCacheService.new(key: build_cache_key(params),
refresh_cache: true,
expire_in: NON_EXPIRED)
cs.call do
# do some heavy works
接着我们编写一个 rake task， 并且使用 crontab 每天定时运行此 rake task 用于生产数据。
# lib/tasks/cron.rake
task :warn_stm_report_cache =& :environment do
puts &#{DateTime.now}: start cron warm cache&
StmReport.warm_cache(qualified: true)
StmReport.warm_cache(qualified: true, per_page: 50)
puts &#{DateTime.now}: end cron warm cache&
生产者的代码也完成，接下来是消费者的代码。
消费者的代码
在本文中，消费的过程即创建报表的过程, 创建报表的过程很自然地也封装到了 StmReport 模型中,
class StmReport
NON_EXPIRED = 999.days.seconds
def self.create(params = {})
= ReportCacheService.new(key: build_cache_key(params))
# 从缓存中读取数据
items = cs.read
# 如果缓存中没有数据即返回空数组，避免从数据库中查询数据
items = [] if items.nil?
# do some other works
这样整个实现就完成了，重新上线后的报表运行地非常稳定迅速，证明这个实现是成功的。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致查看: 4649|回复: 1
Redis遇到（大数据量）百亿级Key存储需求及解决方案介绍
主题帖子积分
问题导读：
1.需求背景是什么？2.存储何种数据？
3.数据特点是什么？
4.存在哪些技术挑战？
5.解决方案有哪些？
6.md5散列桶的方法需要注意的问题？
7.测试结果是什么？
解决方案：
1 需求背景
该应用场景为DMP缓存存储需求，DMP需要管理非常多的第三方id数据，其中包括各媒体cookie与自身cookie（以下统称supperid）的mapping关系，还包括了supperid的人口标签、移动端id（主要是idfa和imei）的人口标签，以及一些黑名单id、ip等数据。
在hdfs的帮助下离线存储千亿记录并不困难，然而DMP还需要提供毫秒级的实时查询。由于cookie这种id本身具有不稳定性，所以很多的真实用户的浏览行为会导致大量的新cookie生成，只有及时同步mapping的数据才能命中DMP的人口标签，无法通过预热来获取较高的命中，这就跟缓存存储带来了极大的挑战。
经过实际测试，对于上述数据，常规存储超过五十亿的kv记录就需要1T多的内存，如果需要做高可用多副本那带来的消耗是巨大的，另外kv的长短不齐也会带来很多内存碎片，这就需要超大规模的存储方案来解决上述问题。
2 存储何种数据
人⼝标签主要是cookie、imei、idfa以及其对应的gender（性别）、age（年龄段）、geo（地域）等；mapping关系主要是媒体cookie对supperid的映射。以下是数据存储⽰示例：
1) PC端的ID：
媒体编号-媒体cookie=&supperid
supperid =& { age=&年龄段编码，gender=&性别编码，geo=&地理位置编码 }
2) Device端的ID：
imei or idfa =& { age=&年龄段编码，gender=&性别编码，geo=&地理位置编码 }
显然PC数据需要存储两种key=&value还有key=&hashmap，⽽而Device数据需要存储⼀一种
key=&hashmap即可。
3 数据特点
短key短value：其中superid为21位数字：比如1689522；imei为小写md5：比如2df37d362a5d；idfa为大写带”-”md5：比如：51DFFC83--FA4F-D04；
媒体自身的cookie长短不一；
需要为全量数据提供服务，supperid是百亿级、媒体映射是千亿级、移动id是几十亿级；
每天有十亿级别的mapping关系产生；
对于较大时间窗口内可以预判热数据（有一些存留的稳定cookie）；
对于当前mapping数据无法预判热数据，有很多是新生成的cookie；
4 存在的技术挑战
1）长短不一容易造成内存碎片；
2）由于指针大量存在，内存膨胀率比较高，一般在7倍，纯内存存储通病；
3）虽然可以通过cookie的行为预判其热度，但每天新生成的id依然很多（百分比比较敏感，暂不透露）；
4）由于服务要求在公网环境（国内公网延迟60ms以下）下100ms以内，所以原则上当天新更新的mapping和人口标签需要全部in memory，而不会让请求落到后端的冷数据；
5）业务方面，所有数据原则上至少保留35天甚至更久；
6）内存至今也比较昂贵，百亿级Key乃至千亿级存储方案势在必行！
5 解决方案
5.1 淘汰策略
存储吃紧的一个重要原因在于每天会有很多新数据入库，所以及时清理数据尤为重要。主要方法就是发现和保留热数据淘汰冷数据。
网民的量级远远达不到几十亿的规模，id有一定的生命周期，会不断的变化。所以很大程度上我们存储的id实际上是无效的。而查询其实前端的逻辑就是广告曝光，跟人的行为有关，所以一个id在某个时间窗口的（可能是一个campaign，半个月、几个月）访问行为上会有一定的重复性。
数据初始化之前，我们先利用hbase将日志的id聚合去重，划定TTL的范围，一般是35天，这样可以砍掉近35天未出现的id。另外在Redis中设置过期时间是35天，当有访问并命中时，对key进行续命，延长过期时间，未在35天出现的自然淘汰。这样可以针对稳定cookie或id有效，实际证明，续命的方法对idfa和imei比较实用，长期积累可达到非常理想的命中。
5.2 减少膨胀
Hash表空间大小和Key的个数决定了冲突率（或者用负载因子衡量），再合理的范围内，key越多自然hash表空间越大，消耗的内存自然也会很大。再加上大量指针本身是长整型，所以内存存储的膨胀十分可观。先来谈谈如何把key的个数减少。
大家先来了解一种存储结构。我们期望将key1=&value1存储在redis中，那么可以按照如下过程去存储。先用固定长度的随机散列md5(key)值作为redis的key，我们称之为BucketId，而将key1=&value1存储在hashmap结构中，这样在查询的时候就可以让client按照上面的过程计算出散列，从而查询到value1。
过程变化简单描述为：get(key1) -& hget(md5(key1), key1) 从而得到value1。
如果我们通过预先计算，让很多key可以在BucketId空间里碰撞，那么可以认为一个BucketId下面挂了多个key。比如平均每个BucketId下面挂10个key，那么理论上我们将会减少超过90%的redis key的个数。
具体实现起来有一些麻烦，而且用这个方法之前你要想好容量规模。我们通常使用的md5是32位的hexString（16进制字符），它的空间是128bit，这个量级太大了，我们需要存储的是百亿级，大约是33bit，所以我们需要有一种机制计算出合适位数的散列，而且为了节约内存，我们需要利用全部字符类型（ASCII码在0~127之间）来填充，而不用HexString，这样Key的长度可以缩短到一半。
下面是具体的实现方式
[Java] 纯文本查看 复制代码public static byte [] getBucketId(byte [] key, Integer bit) {
MessageDigest mdInst = MessageDigest.getInstance(&MD5&);
mdInst.update(key);
byte [] md = mdInst.digest();
byte [] r = new byte[(bit-1)/7 + 1];// 因为一个字节中只有7位能够表示成单字符
int a = (int) Math.pow(2, bit%7)-2;
md[r.length-1] = (byte) (md[r.length-1] & a);
System.arraycopy(md, 0, r, 0, r.length);
for(int i=0;i&r.i++) {
if(r[i]&0) r[i] &= 127;
参数bit决定了最终BucketId空间的大小，空间大小集合是2的整数幂次的离散值。这里解释一下为何一个字节中只有7位可用，是因为redis存储key时需要是ASCII（0~127），而不是byte array。如果规划百亿级存储，计划每个桶分担10个kv，那么我们只需2^30=的桶个数即可，也就是最终key的个数。
5.3 减少碎片
碎片主要原因在于内存无法对齐、过期删除后，内存无法重新分配。通过上文描述的方式，我们可以将人口标签和mapping数据按照上面的方式去存储，这样的好处就是redis key是等长的。另外对于hashmap中的key我们也做了相关优化，截取cookie或者deviceid的后六位作为key，这样也可以保证内存对齐，理论上会有冲突的可能性，但在同一个桶内后缀相同的概率极低(试想id几乎是随机的字符串，随意10个由较长字符组成的id后缀相同的概率*桶样本数=发生冲突的期望值&&0.05,也就是说出现一个冲突样本则是极小概率事件，而且这个概率可以通过调整后缀保留长度控制期望值)。而value只存储age、gender、geo的编码，用三个字节去存储。
另外提一下，减少碎片还有个很low但是有效的方法，将slave重启，然后强制的failover切换主从，这样相当于给master整理的内存的碎片。
推荐Google-tcmalloc， facebook-jemalloc内存分配，可以在value不大时减少内存碎片和内存消耗。有人测过大value情况下反而libc更节约。
6. md5散列桶的方法需要注意的问题
1）kv存储的量级必须事先规划好，浮动的范围大概在桶个数的十到十五倍，比如我就想存储百亿左右的kv，那么最好选择30bit~31bit作为桶的个数。也就是说业务增长在一个合理的范围（10~15倍的增长）是没问题的，如果业务太多倍数的增长，会导致hashset增长过快导致查询时间增加，甚至触发zip-list阈值，导致内存急剧上升。
2）适合短小value，如果value太大或字段太多并不适合，因为这种方式必须要求把value一次性取出，比如人口标签是非常小的编码，甚至只需要3、4个bit（位）就能装下。
3）典型的时间换空间的做法，由于我们的业务场景并不是要求在极高的qps之下，一般每天亿到十亿级别的量，所以合理利用CPU租值，也是十分经济的。
4）由于使用了信息摘要降低了key的大小以及约定长度，所以无法从redis里面random出key。如果需要导出，必须在冷数据中导出。
5）expire需要自己实现，目前的算法很简单，由于只有在写操作时才会增加消耗，所以在写操作时按照一定的比例抽样，用HLEN命中判断是否超过15个entry，超过才将过期的key删除，TTL的时间戳存储在value的前32bit中。
6）桶的消耗统计是需要做的。需要定期清理过期的key，保证redis的查询不会变慢。
7. 测试结果
人口标签和mapping的数据100亿条记录。
优化前用2.3T，碎片率在2左右；优化后500g，而单个桶的平均消耗在4左右。碎片率在1.02左右。查询时这对于cpu的耗损微乎其微。
另外需要提一下的是，每个桶的消耗实际上并不是均匀的，而是符合多项式分布的。
_131551.png (7.47 KB, 下载次数: 0)
13:16 上传
上面的公式可以计算桶消耗的概率分布。公式是唬人用的，只是为了提醒大家不要想当然的认为桶消耗是完全均匀的，有可能有的桶会有上百个key。但事实并不没有那么夸张。试想一下投硬币，结果只有两种正反面。相当于只有两个桶，如果你投上无限多次，每一次相当于一次伯努利实验，那么两个桶必然会十分的均匀。概率分布就像上帝施的魔咒一样，当你面对大量的桶进行很多的广义的伯努利实验。桶的消耗分布就会趋于一种稳定的值。接下来我们就了解一下桶消耗分布具体什么情况：
通过采样统计
31bit（20多亿）的桶，平均4.18消耗
_131654.png (8.36 KB, 下载次数: 0)
13:17 上传
100亿节约了1.8T内存。相当于节约了原先的78%内存，而且桶消耗指标远没有达到预计的底线值15。
对于未出现的桶也是存在一定量的，如果过多会导致规划不准确，其实数量是符合二项分布的，对于2^30桶存储2^32kv，不存在的桶大概有（百万级别，影响不大）：
Math.pow((1 - 1.0 / Math.pow(2, 30)), Math.pow(2, 32)) * Math.pow(2, 30);
对于桶消耗不均衡的问题不必太担心，随着时间的推移，写入时会对HLEN超过15的桶进行削减，根据多项式分布的原理，当实验次数多到一定程度时，桶的分布就会趋于均匀（硬币投掷无数次，那么正反面出现次数应该是一致的），只不过我们通过expire策略削减了桶消耗，实际上对于每个桶已经经历了很多的实验发生。
总结：信息摘要在这种场景下不仅能节约key存储，对齐了内存，还能让Key按照多项式分布均匀的散列在更少量的key下面从而减少膨胀，另外无需在给key设置expire，也很大程度上节约了空间。
这也印证了时间换空间的基本理论，合理利用CPU租值也是需要考虑的。
关注分布式存储技术以及分布式计算方法
来源：博客园
作者：花考拉
主题帖子积分
高级会员, 积分 1210, 距离下一级还需 3790 积分
高级会员, 积分 1210, 距离下一级还需 3790 积分
还不错，这个业务场景不常见
站长推荐 /6
about云|新出视频，openstack零基础入门，解决你ping不通外网难题
云计算hadoop视频大全(新增 yarn、flume|storm、hadoop一套视频
视频资料大优惠
大数据零基础由入门到实战
阶段1：hadoop零基础入门基础篇
阶段2：hadoop2入门
阶段3：大数据非hadoop系列课程
阶段4：项目实战篇
阶段5：大数据高级系列应用课程
阶段6：工作实用系列教程
等待验证会员请验证邮箱
新手获取积分方法
Powered byredis等缓存，如何定义key确保唯一? - 对酒当歌，人生几何 - ITeye技术网站
1.前言。
& 对于存储不同的值，可能会用md5,但md5效率不高，8000字可能要花16毫秒。而hashcode则是0，如果直接用hashcode生成不一样的值，那么就可以做为主键了。
2.代码。
public int hashCode() {
// TODO Auto-generated method stub
int hash = 1;
hash = hash * 31 + name.hashCode();
hash = hash * 31
+ (password== null ? 0 : password.hashCode());
finallygo 写道hashcode不是会重复?
数字操作可能会有重复，所以尽量不要单独加数字，但是字符串是绝对不会重复的，可以去看jdk关于char的hashcode源码。
仔细又想了一下，还是有可能重复的，比如int类型超过了相加溢出。有一种魔兽暴雪的算法，说用三重hashtable可以实现不重复。&&
& 最后我还是换成md5.特此修正。
hashcode不是会重复?
数字操作可能会有重复，所以尽量不要单独加数字，但是字符串是绝对不会重复的，可以去看jdk关于char的hashcode源码。
浏览: 804545 次
来自: 深圳
java-lxm 写道好湿好湿好湿谢谢: )。
好湿好湿好湿redis 的两种持久化方式及原理 - zhengdl126 - ITeye技术网站
博客分类：
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
第一种方法filesnapshotting：默认redis是会以快照的形式将数据持久化到磁盘的（一个二进 制文件，dump.rdb，这个文件名字可以指定），在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave（异步）做快照。
工作原理简单介绍一下：当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write
还有一种持久化方法是Append-only：filesnapshotting方法在redis异常死掉时， 最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。Append-only方法可 以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到 redis关闭前的最后时刻。
LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。
AOF文件刷新的方式，有三种，参考配置参数appendfsync ：appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；appendfsync everysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。
可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：首先做一个AOF文件的备份，复制到其他地方；修复原始AOF文件，执行：$ redis-check-aof –可以通过diff –u命令来查看修复前后文件不一致的地方；重启redis服务。
LOG Rewrite的工作原理:同样用到了copy-on-write：首先redis会fork一个子进程；子进程将最新的AOF写入一个临时文件；父进程 增量的把内存中的最新执行的修改写入（这时仍写入旧的AOF，rewrite如果失败也是安全的）；当子进程完成rewrite临时文件后，父进程会收到 一个信号，并把之前内存中增量的修改写入临时文件末尾；这时redis将旧AOF文件重命名，临时文件重命名，开始向新的AOF中写入。
最后，为以防万一（机器坏掉或磁盘坏掉），记得定期把使用 filesnapshotting 或 Append-only 生成的*rdb *.aof文件备份到远程机器上。我是用crontab每半小时SCP一次。我没有使用redis的主从功能 ，因为半小时备份一次应该是可以了，而且我觉得有如果做主从有点浪费机器。这个最终还是看应用来定了。
========================
浏览 14752
zhengdl126
浏览: 1479833 次
来自: 深圳
原文的书在哪里
你好，请问个问题，从master同步数据到slave的时候，s ...
你好，看了你的文章，我想请教个问题， 我在用 redis的时候 ...
写得非常好
写得非常好初学Redis（4）——简单实现Redis缓存中的排序功能
在实现缓存排序功能之前，必须先明白这一功能的合理性。不妨思考一下，既然可以在中排序，为什么还要把排序功能放在缓存中实现呢？这里简单总结了两个原因：首先，排序会增加数据库的负载，难以支撑高并发的应用；其次，在缓存中排序不会遇到表锁定的问题。Redis恰好提供了排序功能，使我们可以方便地实现缓存排序。
Redis中用于实现排序功能的是SORT命令。该命令提供了多种参数，可以对列表，集合和有序集合进行排序。SORT命令格式如下：
SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC | DESC] [ALPHA] [STORE destination]
BY参数用于指定排序字段，功能类似于SQL中的order by。对于列表和集合而言，仅按照它们的值进行排序往往没有实际意义。以函数Cache2Hash返回的集合为例（实际上返回的是集合键），该集合中存储的是一系列完整的哈希键，只按照这些键进行排序，结果无非是按照数字或字典顺序排列，其用处显然不大。这是因为真正存储行数据的是哈希结构本身，而非哈希键。假设集合键为&resultset.hash:123456&，集合中每个哈希键对应的哈希结构中都有一个名为&timestamp&的字段，现在要把集合中的所有哈希键按照timestamp字段进行排序，这时，只需执行以下命令：
SORT resultset.hash:123456 BY *-&timestamp
从上例可以看出，BY的真正威力在于它可以让SORT命令按照一个指定的外部键的外部字段进行排序。SORT用集合resultset.hash:123456中的每个值（即每个哈希键）替换BY参数后的第一个&*&，并依据&-&&后面给出的字段获取其值，最后根据这些字段值对哈希键进行排序。
LIMIT参数用于限制排序以后返回元素的数量，功能类似于SQL中的limit。该参数接受另外两个参数，即offset和count，LIMIT offset count表示跳过前offset个元素，返回之后的连续count个元素。可见，LIMIT参数可以用于实现分页功能。
GET参数用于返回指定的字段值。以集合resultset.hash:123456为例，使用BY参数对集合中的所有哈希键按照哈希结构中的timestamp字段排序后，SORT命令返回所有排序之后的哈希键。如果某个请求需要不是键而是某些字段值，这时就要使用GET参数，使SORT命令返回指定字段值。假设除timestamp字段以外，集合中每个哈希键对应的哈希结构中还有一个名为&id&的字段，通过以下命令可以使SORT返回按照timestamp排序以后的每个哈希键对应的哈希结构中的timestamp和id值：
SORT resultset.hash:123456 BY *-&timestamp GET *-&timestamp GET *-&id
SORT用集合resultset.hash:123456中的每个值（即每个哈希键）替换GET参数之后的第一个&*&，并将其作为返回值。值得注意的是，利用GET #能够得到集合中的哈希键本身。
ASC和DESC参数用于指定排序顺序（默认为ASC，即从低到高），ALPHA参数用于按照字典顺序排列非数字元素。
STORE参数用于将SORT命令的返回值，即排序结果存入一个指定的列表。加上STORE参数后，SORT命令的返回值就变为排序结果的个数。
下面的代码实现了按照哈希的某个字段对集合中的哈希键排序，并将结果存入列表的过程：
// 该函数对集合中的所有HASH键进行排序，排序依据是HASH键所对应的HASH中的某个字段，
// 排序结果被存入一个LIST结构，LIST键应当包含结果集标识符和排序字段标识符，
// 形如&sorted:4&
string SortHash(sql::Connection *_connection,
redisContext *redis_connection,
const string &resultset_id,
const string &sort_field,
int offset, int count, int order, int ttl) {
// 只考虑存储HASH键的SET
string redis_row_set_key = &resultset.hash:& + resultset_
redisReply *
// 检测SET是否存在
reply = static_cast&redisReply*&(redisCommand(redis_connection,
&EXISTS %s&,
redis_row_set_key.c_str()));
if (reply-&integer == 0) {
freeReplyObject(reply);
throw runtime_error(&FAILURE - no resultsets&);
freeReplyObject(reply);
string field_md5 = md5(sort_field);
// 利用MD5排除排序字段中空格造成的影响
// 将排序结果存入该LIST
string redis_sorted_list_key = &sorted:& + resultset_id + &:& + field_md5;
string by(&*-&& + sort_field);
//确定排序字段
string ord = (order == 1) ? &ASC& : &DESC&;
//order==1时按照升序排列；否则为降序
stringstream ofsstream,
ofsstream &&
cntstream &&
// 执行排序命令，并把排序结果存入LIST
reply = static_cast&redisReply*&(redisCommand(
redis_connection,
&SORT %s BY %s LIMIT %s %s GET %s ALPHA STORE %s&,
redis_row_set_key.c_str(),
by.c_str(),
ofsstream.str().c_str(),
cntstream.str().c_str(),
redis_sorted_list_key.c_str()));
freeReplyObject(reply);
ttlstream &&
// 设置LIST的过期时间
reply = static_cast&redisReply*&(redisCommand(redis_connection,
&EXPIRE %s %s&,
redis_sorted_list_key.c_str(),
ttlstream.str().c_str()));
freeReplyObject(reply);
return redis_sorted_list_
// 返回LIST键，以便于其他函数获取该LIST中的内容
显然，对结果集中的哈希键进行排序要比对字符串键排序更加直观和方便。借助于排序函数，可以方便地实现在Redis中查询排序后的结果集，代码如下：
// 该函数根据sql语句和排序参数，在Redis中查询相应的结果集并进行排序，最后返回
// 排序之后的HASH键
vector&string& GetSortedCache(sql::Connection *mysql_connection,
redisContext *redis_connection,
const string &sql, const string &sort_field,
int offset, int count, int order, int ttl) {
vector&string& redis_row_key_
redisReply *
string resultset_id = md5(sql);
// 结果集标识符
string field_md5 = md5(sort_field);
// 排序字段标识符
// 尝试获取LIST中的所有HASH键
string redis_sorted_list_key = &sorted:& + resultset_id + &:& + field_md5;
// 尝试获取LIST中的所有HASH键
reply = static_cast&redisReply*&(redisCommand(redis_connection,
&LRANGE %s %s %s&,
redis_sorted_list_key.c_str(),
if (reply-&type == REDIS_REPLY_ARRAY) {
// 如果LIST不存在，调用Cache2Hash函数从Mysql中拉取数据到Redis，然后调用SortHash函数
// 对结果集进行排序并将排序后的HASH键存入LIST
if (reply-&elements == 0) {
freeReplyObject(reply);
sql::Statement *stmt = mysql_connection-&createStatement();
sql::ResultSet *resultset = stmt-&executeQuery(sql);
Cache2Hash(mysql_connection, redis_connection, resultset,
resultset_id, ttl);
redis_sorted_list_key = SortHash(mysql_connection, redis_connection,
resultset_id, sort_field, offset,
count, order, ttl);
// 再次尝试获取LIST中的所有HASH键
reply = static_cast&redisReply*&(redisCommand(
redis_connection,
&LRANGE %s %s %s&,
redis_sorted_list_key.c_str(),
// 将LIST中的所有HASH键存入redis_row_key_vector中
string redis_row_
for (int i = 0; i & reply-& ++i) {
redis_row_key = reply-&element[i]-&
redis_row_key_vector.push_back(redis_row_key);
freeReplyObject(reply);
freeReplyObject(reply);
throw runtime_error(&FAILURE - LRANGE error&);
return redis_row_key_
这样，在Redis中对结果集进行简单排序操作的功能就实现了。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'