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 只包含CSN
DN 本地维护事务id, 维护id到CSN的映射(CSN_LOG)
DN 本地GC的过程中回填CSN
单shared读事务使用local snapshot：
get local latest CSN + get prepared_xid
wait 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上的事务不处于提交状态，则必须判断是否残留状态，回滚。
https://carrier.huawei.com/cn/products/it-new/cloud/dws
标签：DN,事务,CSN,关键技术,GaussDB,GTM,csn From： https://www.cnblogs.com/xiaoxu0211/p/18567673