本篇目录结构
一、Redis 数据结构
我对算法的理解
算法:找到最合适的数据结构保存数据,达到增、删、查的最优化;
二、使用场景
最常用的就是做缓存服务,防止请求都压倒数据库中。
2.1 场景一:消息通知,pub/sub
2.2场景二:分布式锁
2.3场景三:缓存服务
三、Redis 为什么这么快
redis 为什么能执行的这么快,原因记住两点就够了,全部内存操作,和比较好的线程模型(各种IO模型,一篇打尽)。
四、集群发展
4.1 哨兵模式
工作原理
当Master 宕机的时候,Sentinel 会选举出新的Master
并根据 Sentinel 中配置的内容,去动态修改VIP(虚拟IP),将VIP(虚拟IP)指向新的Master。
缺陷:
(1) 主从切换的过程中会丢数据
(2) Redis只能单点写,不能水平扩容
4.2 proxy 模式
Proxy目前有两种选择:Codis和Twemproxy
工作原理
1. 客户端使用Twemproxy+KeepAlived做代理,将其后端的多台 Redis 实例分片进行统一管理与分配
2. 每一个分片节点的 Slave 都是Master的副本且只读
3. Sentinel 持续不断的监控每个分片节点的 Master,当Master 出现故障且不可用状态时,Sentinel会通知/启动自动故障转移等动作
4. Sentinel 可以在发生故障转移动作后触发相应脚本,脚本获取到最新的Master来修改Twemproxy配置
缺陷
(1) 部署结构复杂
(2) 可扩展性差,进行扩缩容需要手动干预
(3) 运维不方便
4.3 cluster 模式(3.0原生支持)
工作原理
1.客户端与 Redis 直连,不需要中间Proxy层,直接连接任意一个Master节点
2.根据公式HASH_SLOT=CRC16(key) mod 16384,计算出映射到哪个分片上,然后Redis会去相应的节点进行操作
优点
(1)无需Sentinel哨兵监控,Redis Cluster 自动将Slave切换Master
(2)可以进行水平扩容
(3)支持自动化迁移
缺点
五、持久化方式
5.1 RDB模式
save 命令
阻塞当前Redis服务器,直到RDB过程完成为止,在Redis服务器阻塞期间,服务器不能处理任何命令的请求。
bgsave 命令
Redis进程执行fork操作创建子进程,RDB持久化由子进程负责,父进程(即Redis主进程)则继续处理请求
5.2 RDB的工作原理
5.3 RDB持久化机制的工作流程
流程:
1. Redis根据配置自己尝试去生成RDB快照文件。
2. Redis主进程fork一个子进程出来。
3. 子进程将数据dump到临时的RDB快照文件中。
4. 完成RDB快照文件的生成之后,就替换之前的旧的快照文件dump.rdb,每次生成一个新的快照,都会覆盖之前的老快照
5.4 AOF持久化
AOF持久化,类似 MySQL的Binlog。将Redis服务器执行的每次写命令记录到单独的日志文件中.
5.5 AOF 工作流程
1. 命令追加
所有的写入命令会追加到OS Cache,也就是AOF缓存区中。
2. 同步磁盘文件
AOF缓冲区根据不同的策略、调用操作系统的fsync操作将缓存区的数据同步到硬盘文件中。
3. 文件重写
六、RDB 和AOF 优缺点
RDB持久化机制的优点
1. 数据冷备
2. 数据恢复速度快:RDB是一份数据文件,恢复的时候,直接加载到内存中即可,不需要执行。
RDB持久化机制的缺点
1. 数据相对不完整
RDB数据快照文件,每隔一段时间,比如5分钟,或者更长时间生成一次,这个时候就得接受一旦redis进程宕机,那么会丢失最近5分钟的数据。
2. 性能问题
RDB每次在fork子进程来执行RDB快照数据文件生成的时候,如果数据文件特别大,可能会导致对客户端提供的服务暂停数毫秒甚至更久。
AOF持久化机制的优点
1. 最大可能保证数据完整性
AOF持久化机制可以更好的保护数据不丢失,一般AOF会每隔1秒,通过子线程执行fsync操作,一般最多丢失1秒钟的数据。
2. 写入性能高
AOF日志文件以append-only模式写入,所以没有任何磁盘寻址的开销,写入性能非常高。
3. AOF文件修复简单
redis-check-aof --fix命令修复。
AOF持久化机制的缺点
1. 文件大
AOF日志文件通常比RDB数据快照文件更大。
2.恢复慢
数据恢复速度相对较慢。