Redis原理分享,从使用到会用( 三 )


文章插图
 
4、Set 由哈希表实现 , 用于存储多个字符串的元素 , 但和列表不同的是集合中不允许有重复的元素 , 并且集合中的元素是无序的 。
常用场景: 标签、共同好友、共同好友等
特点: 集合的内部有hash表实现 , 这个很重要 。也就是它的特别和hash的字典结构差不多 , 只不过它相当于内部没有key的指定 , 直接是信息的存储 。把结果堆积在一起 。
常用命令:
SADD key member1 [member2] #向集合添加一个或多个成员SDIFF key1 [key2] #返回给定所有集合的差集SINTER key1 [key2] #返回给定所有集合的交集SUNION key1 [key2] #返回所有给定集合的并集SISMEMBER key member #判断 member 元素是否是集合 key 的成员SMEMBERS key #返回集合中的所有成员SREM key member1 [member2] # 移除集合中一个或多个成员

Redis原理分享,从使用到会用

文章插图
 
5、Sorted Set:有序集合 。将Set中的元素增加一个权重参数score , 元素按score有序排列 。数据插入集合时 , 已经是进行天然排序 。
常用场景:排行榜、带权重的消息队列、时间线等
特点:存储结构特点像hash的结构 , 只不过是把hash内部的key变为了Score用于技术的分值 。但是数据存储结构还是一致的 , 后面选择它的时候可以用于排行、权重这一块的业务 , 内部有一个计数的选项来保持内容的结果 。
常用命令:
ZADD key score1 member1 [score2 member2] #向有序集合添加一个或多个成员 , 或者更新已存在成员的分数ZINCRBY key increment member #有序集合中对指定成员的分数加上增量 incrementZRANGEBYSCORE key min max [WITHSCORES] [LIMIT] #通过分数范围返回有序集合指定区间内的成员ZINTERSTORE destination numkeys key [key …] #计算给定的一个或多个有序集的交集 , 并将结果集存储在新的有序集合 key 中ZUNIONSTORE destination numkeys key [key …] #计算给定的一个或多个有序集的并集 , 并存储在新的 key 中对于数据结构更多是需要明白每个数据类型的组成 , 当拿到业务情况时 。首先拆解业务组成的属性 , 从而用Redis的数据类型来代替原来需要MySQL结构化数据实现的业务 , 从而提升性能 。同时应对一些情况特殊的场景 , 例如:秒杀用队列的时候、分布式时采用session共享会话等等
二、提升缓存命中率说到底Redis再好 , 它的本质就是用于缓存数据 , 如果请求没有在Redis里面找到缓存的内容 , 那么同样还是不能减轻数据的压力 。同时如果内存存储一些冷数据也不能为那些高频率使用网站的用户提供服务 。
所以提升缓存的命中率显得异常重要 。那么如何来提升缓存的命令率呢?
那我们可设想 , 既然缓存的数据是需要通过Key的方式获取 , 那么我们在服务端进行key的监控 , 把那些不经常使用的key换成热点数据的key 。同时缓存是为了提供业务的快速访问 , 但网站中热点的业务并不是所有的业务都需要等等 。
归纳起来就是每个请求应该在哪里去找到key? 这个key使用的频率高吗?这个key会受那些因素影响后而导致缓存的命中率降低呢?
以下是一些因素问题的影响:
1. 业务场景
缓存适合“读多写少”的业务场景 , 反之 , 使用缓存的意义不大 , 命中率会很低 。缓存时间越长 , 命中率会越高 。时效性要求越低 , 就越适合缓存 。
2. 更新策略
缓存的粒度越小 , 命中率会越高 。举个实际的例子说明:
当缓存单个对象的时候(例如:单个用户信息) , 只有当该对象对应的数据发生变化时 , 我们才需要更新缓存或者让移除缓存 。而当缓存一个集合的时候(例如:所有用户数据) , 其中任何一个对象对应的数据发生变化时 , 都需要更新或移除缓存
3. 清理策略
对于持续运行的Redis服务器来说 ,  服务器需要定期对自身的资源和状态进行必要的检查和整理 , 有三种不同的删除策略 , 立即删除会短时间内占用大量cpu , 惰性删除会在一段时间内浪费内存 , 所以定时删除是一个折中的办法 。
(1)立即清理 。在设置键的过期时间时 , 创建一个回调事件 , 当过期时间达到时 , 由时间处理器自动执行键的删除操作 。


推荐阅读