分布式基础概念-分布式缓存[3]

Redis主从同步机制

1. 从节点执行slaveof masterIp port，保存主节点信息
2. 从节点中的定时任务发现主节点信息，建立和主节点的socket连接
3. 从节点发送信号，主节点返回，两边能互相通信
4. 连接建立后，主节点将所有数据发送给从节点（数据同步）
5. 主节点把当前的数据同步给从节点后，便完成了复制过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

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部分复制

1. 复制偏移量：psync runid offset
2. 复制积压缓冲区：当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。
   1. 如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；
   2. 如果从节点保存的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解决

1. 顺序向五个节点请求加锁
2. 根据一定的超时时间来推断是不是跳过该节点
3. 三个节点加锁成功并且花费时间小于锁的有效期
4. 认定加锁成功

往期精彩系列推荐

• 对线面试官系列
• 分布式基础概念系列

我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！