核心特性

• 高可用性和强性能：锁的获取与释放必须高效且可靠，无论是主从架构还是高可用性集群都需防止资源不可用。
• 非阻塞与可重入：支持非阻塞锁机制，避免死锁风险，确保可重入性。
• 自动释锁机制：应具备锁失效保护机制，防止死锁和资源泄漏。
• 原子性操作：采用Redis脚本实现原子性操作，确保多步骤操作的完全性。

技术实现

• Redis作为传统的分布式锁实现之一，提供了可靠的锁机制，但需注意过期时间的管理和锁续期问题。
• RedissonLock提供了完整的封装，简化了锁的使用流程，适合高性能和高可用性需求的场景。
• 在主从架构下，需谨慎考虑锁的高可用性，避免因网络延迟或故障导致锁无法及时释放。

权衡与选择

• 对于对高可用性有极高要求的场景，建议选择基于RedissonLock的实现方案，配备兜底机制。
• 对于追求更高一致性和容错能力的场景，可以考虑ZooKeeper的实现方案。

工作流程

• 日志复制：所有节点都维护一个日志列表，记录操作请求。日志采用指数增长策略，确保旧日志的及时清理。
• 角色分工：系统中始终只有一个Leader角色，其余均为Follower。Leader职责包括接收请求、分发给Follower，并管理集群状态。

两阶段提交

• 阶段一：Leader接收请求并记录日志后，将该操作提交给所有Follower。
• 阶段二：如果超过半数的Follower复制成功，Leader提交操作，通知所有节点提交相关日志。

优势保证

• 完备复制：经过多数节点复制后，数据在所有节点均有冗余备份，确保数据不丢失。
• 严格的一致性：每个节点的日志状态要么完全一致，要么可以通过后续同步自动修复。

定时器的作用

• 每个节点设置定时器，定时器超时即表示没有有效的Leader存在。
• 当节点未收到Leader消息时，触发自我转换为Candidate请求，进入选举状态。

选举流程

• 自动转换：节点在保管能力一段时间后转换为Candidate，竞争成为Leader。
• 投票请求：Candidate向其余节点发送投票请求，承诺持有最新的日志信息。
• 投票计数：若某Candidate获得超过半数支持，则成为新的Leader，其他节点转换为Follower，并重置定时器。

应对选举冲突

• 若多数节点同时成为Candidate，需随机设置不同定时器时间，避免同时触发多次选举请求。
• 集群进入新的选举周期，直到解决冲突并产生唯一的Leader。

任期生成

• 每次选举后，Leader的任期自动递增，并通知所有节点更新自身的任期信息。
• 任期信息是一个递增的数，因此收到过期消息时可直接丢弃。

信息的有效性

• 节点在接收到信息时，首先检查消息的任期是否高于自己的任期。如果消息过期，则直接拒绝处理。
• 关键日志条目标记其任期信息，确保日志同步过程中的一致性。

投票规则

• 每个节点只能投给拥有相同或更晚日志条目的Candidate。
• 投票过程中，日志条目的一致性和更新性是核心保证。

具体流程

• 节点在接收到RequestVote请求时，首先检查请求的任期信息。
• 比较当前日志条目与请求中包含的日志信息，决定是否进行投票。
• 若拒绝投票，返回失败状态，避免无法完成的操作产生不一致。

避免并发

• 若两个节点同时成为Candidate，可能导致双节点均获得较多的投票。
• 必须设置不同的定时器时间，避免多个节点同时尝试成为Leader，导致选举失败。

时间跨度设置

• 定时器时间应稍长于心跳间隔，确保正常情况下不会出现多个节点自想当成Leader。
• 惼_verified_,，可参考150-300ms的范围，具体数值可根据网络延迟和集群规模进行调整。

日志复制

• Leader发送日志追加请求（AppendEntries）给所有Follower。
• Follower接收到请求后，首先验证请求的有效性（如任期、日志一致性等），再根据日志状态进行相应处理。

日志提交

• 复制成功后，Leader会将当前操作提交至自身日志列表，并通知Follower进行提交操作。
• 假如出现Follower节点故障，且无法接收到新的日志，原有的日志复制任务会自动重试，确保数据一致性。

• 系统设计简洁，易于理解和维护。

• 可以在较多节点故障的情况下保持系统稳定运行。

• 强大的日志同步机制，确保所有节点的数据一致性。