redis 特性以及五种数据类型的编码特点适用场景
redis特性优势(快)
- 纯内存访问, redis在不进行持久化配置的时候, 数据存在内存中, 内存的响应时间大约为100纳秒, 非常快, 每秒可以处理上万访问。
- 非阻塞I/O, redis使用epoll 作为I/O 多路复用技术的实现, 再加上redis自身的事件模型epoll中的连接, 读写, 关闭都转换为事件,不再网络I/O上浪费时间
- 采用单线程的情况下, 避免了线程之间切换, 竞态生成等消耗
string类型的编码及适用场景
- string 的编码
redis 会根据当前值的类型和长度决定使用那种内部编码实现
1. int 为8字节的长整形
2. embstr:小于等于39个字节的字符串
3. raw:大于39个字节的字符串
set key 8856
object encoding key
- string 的使用场景
- 可以做缓存
redis 可以设置ley-value形式, 做缓存, 见效数据库的压力- 可以计数
使用incr针对key的访问进行计数, 比如统计文章的浏览量等- 共享Session
保障redis的高可用, 高扩展性, 将用户的数据存在redis里面, 所有系统都在redis里面取用户的认证信息- 限速
比如限制用户每分钟只能访问5次
hash 的编码及适用的类型
- 内部编码
- ziplist(压缩列表) 当哈希类型的元素个数小于hash-max-ziplist-entries 配置(默认512), 同时所有值都小于hash-max-ziplist-value配置(默认64字节) 更加紧凑, 可以实现多个元素的连续存储, 更加节省内存
- hashtable 当哈希类型无法满足ziplist的条件时, redis就会使用hashtable实现, 在这之后, ziplist的读写能力就会下降, 而hashtable的时间复杂度为O(1)
- 适用场景
- 可以实现一个key 多个field-value的对象存储
list的编码及适用场景
- 内部编码
- ziplist(压缩列表) 当列表的元素个数小于hash-max-ziplist-entries 配置(默认512), 同时所有值都小于hash-max-ziplist-value配置(默认64字节) redis会使用ziplist来节省内存
linkedlist(链表) 当无法满足ziplist的时候就用linkedlist
- 适用场景
- 消息队列
redis的lpush+brpop可以实现阻塞队列, 生产者使用lpush在队列的左侧插入, 然后多个消费者使用brpop在队列的末尾抢元素。- 文章列表
每个用户有自己的文章列表, 且需要分页, list可以支持有序并且可以范围查询
集合set的内部编码及使用场景
- 内部编码
- intset ( 整数集合) 当集合中的元素都是整数且元素个数小于set-max-intset-entries 配置(默认512)
- hashtable 当不满足intset条件时, 使用hashtable来实现
- 使用场景
- 统计相同爱好的用户
有序集合zset的编码及适用场景
- 内部编码
- ziplist(压缩列表) 当集合的元素个数小于hash-max-ziplist-entries 配置(默认512), 同时所有值都小于hash-max-ziplist-value配置(默认64字节) 更加紧凑, 可以实现多个元素的连续存储, 更加节省内存
skiplist (跳跃表) 当不满足ziplist 的条件时, 适用skiplist
- 适用场景
可以用于统计点赞量等