分布式事务全局一致性 全局时钟(Global Timestamp) 全局时钟在分布式数据库中的作用是通过提供统一的时间参考,确保系统内各组件协同工作时的时间同步,从而保障数据的一致性和系统的正确运行。如下为全局时钟的架构和分布式并发记录结构。 由GTM提供全局唯一的事务id和全局事务快照。当事务执行时,会话携带全局事务id,各节点通过全局事务id来判断数据的可见性。 全局时钟通过分布式并发记录来保障各组件协同工作时的时间同步。分布式并发控制核心点如下: 1. 逻辑时钟从零开始内部单向递增且唯一,由GTM维护,定时和服务器硬件计数器对齐,从而保证时钟源稳定。 2. 多个GTM节点构成集群,主节点对外提供服务;主备之间通过日志同步时间戳状态,保证GTS核心服务可靠性。 3. 单台物理机每秒能够处理1200万QPS,几乎满足所有业务场景。 4. 段页式存储的MVCC是整个并发控制的基础。同时约定:事务的gtsstart > gtsmin并且gtsmax没有提交或者gtsstart < gtsmax才能看到对应的事务。 两阶段提交(Two Phase Commit) 分布式事务执行时,由CN节点发起两阶段提交事务,并协调其它节点(参与者)执行事务,经过表决、执行两个阶段各参与者返回的状态,决定分布式事务需要提交或回滚。 两阶段提交被认为是一种一致性协议,用来保证分布式系统数据的一致性。绝大部分的关系型数据库都是采用两阶段提交协议来完成分布式事务处理。 两阶段提交事务在执行时分为两个阶段,第一阶段为表决阶段Prepare,第二阶段为执行阶段Commit,由协调者发起,并根据所有参与者返回的状态,判断是否需要执行下一阶段,Commit提交或回滚事务。 1. 表决阶段Prapare:所有参与者都将本事务能否成功的信息反馈发给协调者。 2. 执行阶段Commit:协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚。 两阶段提交机制的潜在问题: 1. 数据不一致问题:当部分参与者故障,各参与者在两阶段提交事务中的状态就会出现不一致的情况,如:部分节点commit,部分prepare,或部分commit,部分rollback,这都会导致该事务更新的数据在所有参与者中出现不一致。 2. 同步阻塞问题:两阶段提交过程中的一些步骤是同步阻塞的,没有超时机制,可能会有长时间阻塞的问题。同时,如果异常时,有prepare状态的两阶段事务残留,残留事务仍会持有锁,会阻塞后续会话对这些数据的访问和更新。 3. 协调节点单点故障问题:如果协调节点故障后短时间不能恢复,参与者的两阶段事务会一直残留,导致出现数据不一致、资源阻塞的问题。 TeleDB在内核处理机制,以及异常处理两个角度,对两阶段提交进行了优化,确保在两阶段事务异常时能自动恢复,不会出现上述问题。 内核处理机制优化 在两阶段事务执行过程中记录信息,用于异常时恢复残留的两阶段事务; 避免进入“Commit Prepared”的两阶段事务在所有参与节点被回滚。 分布式死锁检测模块:该模块对数据库状态进行实时监测,当发现存在长时间等待依赖时自动开启分布式死锁检测,经过节点间信息传递和算法分析可快速检测并解除死锁环。检测算法不影响系统查询效率,用户对死锁检测过程无感知。分布式死锁主要分为四个模块,分别为锁等待依赖关系的管理、线程模型模块、检测算法模块和监控与追踪模块。 锁等待依赖关系的管理:对分布式数据库中出现的长时间等待事务依赖对进行检测与上报。 线程模型模块:包含DDS专用线程工作模式和方法的设计、实现。 检测算法模块:分布式死锁检测的执行算法,根据上游节点发送的消息进行两阶段算法推演,再发送消息给下游节点。 监控与追踪模块:包含DDS依赖消息产生和传播的追踪日志、各节点依赖可视化、最近死锁记录保存。 其优点是内核原生支持、自动检测并解锁、分布式算法,需要传输的信息量少、网络资源消耗少、解锁速度快、无死锁误判、支持优先级解锁和抗丢包性强。 异常处理优化:提供两阶段事务的自动处理插件,在监测到两阶段事务残留时,通过访问两阶段事务执行过程中记录的信息,来判断各个参与节点的状态,根据状态参照对应规则,对残留事务进行清理,恢复各节点数据到全局一致。 PREPARED状态 COMMIT状态 ROLLBACK状态 异常阶段及原因 动作 有 有 无 commit阶段异常参与节点故障 COMMIT剩余事务 有 无 有 prepare阶段异常参与节点宕机 ROLLBACK剩余事务 有 无 无 prepare阶段异常发起节点宕机 ROLLBACK剩余事务