GTM 仅处理全局时间戳请求, 64位CSN递增,几乎都是CPU ++和消息收发操作。不是每次都写ETCD, 而是采用定期持久化到ETCD 里, 每次写ETCD的CSN要加上一个backup_step (100w), 一旦GTM故障,CSN从ETCD读取出来的值保证单调递增。当前GTM 只完成CSN++, 预估可以支持200M/s 请求。GTM处理获取csn消息和csn++的消息, TCP 协议栈消耗CPU会非常严重,采用用户态协议栈提高GTM单节点的处理能力。未来架构演进完全去中心化,采用高精度时钟解决扩展性问题。
5.1 单节点的事务
图2 单节点事务处理
流程关键设计:GTM 只维护一个CSN++, snapshot 只包含CSNDN 本地维护事务id, 维护id到CSN的映射(CSN_LOG)DN 本地GC的过程中回填CSN单shared读事务使用local snapshot:get local latest CSN + get prepared_xidwait csn commit in process(same as before)如果row.csn < localsnapshot.csn || xid in prepared_xid list 可见, 否则不可见
5.2 跨节点事务
图3 跨节点事务处理流程
关键设计:第二阶段Commit 改为异步方式,只同步做prepare xact。(1.5 PC)DN 上行级别可见性判断:DN处于prepared状态的事务依赖对应CN上的事务是否提交,如果已经提交,且CSN比snapshot.CSN小,就可见对DN上处于prepared的事务,CN上的事务不处于提交状态,则必须判断是否残留状态,回滚。