总结篇4：redis 核心数据存储结构及核心业务模型实现应用场景

redis 和memcached 有什么区别？

为什么在高并发下，单线程的redis 比多线程的效率高？

• mc 可以缓存图片和视频，redis 支持除更多的数据结构。redis 典型的应用场景是用户订单列表，用户消息，帖子评论等。

• redis 可以使用虚拟内存，redis 可持久化和aof 灾难恢复，支持主从数据备份。如果redis 挂了，内存能够快速恢复热数据，不会将压力瞬间压在数据库上，没有cache 预热的过程。对于只读和数据一致性要求不高的场景可以采用持久化存储。

• redis 可以做消息队列。redis 支持集群，可以实现主动复制，读写分离，mc 如果想实现高可用，需要进行二次开发。

• mc 存储的vlaue 最大为1M。

选择mc 的场景：

• 1 纯kv, 数据量非常大的业务。原因是：

• 1 mc 的内存分配采用的是预分配内存池的管理方式，能够省去内存分配的时间。redis 是临时申请空间，可以导致碎片化

• 2 虚拟内存使用，mc 将所有的数据存储在物理内存里，redis 有自己的vm 机制，理论上能够存储比物理内在更多的数据，当数据超量时，引发swap， 把冷数据刷新到磁盘上。从这点上看，数据量大时，mc 更快

• 3 网络模型。mc 使用非阻塞的io 复用模型，redis 也是使用非阻塞的io 复用模型，但是redis 还提供了一些非kv 存储之外的排序，聚合功能，复杂的cpu 计算，会阻塞整个io 调度，从这点上由于redis 提供的功能较多，mc 更快一些。

• 4 线程模型，mc 使用多线程，主线程监听，worker 子线程接受请求，执行读写，这个过程可能存在锁冲突。redis 使用单线程，虽然无锁冲突，但是难以利用多核的特性提升吞吐量。

选择redis 场景：

• 1 存储方式上：mc 会把数据全部存储在内存中，断电后会挂掉，数据不能超过内存的大小。redis 有部分数据存在硬盘上，这样能保证数据持久性。

• 2 数据支持类型上：redis 支持更丰富的数据类型

• 3 使用底层模型不同：底层实现方式以及客户端之间通信的应用协议不同。redis 直接构建了vm 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

• 4 value 大小。redis 可以达到1 G，而mc 只有1 M。

mc 多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。为什么 redis 单线程还如此快？因为底层有高效数据存储结构。整个redis 存储结构是全局哈希表，哈希运算非常快，时间复杂度为常量。

redis 常见性能问题和解决方案

• 1 master 最好不要做持久化工作，如RDB 内存快照和AOF 日志文件

• 2 如果数据比较重要，某个slave 开启AOF 备份，策略设置成每秒同步一次

• 3 为了主从复制的速度和连接的稳定性，master 和slave 最好在一个局域网内

• 4 尽量避免在压力大得主库上增加从库

• 主从复制不要采用网状结构，尽量是线性结构。

redis set key value， 其中key 类型都是string 类型。五种基本类型都是对应的value。

String 应用场景

• 字符串常用操作

set key value // 存入字符串键值对mset key value [key value] // 批量存储字符串键值对

• 单值缓存

1 set key value2 get key

• 对象缓存

1 set user:1 value(json 格式数据)2 mset user:1 name zhuge user:1:balance 888
  mget user:1:name user:1:balance

• 分布式锁

setnx product:100001 true // 返回1 代表获取锁成功setnx product:100001 true // 返回0代表获取锁失败。。。执行业务操作del product:100001  // 执行完业务释放锁set product:100001 true ex 10 nx // 防止程序意外终止导致死锁

• 计数器

incr article:readcount:{文章id}   // 文章点赞数get article:readcount:{文章id}

• 分布式系统全局序列号

incrby orderid 100  、、 redis 批量生成序列号提升性能

一般我们设置数据库自增主键，并设置相应索引。如果数据量很大，分库分表时就实现不了。可以用缓存实现。为提升性能，我们可以优化，做一个批量内存的自增，比如一次生成100个。

hash 常用操作

优点：

• 同类数据归类整合储存，方便数据管理

• 相比 string 操作消耗内在与cpu 更小

缺点：

• 过期功能不能使用在field 上，只能用在key 上

• redis 集群架构下不适合大规模使用

hset key field value // 存储一个哈希表key 的键值hsetnx key field value // 存储一个不存在的哈希表key 的键值hmset key field value [field value ...] // 在一个哈希表key 中存储多个键值对hget key field // 获取哈希表key 中多个field 键值hmget key field [field...] // 批量获取哈希表key 中多个field 键值hdel key field [field...] // 删除哈希表key 中的field 键值hlen key  // 返回哈希表key 中field 的数据hgetall key  // 返回哈希表key 中所有的键值hincrby key field increment  // 为哈希表key 中field 键的值加上增量 increment

