请教问题：
1、分布式事务提交过程中从节点未成功写入write cf，重启后的事务补偿是在读取相应记录时还是后台定期进行检查进行补偿的？
2、lock cf和write cf的清理策略是什么？
1 个赞
如果是 “提交过程中挂掉”的情况，通常是重启后由后台或协调者主动发起恢复
3 个赞
lock cf 主动释放 + 超时回收，write cf 靠 GC 清理。
3 个赞
Lock CF 中的锁是临时状态，不会长期保留 ，任何情况下的事务完成 / 超时都会触发锁的清理；
Write CF 的清理是异步、基于GC safe point版本记录机制 ，保证 MVCC 多版本读的同时，逐步清理过期垃圾数据。
1 个赞
如果主节点是基于GC，为了保证备节点未决事务岂不是还要查询各个可能的备节点的write cf，这样是不是会很影响效率？希望有大佬把详细的处理流程解析一下。
感谢分享，这个问题很典型，解决方案很实用！
照理说,悲观锁过程中间宕机的话,重启之后锁和数据的相关cf不丢失吧
我感觉保证不丢失的话，GC要做很多工作才行，主节点如果不加判断的直接清理肯定会问题，内部的细节不是很清楚
有没有比较详细的执行过程资料参考？
感谢老师分享
Write CF 存储了数据的多版本控制信息（MVCC）。随着时间推移，旧版本的数据会变成“垃圾”，需要通过 GC（垃圾回收）来清理，以释放物理空间
从节点未写入 write CF 时，事务补偿主要在读取该记录时触发 resolve lock ，后台 GC 仅作为兜底清理长时间残留的锁。
我意思就是想问主节点GC如果要保证从节点不丢数据清理时还要每个节点都要去查一下吗？
事务补偿的核心是 “Primary 锁为准”，读取触发是主要方式，后台检查仅兜底
Lock CF 清理优先即时删除，过期锁靠 GC 兜底，Write CF 清理核心是 MVCC GC，保留最新版本
数据库所有清理策略都兼顾 “数据一致性” 和 “资源释放”，避免误删导致事务异常
CF是Column Family缩写?
数据库会定期计算一个Safe Point, 只有事务都完成才会推进,才会删除
是这个意思