缓存中间件-Memcache和Redis的区别
Memcache：代码层次类似Hash
- 支持简单数据类型
- 不支持数据持久化存储
- 不支持主从（主从服务器复制）
- 不支持分片
Redis：
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
Redis数据类型
- string：最基本的数据类型，二进制安全
- hash：String元素组成的字典，适合用于存储对象
- list：列表，按照String元素插入顺序排序
- set：无序集合，通过哈希表实现，不允许重复
- zset ：有序集合
Redis为何这么快
- 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
- 数据结构简单，对数据操作也简单
- 采用单线程，单线程也能处理高并发请求，想要多核也可启动多Redis实例
- 使用多路I/O复用模型，非阻塞IO
从海量Key里查询出某一固定前缀的Key
-
方法一：
使用KEYS pattern命令：查找所有符合给定模式pattern的key
例如查找前缀为he的key：keys he*
特点：- KEYS指令一次性返回所有匹配的key，速度很慢
- 键的数量过大会使服务卡顿（影响线上项目运行速度）
-
方法二：
使用scan cursor [MATCH pattern] [COUNT count] 命令
例如查找前缀为he的key：scan 0 [MATCH he*] [COUNT 4]
表示的是返回前4个he*前缀的key
特点：- 基于游标的迭代器，以0作为游标起点
- 不保证每次执行都返回给定数量的元素，支持模糊查询
因此采用scan命令进行海量数据查询，查询快速，不会造成服务卡顿。
如何通过Redis实现分布式锁
分布式锁需要解决的问题：
- 互斥性
- 安全性
- 死锁
- 容错
Redis数据持久化
-
RDB（快照）持久化：保存某个时间点的全量数据快照
- SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
- BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
-
AOF（Append-Only-File）持久化：保存写状态
- 记录下所有变更数据库状态的指令
- 以append的形式追加保存到AOF文件中（增量）
-
RDB和AOF的优缺点
- RDB优点：全量数据快照，文件小，恢复快。
- RDB缺点：无法保存最近一次快照之后的数据
- AOF优点：可读性高，适合保存增量数据，数据不易丢失
- AOF缺点：文件体积大，恢复时间长
-
RDB-AOF混合持久化方式：
- BGSAVE做镜像全量持久化，再使用AOF重放快照之后的操作指令来做增量持久化。
Redis数据的恢复
在RDB和AOF文件共存情况下的恢复流程：
- 先查看AOF文件是否存在，如果存在就加载AOF文件进行恢复
- 如果AOF文件不存在，则查看RDB文件是否存在，存在则加载RDB文件进行回复