场景：购物车

以用户id 为key以商品id 为field商品数据为value购物车操作添加商品 hset cart:1001 10088 1增加商品 hincrby cart:1001 10088 1商品数量 hlen cart:1001删除商品 hdel cart:1001 10088获取购物车所有商品 hgetall cart:1001

list 结构

list 常用操作

lpush key value [value..] //插入到列表最左边rpush key value [value...] //插入到列表最右边lpop key // 移除列表的头元素rpop key // 移除列表的尾元素lrange key start stop // 列表区间内元素blpop key [key ...] timeout // 从列表表头中弹出第一个元素。如果元素为空，阴塞等待timeout 秒。如果timeout 为0， 一直等待brpop key [key ...] timeout  // 从列表表尾弹出元素

常用数据结构 stack （栈） = lpush + lpop = filo queue (队列) = lpush + rpop blocking MQ(阴塞队列) = lpush + brpop

场景：消息流页面：订阅号，微博等

（这块功能如果用数据库也可实现，但是一般性能比较慢。如果有order by 等排序功能，还容易导致索失效。）

1 发消息id为18 lpush msh:{nameId} 182 发消息id为20 lpush msh:{nameId} 203 查看消息流 lrange msg:{nameId} 0 9

每个消息流推送给每个粉丝，如果粉丝量大，lpush 命令需要优化。如pipeline，或优先推送在线用户。

set 结构

 set 常用操作sadd key member [member ...] // 往集合key 中存入元素， 元素存在则忽略srem key member [member ...] // 从集合key 中删除元素smembers key // 获取集合key 中所有元素scard key // 获取集合key 的元素个数sismember key member // 判断member 元素是否存在集合key 中srandmember key [count] // 从集合key k 中选出count 个元素，元素不从key 中删除spop key [count] // 从集合key 中选出count 个元素，元素从key 中删除

应用场景：

抽奖1 点击抽奖加入集合 sadd key {userid}2 查看所有抽奖用户 smembers key3 抽取count 名中奖者srandmember key [count] / spop key [count]点赞sadd like:{消息id}{用户id}取消点赞 srem like:{消息id}{用户id}检查用户是否点过赞sismember like:{消息id}{用户id}获取点赞用户列表smembers like:{消息id}获取点赞用户数scard like：{消息id}

社交类产品的重要场景，叫社交关注模型

 set 运算操作sinter key [key ...]  // 交集运算sinterstore destination key [key ...] // 将交集结果存入新集合destination 中sunion key [key ...] // 并集运算sunionstore destination key [key ...] // 将并集结果存入新集合destination 中sdiff key [key ...] // 差集运算sdiffstore destination key [key ...] // 将差集结果存入新集合destination 中社交关注模型应用场景：1 nameA关注的人 nameAset2 nameB关注的人 nameBset3 nameC关注的人 nameCset4 我和nameA共同关注的人 sinter 
5 我关注的人也关注了他 sismember 
6 我可能认识的人 sdiff商品筛选模型 

zset 有序集合

常用操作zadd key score member [[score member]...] // 往有序集合key 中加入带分值元素zrem key member [member ...] // 从有序集合中删除元素zcore key member  // 返回有序集合key 中元素member 的分值zincrby key increment member // 为有序集合key 中元素member的分值加上increment 
zcard key // 返回有序集合key 中元素个数zrange key start stop [withscores] // 正序获取有序集合key 从start 下标到stop 下标的元素zrevrange key start stop [withscores] // 倒序集合操作zunionstore destkey numkeys key [key ...] 并集计算zinterstore destkey numkeys key [key ...] 交集计算

应用场景

1 点击新闻 zincrby hotnews:202008 1 name2 单日排行榜 zrevrange hotnews:202208 0 9 withscores 
3 七日搜索榜单计算zunionstore hotnews:20220801-20220807 74 展示七日榜前十zrevrange hotnews:20220801-20220807 0 9 withscores

redis 数据结构

数组：根据序号随机查找很快，但是插入与删除很慢，需要挪动很多元素。

链表：插入与删除很快，只需要修改相邻元素指针，但是查找很慢，需要从第一个元素逐个遍历查找。

有序数组支持折半查找，链表不支持折半查找。

有序数组的折半查找操作速度很快，但是插入、删除操作很慢。

跳表（O(logN)）：将有序列表改造为支持“折半查找”算法，可以进行快速的插入、删除、查找操作。

未完待续... ...

文：一只阿木木

欢迎转发、交流小数据。

松花酿酒，春水煎茶。

眉上风止，见字如晤。

一只阿木木