秋招Java后端开发冲刺——非关系型数据库篇（Redis）
一、非关系型数据库
1. 主要针对的是键值、文档以及图形类型数据存储。
2. 特点：
| 特点 | 说明 |
|---|---|
| 灵活的数据模型 | 支持多种数据模型（文档、键值、列族、图），无需预定义固定的表结构，能够处理各种类型的数据。 |
| 高扩展性 | 设计为水平扩展，能够轻松地通过增加更多节点来处理大量的数据和高并发请求。 |
| 高性能 | 通过优化特定类型的查询和数据操作，通常比关系型数据库在大规模数据处理时表现更好。 |
| 分布式架构 | 天生支持分布式存储和计算，能够跨多个节点和数据中心实现数据的分布和冗余。 |
| 弱一致性 | 为了提高性能和可用性，通常采用最终一致性模型，而不是关系型数据库的强一致性模型。 |
| 灵活的事务支持 | 事务支持通常较为灵活，有些NoSQL数据库提供有限的事务支持，有些则支持ACID事务。 |
| 易于使用 | 简单的API接口和查询语言，使开发者能够快速上手和使用。 |
| 丰富的类型支持 | 能够存储和处理多种数据类型，包括JSON、XML、二进制数据等。 |
| 高可用性 | 通过数据复制和分区，实现高可用性和数据冗余，保证系统在部分节点失效时仍能正常运行。 |
| 适应多种应用场景 | 特别适合于大数据分析、实时应用、社交网络、物联网等需要处理大量非结构化数据的场景。 |
3. 代表：HBase、Cassandra、MongoDB、Redis
二、Redis
Redis是一个基于 C 语言开发的开源 NoSQL 数据库，使用key-value键值对存储数据，且由于其数据存储在内存中，速度很快，在开发中使用广泛。
（一）数据类型
1. 五种基础数据类型
五种基础数据类型包括：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）
- String：是一种二进制安全的数据类型，常用于缓存 Session、Token、图片地址、序列化后的对象,用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数
- List：使用一个双向链表实现，常用于实现最新文章、最新动态、消息队列
- Hash：是一个 String 类型的 field-value（键值对） 的映射表，内部实现：数组 + 链表，常用于存储对象
- Set：是一种无序集合，实现了求交集、并集、差集等操作，常用于网站 UV 统计、文章点赞、动态点赞等场景；共同好友(交集)、共同粉丝(交集)、共同关注(交集)、好友推荐（差集）、音乐推荐（差集）、订阅号推荐（差集+交集） 等场景；抽奖系统、随机点名等场景
- Sorted Set：增加了一个权重参数 score，底层使用跳表实现，使得集合中的元素能够按 score 进行有序排列，常用于各种排行榜，优先级任务队列
2. 三种特殊数据类型
包括：HyperLogLog（基数统计）、Bitmap （位图）、Geospatial (地理位置)
- Bitmap：存储的是连续的二进制数字（0 和 1），常用于用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。
- HyperLogLog：是一种有名的基数计数概率算法，常用于数据量巨大的统计场景：热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计等
- Geospatial index（地理空间索引，简称 GEO）：基于 Sorted Set 实现，主要用于存储地理位置信息。
3. 其他数据类型
包括： Bloom filter（布隆过滤器）、Bitfield（位域）
- Bloom filter（布隆过滤器）：由一个初始值为零的bit数组和多个哈希函数构成，用来快速判断集合中是否存在某个元素，常用于解决缓存穿透问题
- Bitfield（位域）：是一种对Redis中的字符串类型进行扩展的数据类型，用于对字符串中任意偏移进行修改等操作。
（二）应用
（三）常见面试问题
1. 为什么快
- Redis 基于内存存储数据，内存的访问速度比磁盘快很多
- Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，使用IO多路复用+事件派发来处理多个socket
- Redis是单线程的，避免线程间的切换（Redis6.0之后命令回复处理器、命令请求处理器使用了多线程，命令执行还是使用的单线程）
- Redis 内置了多种优化过后的数据类型/结构实现，性能非常高
- Redis 通信协议实现简单且解析高效
2. 缓存读写策略
（1）Cache Aside Pattern（旁路缓存模式）
- 读数据：从 cache 中读取数据，读取到就直接返回；否则从 db 中读取数据返回，再把数据放到 cache 中
- 写数据：先更新db，再删除缓存
（2）Read/Write Through Pattern（读写穿透）（以cache服务器为主）
- 读数据：从 cache 中读取数据，读取到就直接返回 ；否则先从 db 加载，写入到 cache 后返回响应
- 写数据：先查 cache，cache 中不存在，直接更新 db；cache 中存在，则先更新 cache，然后 cache 服务自己更新 db
（3）Write Behind Pattern（异步缓存写入）
- 只同步更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db
- db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量
3. key过期删除策略
- 惰性删除：使用时才检查删除（内存消耗大）
- 定期删除：周期性地随机从设置了过期时间的 key 中抽查一批，然后逐个检查这些 key 是否过期，过期就删除 key（周期时间确定较难）
- 延迟队列：把设置过期时间的 key 放到一个延迟队列里，到期之后就删除 key（需要额外的资源维护队列）
- 定时删除：每个设置了过期时间的 key 都会在设置的时间到达时立即被删除（每个key都要维护一个定时器，资源消耗大）
注：Redis采用惰性+定期删除的方式
4. Redis 的内存淘汰策略（内存不足时触发）
- volatile-lru（least recently used）：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
- volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰
- volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
- volatile-lfu（least frequently used）：从已设置过期时间的数据集中挑选最不经常使用的数据淘汰
- allkeys-lru（least recently used）：从数据集中移除最近最少使用的数据
- allkeys-random：从数据集中任意选择数据淘汰。
- allkeys-lfu（least frequently used）：从数据集中移除最不经常使用的数据淘汰
- no-eviction（默认内存淘汰策略）：不淘汰数据，当内存不足以容纳新写入数据时，新写入操作会报错
5. 生产问题（缓存三兄弟）
（1）缓存穿透
- 请求的 key 不存在于缓存中，会导致大量查询请求直接到了数据库，导致数据库崩溃
- 解决方式：
① 缓存无效值（内存不友好）
② 布隆过滤器（使用一个较大的 bit 数组来保存所有可能请求的key的哈希值，每次请求时计算key对应的哈希值，如果哈希值对应的位置为true才去缓存中查找）
（2）缓存击穿
- 请求的key对应的是热点数据 ，但缓存中的那份数据已经过期，导致大量请求落在数据库上
- 解决方法：
① 设置热点数据永不过期或者过期时间比较长（内存不友好）
② 提前预热（推荐）：针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期
③ 加锁：在缓存失效后，通过设置互斥锁确保只有一个请求去查询数据库并更新缓存
（3）缓存雪崩
- 缓存中的key在同一时间大量失效，导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力/Redis服务器宕机
- 解决方式：
① key设置随机失效时间
② 提前预热
③ 多级缓存：设置多级缓存，例如本地缓存+Redis 缓存的二级缓存组合
④ Redis 集群：采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用
6. Redis集群
（1）主从复制
- 主节点写，多个从节点读
- 主从数据同步原理
① 全量同步：初始同步都采用全量同步
② 增量同步：一般是slave重启或者后期数据变化
- 实现高并发
（2）哨兵模式
- 使用哨兵检测集群中各个服务器的状态（心跳机制），并在主节点宕机后重新选择主节点
- 哨兵选主规则：优先级、与主节点断开时间（小）、offset值（大）、id(小)
- 可能会出现脑裂问题（网络问题导致），解决方法是：设置最少的从节点数量/缩短主从数据同步的延迟时间/达不到要求就拒绝请求
- 实现高可用
（3）分片集群
- 多个master、多个slave，多个master之间通过ping检测彼此健康状态；客户端请求可以访问任意节点，最终会根据Redis中的路由转发到正确节点
- 实现海量数据存储，以及高并发写
7. 持久化机制
（1）快照RDB
- 通过创建快照来获得存储在内存里面的数据在某个时间点上的副本
- 优点：
① RDB 文件存储的内容是经过压缩的二进制数据，文件很小，适合做数据的备份，灾难恢复
② 使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快
- 实现原理：bgsave命令开始时主进程会fork一个子进程，子进程复制主进程的页表，将对应的内存数据写入磁盘
- 对数据丢失容忍度更高，追求启动速度
（2）只追加文件AOF
- 将每一条Redis执行命令写入到 AOF 缓冲区中，然后再写入到 AOF 文件中，最后根据持久化方式（ fsync策略）的将系统内核缓存区的数据同步到硬盘中
- 优点
① 实时性更好
② AOF 以一种易于理解和解析的格式包含所有操作的日志，可以直接进行操作和分析
- 对数据的安全性、完整性要求更高
- 持久化策略
① appendfsync always：主线程调用 write 执行写操作后，后台线程（ aof_fsync 线程）立即会调用 fsync 函数同步 AOF 文件（刷盘），fsync 完成后线程返回
② appendfsync everysec：主线程调用 write 执行写操作后立即返回，由后台线程（ aof_fsync 线程）每秒钟调用 fsync 函数（系统调用）同步一次 AOF 文件
③ appendfsync no：主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步刷盘
- AOF文件重写（当文件较大时）：由一个子进程将数据库状态写入新的AOF文件中，重写期间，Redis 还会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾。
注：该操作不不需要对原有AOF文件进行任何的读取，写入，分析
（3）混合方式
- AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头
- 优点：可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据
- 缺点：AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差
8. Redis实现延时
（1）Redis 过期事件监听
- 原理：在pub/sub 模式下，监听 key 的过期事件 channel，就可以拿到过期的 key 的消息，进而实现了延时任务功能
- 存在问题
① 时效性差，key过期后的删除是惰性删除+定期删除结合，而这个发布者是要在key删除时才发布消息到channel
② 丢消息：当没有订阅者时，消息会被直接丢弃，在 Redis 中不会存储该消息
③ 多服务实例下消息重复消费
（2）Redisson 内置的延时队列
- 原理：基于 Redis 的 SortedSet 来实现，将需要延迟执行的任务插入到 SortedSet 中，并给它们设置相应的过期时间作为分数，Redisson 使用 zrangebyscore 命令扫描 SortedSet 中过期的元素，然后将这些过期元素从 SortedSet 中移除，并将它们加入到就绪消息列表中
9. Redis实现分布式锁
（1）SETNX（SET if Not eXists）命令实现分布式锁
（2）使用Redisson实现的分布式锁
- 基于lua脚本完成加锁、设置过期时间等操作，使用watch-dog给锁续期
- 不能实现主从一致性，使用红锁可以，但性能极差
