Redis各个数据类型的使用场景,redis数据类型及应用场景( 二 )


embstr 的优势在于创建时少分配一次空间(RedisObject 和 sds 是连续的),删除时少释放一次空间,以及对象的所有数据连在一起,寻找方便;当然缺点也非常明显,如果字符串的长度增加,需要重新分配内存的时候,整个 RedisObject 和 sds 都需要重新分配空间 。修改 embstr 对象的时候,Redis 会将其转换成 raw 格式再进行修改,所以 embstr 对象修改之后的对象,一定是 raw 的 。
应用场景:常规计数都可以使用,可用作缓存、计数、限速等等,比如商品剩余数量,字典表信息,长度不能超过 512MB 。HashHash 对象的底层实现可以是 ziplist 或者 hashtable 。ziplist:在这个数据结构中,是按照 key1, value1, key2, value2 这样的顺序存放来存储的;hashTable:是由 dict 这个结构来实现的 。
(这个结构比较复杂,后面单写一篇来说)应用场景:Hash 适用于存储结构化的对象,可以直接修改这个对象中的某个字段的值;比如用户信息 。ListList 对象的编码可以是 ziplist 或者 linkedlist,从名字上也能看出来两种结构都是啥 。ziplist:是一种压缩链表,它存储数据都是连续地放在内存区域当中 。
linkedlist:是一种双向链表 。应用场景:通常网站上的消息列表,可以使用 List 来进行存储;另外 lrange 命令,从某个元素开始,读取多少个元素,可以看做是分页查询,比如很多网站上那种不断下拉,不断分页的效果 。SetSet 相对于 List 来说,Set 是可以自动排重的;它的编码可以是 intset 或者 hashtable。
intset:是一个整数集合,支持三种长度的整数:int16_t、int32_t、int64_t;集合中的数据长度必须是一致的,比如一个 int16_t 长度的 Set,当插入了一条 int32_t 长度的数据,那么所有的数据都会转成 int32_t 长度(不支持降级) 。hashTable:对于 Set 来说,hashTable 的 value 永远为 NULL 。
应用场景:如果要存储一个列表,同时又需要做数据排重的时候,可以使用 set ;另外,Redis 还为 Set 提供了求交集、并集、差集等操作,比如微博上面的【共同关注】这个功能,就可以用 Set 实现 。ZSet / Sorted Set和 Set 相比,ZSet 增加了一个参数 score,集合中的元素按照 score 进行有序排列 。
有序集合的编码可能两种,一种是 ziplist,另一种是 skipList 与 hashTable 的结合 。ziplist:和 Hash 类似,元素 和 score 都是按顺序存放的;比较适合用于元素内容不大的场景 。skipListhashTable:是一种添加,移除,更新元素等操作更高效的数据结构,这个跳跃表的数据结构,我近期会发一篇文章单独介绍 。
数据多的时候为什么要使用redis而不用mysql?

Redis各个数据类型的使用场景,redis数据类型及应用场景


【Redis各个数据类型的使用场景,redis数据类型及应用场景】通常来说,当数据多、并发量大的时候,架构中可以引入Redis,帮助提升架构的整体性能,减少Mysql(或其他数据库)的压力,但不是使用Redis,就不用MySQL 。因为Redis的性能十分优越,可以支持每秒十几万此的读/写操作,并且它还支持持久化、集群部署、分布式、主从同步等,Redis在高并发的场景下数据的安全和一致性,所以它经常用于两个场景:缓存经常会被查询,但是不经常被修改或者删除的数据;比如数据字典,业务数据中的热点数据;这样不仅提升查询效率,还可以减少数据库的压力;经常被查询,实时性要求不高数据,比如网站的最新列表、排行榜之类的数据,只需要定时统计一次,然后把统计结果放到Redis中提供查询(请不要使用select top 10 from xxxx) 。
缓存可以方便数据共享,比如我先用电脑网页打开X东,选了两件商品放到购物车里面,再登录手机APP,也是可以看到购物车里面的商品的 。判断数据是否适合缓存到Redis中,可以从几个方面考虑:会经常查询么?命中率如何?写操作多么?数据大小?我们经常采用这样的方式将数据刷到Redis中:查询的请求过来,现在Redis中查询,如果查询不到,就查询数据库拿到数据,再放到缓存中,这样第二次相同的查询请求过来,就可以直接在Redis中拿到数据;不过要注意【缓存穿透】的问题 。

推荐阅读