对于XL改进方案的初步分析
根据前一篇博客中统计的单个事务耗时分布，我们发现每个请求在datanode执行的时间与PG执行时间几乎一样。
之前测试的是短事务，一个事务一个insert语句写入一条数据，这种场景对于xl来说没有什么优势，除了执行写入还要增加网络交互的耗时，且insert操作本身很快完成，相比执行网络交互耗时占的比重就大了很多。
而后我们测试了一下长事务，也就是一条sql执行本身就比较耗时，且能够调动xl多个datanode共同处理的情况。每个事务一条sql，写入10万行数据，这次的执行结果大不一样。
PG在8并发时tps到达上限(25)，XL在32并发时到达tps上限(52)，2并发及一下PG的性能略优于XL，2并发以上XL的性能明显优于PG。
由此我们总结出，XL能体现优势的场景，是网络开销在整个事务中所占的比重小，且能充分调动datanode的处理能力的场景。
结合之前画的XL事务处理时序图和XL进程架构图，对于XL的性能问题，有以下改进方案(有待补充)：
1. 减少网络交互次数
- 合并请求，比如合并获取GTXID和snapshot的请求(对短事务提升相对明显) ***
- 使用其他方案实现事务可见性判断(替代现有的集群快照) *****
2. 提高网络传输效率
- 更换传输协议 ****
3. 提高高并发时性能上限
- 优化进程架构？(高并发时，进程数过多，系统中连接数过多)
4. 减少coordinator与datanode的重复步骤
- 执行计划只在coordinator生成，再下发到各个datanode执行。 ****
【事务处理流程时序图】
【进程架构图】