目录
List 编码方式
早期版本
现今版本
List 实际应用
多表之间的关联关系
消息队列
频道（多列表）消息队列
微博 Timeline
栈 & 队列
List 编码方式
早期版本
- 早期版本 List 类型的内部编码方式有两种
- ziplist（压缩列表）
- linkedlist（链表）
- 两个配置项
- list-max-ziplist-entries 配置
- list-max-ziplist-value 配置
注意：
- 现版本Redis 已不再使用这两个配置项
- 且上述的 两种编码方式 为早期版本 Reids 中的 List 类型内部编码方式
现今版本
- 现今版本 Redis 使用 quicklist 作为 List 类型的内部编码方式
- quicklist 相当于ziplist 和 linkedlist 的结合
- quicklist 整体上还是一个 linkedlist ，但 linkedlist 的每个节点均为一个 ziplist
特点：
- 每个节点上的 ziplist 不会太大，且这多个 ziplist 通过链式结构链接起来
配置项：
- 该配置项描述了每个节点 ziplist 的阈值
- 当 ziplist 满足阈值，便将其分裂成多个列表节点，即多个 ziplist
- 再将这多个 ziplist 通过链式结构链接起来
注意：
- 观察上图注释信息，ziplist 的阈值为可选项
- 所以我们还需针对当前业务场景，来选择合适的阈值！
实例理解
- 我们通过object encoding key来查看编码方式
List 实际应用
多表之间的关联关系
- 可将list 作为 数组 这样的结构来存储多个元素
实例理解
- 使用 MySQL 表示学生和班级信息
- 上图MySQL 表结构 可以很方便的实现 查询指定班级中有哪些同学
- Redis 所提供的查询功能 是不如 MySQL 的
- 所以我们可以通过往 Redis 中插入 List 类型键值对直接将 学生 和 班级信息 进行关联
- 结合上图实例，Redis 通过 List 类型 便可以将 学生 和 班级信息 关联起来
- 从而能很轻易的实现查询指定班级中有哪些同学
注意：
- 此处除了使用 Hash 类型表示学生信息，也可使用 String + JSON 的方式来表示学生信息
- 即 具体 Redis 中的数据是如何组织的，都需根据实际的业务情况来决定
消息队列
- 生产者消费者模型
- 上图的 brpop 为阻塞操作
- 当列表为空时，brpop 命令便会阻塞等待，一直等到其他客户端向列表中 lpush 元素为止
重点理解：
- 此处只有一个消费者能抢到元素
通俗理解：
- 谁先执行的brpop 命令，谁就能拿到这个新 lpush 的元素
- 该设定便能很好的构成”轮询”效果
实例理解
- 假设此时列表为空，三个消费者（A、B、C）按顺序执行 brpop 命令进行阻塞等待
- 即执行顺序为 消费者A ——>消费者B ——> 消费者C
- 当有新元素到达列表时，该新元素将被 消费者A 获取，且 brpop 命令立即返回，标志着 消费者A完成了一次消费操作
- 若消费者A 想要继续消费，必须再次执行 brpop 命令
- 此时执行顺序变为消费者B——> 消费者C——> 消费者A
- 如果再有新元素到达，消费者B 将获取该元素，且 brpop 命令立即返回，标志着 消费者 B 完成了一次消费操作
总结：
- 上述实例所描述的这种轮询方式，即消费者们按照固定的顺序交替执行 brpop 命令
- 很好的实现了对阻塞队列的有序消费
频道（多列表）消息队列
- 多列表/频道 这种场景是比较常见的
实例理解
- 日常使用的程序，比如抖音
- 一个频道 用来传输短视频数据
- 一个频道 用来传输弹幕
- 还可以有多个频道，用来传输点赞、转发、收藏、评论数据
优点：
- 多频道模式 一定程度上保证了在某种数据发生问题的时候，不会对其他数据造成影响
- 具有一定的 解耦合 作用
微博 Timeline
- 每个用户都拥有属于自己的 Timeline（微博列表），现需要分页展示文章列表
- 此时便可以考虑使用列表，因为列表不但是有序的，且支持按照索引范围获取元素
实例理解
- 每篇微博使用 哈希结构存储
- 此处包含三个属性（title、timestamp、content）
hmset mblog:1 title xx timestamp 1476536196 content xxxxx...hmset mblog:n title xx timestamp 1476536196 content xxxxx
- 向用户 Timeline 添加微博，使用 List 类型
- 此处使用 user::mblogs 作为微博的键
lpush user:1:mblogs mblog:2 mblog:4...lpush user:k:mblogs mblog:n
- 分页获取用户的 Timeline
- 此处假设获取用户1 的前 5 篇微博
keylist = lrange user:1:mblogs 0 4for key in keylist { hgetall key}问题一：
- 当前一页中有多少数据是不确定，所以有可能会导致 for 循环比较大
- 从而会触发多次 hgetall 命令，即多次网络请求
解决方法：
- 使用 pipeline（流水线、管道）
- 虽然此处是多个 Redis 命令，但是通过 pipeline 我们可以将这些命令合并成一个 网络请求 进行通信
- 由此可以大大降低 客户端 和 服务器 之间的交互次数
问题二：
- lrange 在列表两端表现较好，获取列表中间的元素表现较差
解决方案：
- 将文章对应的 list 进行切分
- 假设某用户发布了1w 篇微博，则 list 的长度为1w
- 如果将这 1w 篇微博拆分成 10 份，即 每份1k 篇微博
- 此时如果想获取第 5k 篇左右的微博
- 即直接找到第五个列表，进行遍历即可
- 通过这样的拆分方式便能降低单个 list 的长度，并加快中间位置元素的查询速度
栈 & 队列
- 同侧存取（lpush+lpop 或 rpush+rpop）为栈
- 异侧存取（lpush+rpop 或 rpush+lpop）为队列
