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上的事务不处于提交状态，则必须判断是否残留状态，回滚。
