Memcache和Redis的区别
- Memcache：代码层次类似Hash
- 支持简单数据类型
- 不支持数据持久化存储
- 不支持主从
- 不支持分片
- Redis
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
FD:File Descriptor,文件描述符：一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射
- Redis采用的IVO多路复用函数：epoll/kqueue/evport/select
- 优先选择时间复杂度为O（1)的I/O多路复用函数作为底层实现
- 以时间复杂度为O(n)的select作为保底
- 基于react设计模式监听I/O事件
- Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈
- Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争
- String：最基本的数据类型，二进制安全
- Hash：String元素组成的字典，适合用于存储对象
- List：列表，按照String元素插入顺序排序
- Set:String元素组成的无序集合，通过哈希表实现，不允许重复
- Sorted Set:通过分数来为集合中的成员进行从小到大的排序
- 用于计数的HyperLogLog，用于支持存储地理位置信息的Geo
从海量Key里查询出某一固定前缀的Key
- KEYS pattern：查找所有符合给定模式pattern的key
- SCAN cursor [MATCH pattern] [COUNT count]
- 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
- 以O作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
- 不保证每次执行都返回某个给定数量的元素，支持模糊查询
- 一次返回的数量不可控，只能是大概率符合count参数
如何通过Redis实现分布式锁
- 分布式锁需要解决的问题
- 互斥性
- 安全性
- 死锁
- 容错
SETNX key value:如果key不存在，则创建并赋值
- 时间复杂度：O（1)
- 返回值：设置成功，返回1；设置失败，返回0。
- EXPIRE key seconds
- 设置key的生存时间，当key过期时（生存时间为0），会被自动删除
- SET key value [EX seconds][PX milliseconds][NXIXX]
- EX second：设置键的过期时间为second秒
- PXmillisecond：设置键的过期时间为millisecond 毫秒
- NX：只在键不存在时，才对键进行设置操作
- XX：只在键已经存在时，才对键进行设置操作
- SET操作成功完成时，返回OK，否则返回nil
- 大量的key同时过期的注意事项
- 集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象
- 解放方案：在设置key的过期时间的时候，给每个key加上随机值
异步队列
- 使用List作为队列，RPUSH生产消息，LPOP消费消息
- 缺点：没有等待队列里有值就直接消费
- 弥补：可以通过在应用层引入Sleep机制去调用LPOP重试
- BLPOP key [key…] timeout:阻塞直到队列有消息或者超时
- 缺点：只能供一个消费者消费
- pub/sub：主题订阅者模式
- 发送者（pub)发送消息，订阅者（sub)接收消息
- 订阅者可以订阅任意数量的频道
- 缺点：消息的发布是无状态的，无法保证可达
持久化
RDB(快照）持久化：保存某个时间点的全量数据快照
- SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
- BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
- 通过lastsave 查看是否保存工程
- 自动化触发RDB持久化的方式
- 根据redis.conf配置里的SAVEmn定时触发（用的是BGSAVE)
- 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行Shutdown且没有开启AOF持久化
Bgsave
- 系统调用fork0：创建进程，实现了Copy-on-Write
- 如果有多个调用者同时要求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变
- 缺点
- 内存数据的全量同步，数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
AOF
AOF(Append-Only-File)持久化：保存写状态
- 记录下除了查询以外的所有变更数据库状态的指令
- 以append的形式追加保存到AOF文件中（增量）
- 日志重写解决AOF文件大小不断增大的问题，原理如下：
- 调用fork)，创建一个子进程
- 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
- 主进程持续将新的变动同时写到内存和原来的AOF里
- 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
- RDB和AOF的优缺点
- RDB优点：全量数据快照，文件小，恢复快
- RDB缺点：无法保存最近一次快照之后的数据
- AOF优点：可读性高，适合保存增量数据，数据不易丢失
- AOF缺点：文件体积大，恢复时间长
- RDB-AOF混合持久化方式
- BGSAVE做镜像全量持久化，AOF做增量持久化
Pipe
Pipeline和Linux的管道类似
Redis基于请求/响应模型，单个请求处理需要一一应答
Pipeline批量执行指令，节省多次I0往返的时间
有顺序依赖的指令建议分批发送
主从同步
全同步过程
- Salve发送sync命令到Master
- Master启动一个后台进程，将Redis中的数据快照保存到文件中
- Master将保存数据快照期间接收到的写命令缓存起来
- Master完成写文件操作后，将该文件发送给Salve
- 使用新的AOF文件替换掉旧的AOF文件
- Master将这期间收集的增量写命令发送给Salve端
增量同步过程 - Master接收到用户的操作指令，判断是否需要传播到Slave
- 将操作记录追加到AOF文件
- 将操作传播到其他Slave：1、对齐主从库；2、往响应缓存写入指令
- 将缓存中的数据发送给Slave
Redis Sentinel
解决主从同步Master宕机后的主从切换问题：
- 监控：检查主从服务器是否运行正常
- 提醒：通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移：主从切换
流言协议Gossip
- 每个节点都随机地与对方通信，最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递给所有节点，但是最终会趋于一致
Redis的集群原理
- 如何从海量数据里快速找到所需？
- 分片：按照某种规则去划分数据，分散存储在多个节点上
- 常规的按照哈希划分无法实现节点的动态增减
- 一致性哈希算法：对2^32取模，将哈希值空间组织成虚拟的圆环
- 将数据key使用相同的函数Hash计算出哈希值
- 引入虚拟节点解决数据倾斜的问题