Redis主从同步机制
- 从节点执行slaveof masterIp port,保存主节点信息
- 从节点中的定时任务发现主节点信息,建立和主节点的socket连接
- 从节点发送信号,主节点返回,两边能互相通信
- 连接建立后,主节点将所有数据发送给从节点(数据同步)
- 主节点把当前的数据同步给从节点后,便完成了复制过程。接下来,主节点就会持续的把写命令发送给从节点,保证主从数据一致性。
runId:每个redis节点启动都会生成唯一的uuid,每次redis重启后,runId都会发生变化。
offset:主从节点各自维护自己的复制偏移量offset,当主节点有写入命令时,offset=offset 命令的字节长度。从节点在收到主节点发送的命令后,也会增加自己的offset,并把自己的offset发送给主节点。主节点同时保存自己的offset和从节点的offset,通过对比offset来判断主从节点数据是否一致。
repl_backlog_size:保存在主节点上的一个固定长度的先进先出队列,默认大小是1MB。
全量复制
- 从节点发送psync命令,psync runid offset(由于是第一次,runid为?,offset为-1)
- 主节点返回FULLRESYNC runId offset,runId是主节点的runId,offset是主节点目前的offset。从节点保存信息
- 主节点启动bgsave命令fork子进程进行RDB持久化
- 主节点将RDB文件发送给从节点,到从节点加载数据完成之前,写命令写入缓冲区
- 从节点清理本地数据并加载RDB,如果开启了AOF会重写AOF
部分复制
- 复制偏移量:psync runid offset
- 复制积压缓冲区:当主从节点offset的差距过大超过缓冲区长度时,将无法执行部分复制,只能执行全量复制。
- 如果从节点保存的runid与主节点现在的runid相同,说明主从节点之前同步过,主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况);
- 如果从节点保存的runid与主节点现在的runid不同,说明从节点在断线前同步的Redis节点并不是当前的主节点,只能进行全量复制。
过程原理
image.png
简述Redis事务实现
事务开始
MULTI命令的执行,标识着一个事务的开始。MULTI命令会将客户端状态的flags属性中打开REDIS_MULTI标识来完成的。
命令入队
当一个客户端切换到事务状态之后,服务器会根据这个客户端发送来的命令来执行不同的操作。如果客户端发送的命令为MULTI、EXEC、WATCH、DISCARD中的一个,立即执行这个命令,否则将命令放入一个事务队列里面,然后向客户端返回QUEUED回复
- 如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个,那么服务器立即执行这个命令。
- 如果客户端发送的是四个命令以外的其他命令,那么服务器并不立即执行这个命令。首先检查此命令的格式是否正确,如果不正确,服务器会在客户端状态(redisClient)的flags属性关闭REDIS_MULTI标识,并且返回错误信息给客户端。如果正确,将这个命令放入一个事务队列里面,然后向客户端返回QUEUED回复
事务队列是按照FIFO的方式保存入队的命令
事务执行
客户端发送EXEC命令,服务器执行EXEC命令逻辑。
- 如果客户端状态的flags属性不包含REDIS_MULTI标识,或者包含REDIS_DIRTY_CAS或者REDIS_DIRTY_EXEC标识,那么就直接取消事务的执行。
- 否则客户端处于事务状态(flags有REDIS_MULTI标识),服务器会遍历客户端的事务队列,然后执行事务队列中的所有命令,最后将返回结果全部返回给客户端;
Redis不支持事务回滚机制,但是它会检查每一个事务中的命令是否错误。
Redis事务不支持检查那些程序员自己逻辑错误。例如对String类型的数据库键执行对HashMap类型的操作!
- WATCH命令是一个乐观锁,可以为Redis事务提供check-and-set(CAS)行为。可以监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执行,监控一直持续到EXEC命令。
- MULTI命令用于开启一个事务,它总是返回OK。MULTI执行之后,客户端可以继续向服务器发送任意多条命令,这些命令不会立即被执行,而是被放到一个队列中,当EXEC命令被调用时,所有队列中的命令才会被执行。
- EXEC:执行所有事务块内的命令。返回事务块内所有命令的返回值,按命令执行的先后顺序排列。当操作被打断时,返回空值nil。
- 通过调用DISCARD,客户端可以清空事务队列,并放弃执行事务,并且客户端会从事务状态中退出。
- UNWATCH命令可以取消watch对所有key的监控。
简述Redis有哪些数据结构
- String:字符串
- List:列表
- Hash:哈希表
- Set:无序集合
- Sorted Set:有序集合
- bitmap:布隆过滤器
- GeoHash:坐标,借助Sorted Set实现,通过zset的score进行排序就可以得到坐标附近的其它元素,通过将score还原成坐标值就可以得到元素的原始坐标
- HyperLogLog:统计不重复数据,用于大数据基数统计
- Streams:内存版的kafka
数据库实现分布式锁的问题及解决方案
利用唯一约束键存储key,insert成功则代表获取锁成功,失败则获取失败,操作完成需要删除锁
问题:
- 非阻塞,锁获取失败后没有排队机制,需要自己编码实现阻塞,可以使用自旋,直到获取锁
- 不可重入,如果加锁的方法需要递归,则第二次插入会失败,可以使用记录线程标识解决重入问题
- 死锁,删除锁失败、则其他线程没办法获取锁,可以设置超时时间、使用定时任务检查
- 数据库单点故障,数据库高可用
Redis分布式锁实现
setnx setex:存在设置超时时间失败的情况,导致死锁
set(key,value,nx,px):将setnx setex变成原子操作
问题:
- 任务超时,锁自动释放,导致并发问题。使用Redisson解决(看门狗监听,自动续期)
- 以及加锁和释放锁不是同一个线程的问题。在value中存入uuid(线程唯一标识),删除锁时判断该标识(使用lua保证原子操作)
- 不可重入,使用redisson解决(实现机制类似AQS,计数)
- 异步复制可能造成锁丢失,使用redLock解决
- 顺序向五个节点请求加锁
- 根据一定的超时时间来推断是不是跳过该节点
- 三个节点加锁成功并且花费时间小于锁的有效期
- 认定加锁成功
往期精彩系列推荐
- 对线面试官系列
- 分布式基础概念系列