基本数据结构
String类型
String是Redis中最简单同时也是最常用的一个数据结构，它是一种二进制安全的数据结构，可以用来存储任何类型的数据比如字符串整数、浮点数、图片（图片的base64编码或者图片的路径）、序列化后的对象。
应用场景
需要存储常规数据的场景
- 缓存session
- token
- 图片地址
- 序列化后的对象（相比较于Hash存储更节约内存）
- 相关命令：GET、SET
需要计数的场景 - 用户单位时间的请求数（简单限流可用到）
- 页面单位时间的访问数
- 相关命令：SET、GET、INCR、DECR
分布式锁 - 利用
SETNX key value命令可以实现一个最简易的分布式锁（存在一些缺陷，通常不建议这样实现分布式锁）
常用命令
列表（List）
Redis列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或尾部（右边）
应用场景
信息流展示
- 最新文章
- 最新动态
- 相关命令：LPUSH、LRANGE。实现栈（先进后出）
- 相关命令：LPUSH、LPOP。实现队列（先进先出）
- 相关命令：RPUSH、LPOP
基本操作
哈希（Hash）
Redis中的Hash是一个String类型的键值对的映射表。特别适合用于存储对象，我们也可以直接修改对象中的某些字段值
应用场景
对象数据存储场景
- 用户信息
- 商品信息
- 文章信息
- 相关命令：HSET（设置单个字段的值）、HMSET（设置多个字段的值）、HGET（获取单个字段的值）、HMGET（获取多个字段的值）
购物车信息 - 相关命令：HSET（加购物车）、HINCR（加数量）、HLEN（获取所有商品数量）、HDEL（删除商品）、HGETALL（获取所有商品）
基本操作
集合（Set）
Redis中的Set类型是一种无序集合，集合中的元素唯一，也就是集合中的元素是无重复的，类似于Java中的HashSet
应用场景
需要随机获取数据源中的元素的场景
- 抽奖系统
- 随机
- 相关命令：SADD（加入抽奖系统）、SMEBERS（查看所有抽奖用户）、SPOP（随机获取集合中的元素并移除，适合不允许重复中奖的场景）
需要存放的数据不能重复的场景 - 文章点赞
- 动态点赞等场景
- 相关命令：SADD（点赞）、SREM（移除点赞）、SISMEMBER（检查用户是否点赞过）、SMEMBERS（获取点赞用户列表）
基本操作
有序集合（Sorted Set）
Sorted Set类似于Set，但和Set相比，Sorted Set增加了一个double类型的分数，使得集合中的元素能够按照分数进行有序排列
应用场景
需要随机获取数据源中的元素根据某个权重进行排序的场景
- 各种排行榜比如直播间送礼物的排行榜
- 朋友圈微信步数排行榜
- 王者荣耀中的段位排行榜
- 话题热度排行榜
- 相关命令：ZINCR（每点击一次进行加一）、ZREVRANGE（从大到小排序）、ZUNIONSTORE（多日搜索汇总）
基本操作
高级数据结构
位图（Bitmaps）
Bitmap存储的是连续的二进制数字（0和1），通过Bitmap，只需要一个bit位来表示某个元素对应的值或状态，key就是对应的元素本身。我们知道8个bit可以组成一个byte，所以Bitmap本身会极大的节省存储空间
应用场景
需要保存状态信息（0/1即可表示）的场景
- 用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）
- 相关命令：SETBIT、GETBIT、BITCOUNT、BITOP
基本操作
超日志（HyperLogLogs）
HyperLogLog是一种有名的基数计数概率算法，基于LogLog Counting（LLC）优化改进得来，并不是Redis特有的，Redis只是实现了这个算法并提供了一些开箱即用的API
Redis提供的HyperLogLog占用空间非常非常小，只需要12k的空间就能存储接近2^64个不同元素，并且Redis对HyperLogLog的存储结构做了优化，采用两种方式计数
- 稀疏矩阵：计数较少的时候，占用空间很小
- 稠密矩阵：计数达到某个阈值的时候，占用12k的空间
应用场景
数量巨大（百万、千万级别以上）的计数场景
- 热门网站每日/每周/每月访问ip数统计
- 热门帖子uv统计
- 相关命令：PFADD、PFCOUNT
基本操作
地理空间（Geospatial）
Geospatial index（地理空间索引，简称GEO）主要用于存储地理位置信息，基于Sorted Set实现。
通过GEO我们可以轻松实现两个位置距离的计算、获取指定位置附近的元素等功能。
基本操作
发布订阅（Pub/Sub）
Redis发布/订阅是一种消息传模式，其中发布者发送消息，而订阅者接受消息，传递消息的通道称为channel
应用场景
简易的实时消息传递场景（无法持久化）
- 聊天系统：用户发布的消息可以通过Redis的频道广播给所有订阅者，实现实时聊天系统
- 通知系统：例如在社交媒体平台上，当有新评论或新点赞时，可以通过Pub/Sub通知相关用户
基本操作
SUBSCRIBE:订阅给定的一个或多个频道的消息
PUBLISH：将消息发到指定的频道
Redis支持事务，但与其他数据库有所区别
- 原子性：Redis事务保证的是队列中的命令作为一个整体要么全部执行，要么全部不执行。但是，如果事务中的某个命令因为执行错误而失败，Redis会继续执行事务中的其他命令，而不是回滚整个事务。
- 无隔离级别：Redis事务中的命令在提交前不会被实际执行，因此不存在传统数据库中的事务隔离级别问题，如脏读、不可重复读或幻读
- 命令队列：当客户端发送multi命令后，所有随后的命令都会被放入一个队列中，而不是立即执行。当exec命令被发送时，Redis会尝试执行队列中的所有命令
- 乐观锁：Redis使用watch命令来实现乐观锁机制。客户端可以监控一个或多个键，如果在执行exec之前这些键的值被其他客户端改变，事务将不会执行。
- 自动放弃：如果事务因为监控键被修改而不能执行，exec命令将放弃当前队列命令，返回null
- discard命令：如果客户端在发送multi之后决定放弃事务，可以使用discard命令来清空事务队列并退出事务状态
- 有限的回滚：Redis事务不支持命令级别的回滚。如果事务中的某个命令失败，Redis会停止执行后续命令，而不是回滚到事务开始前的状态
| 阶段 | 检查什么 | 失败结果 |
|---|---|---|
| 命令解析阶段 | 命令是否存在 | 拒绝入队，事务可能污染 |
| 入队阶段 | 参数数量、格式 | EXEC时整个事务取消 |
| 执行阶段 | 数据状态、业务条件 | 只跳过失败命令，不回滚 |
Redis事务
概念
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。
常用命令
- multi：开启一个事务，multi执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中。
- exec：执行队列中所有的命令
- discard：中断当前事务，然后清空事务队列并放弃执行事务
- watch key1 key2 ...：监视一个（或多个)key,如果在事务执行之前这个（或这些）key被其他命令所改动，那么事务将被打断
RDB持久化
详细流程：
- 主进程fork出一个子进程。因为采用的是fork的方式，所以子进程的内存并非来自于主进程的复制。fork刚开始时，系统不会马上复制整个Redis内存。而是复制进程地址空间和页表。实际上仍是共同共享读取同一片内存空间，只是看起来像两份
fork主进程 子进程虚拟内存 虚拟内存| || |v v+---------+ +---------+| user=Tom| | user=Tom|+---------+ +---------+| age=20 | | age=20 |+---------+ +---------+
这里看起来像两份，实际上：
物理内存+---------+| user=Tom|+---------+| age=20 |+---------+↑两个进程共享读取
也就是说：
fork之后，初始状态下，两个进程读的是同一份物理内存。
- 子进程负责共享内存数据写入rdb文件中。而与此同时，主进程仍在不断接收到新的数据变更。这时候，为了避免干扰子进程，主进程采用Copy On Write(写入时才复制) 的方式，对受影响的数据复制到一块新的内存空间去，然后再做修改
原来：
物理页+---------+| age=20 |+---------+↑+-----+-----+| |主进程 子进程
主进程想修改：
age=30
Linux发现：这个页被两个进程共享。于是复制一份：
物理内存+---------+| age=20 |+---------+↑子进程+---------+| age=30 |+---------+↑主进程
现在子进程：
age=20
主进程：
age=30
- 等待子进程完成RDB文件的写入后，会将新的RDB文件替换掉旧的RDB文件。
注：RDB文件中存的是当前时刻下的快照，也就是全部数据。
优缺点
优点
- 性能高
- 文件紧凑
缺点 - 容易丢数据
AOF持久化
详细流程
- Redis将“写”操作放入到AOF缓冲区
- AOF缓冲区根据不同配置，将缓冲区内所有“写”操作追加写入到AOF日志文件中。其中常见的配置有三种
- 实时同步：AOF缓冲区每接收到一条写命令立即追加写入AOF日志文件中。但这样可能会导致性能浪费。
- 固定间隔同步：设置固定间隔（常见为1s），每隔一段时间，将AOF缓冲区内容追加写入AOF日志文件。最多只会造成一秒的数据丢失。生产常用
- 系统自动调配同步：由操作系统决定什么时候写入AOF日志文件。但这样可能会造成严重的数据丢失
- AOF日志文件重写：
- 作用：压缩AOF文件，不再存储无用指令。如Redis在某个时段把a设为了1，然后后面由执行了INCR。则实际只需要记录a=2这个最终结果即可，减少无用命令。值得注意的是，AOF重写不是压缩旧的AOF文件，而是根据当前内存状态，重新生成一个新的AOF文件
- 触发时机：
-
自动触发（生产环境主要方式）在Redis的配置文件中。
auto-aof-rewrite-percentage 100 换行 auto-aof-rewrite-min-size 64mb。两个条件同时满足会触发重写条件1：AOF文件达到配置的最小大小。即超过指定大小会触发
auto-aof-rewrite-min-size 64mb：AOF至少达到64MB条件2：增长比例达到阈值
auto-aof-rewrite-percentage 100:当前AOF大小超过上次重写后大小的100%。即：当前AOF大小 >= 上次重写大小 × (1 + percentage/100) -
手动触发：管理员可以执行
BGREWRITEAOF命令手动触发
-
AOF的优缺点
优点
- 数据更可靠
缺点 - 文件较大
- 恢复速度较慢