分布式基础概念 - 分布式缓存 [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 的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。

3. 如果从节点保存的 runid 与主节点现在的 runid 相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看 offset 和复制积压缓冲区的情况)；

4. 如果从节点保存的 runid 与主节点现在的 runid 不同，说明从节点在断线前同步的 Redis 节点并不是当前的主节点，只能进行全量复制。

过程原理

简述 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. 认定加锁成功

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或关注微信公众号【码上遇见你】。