Q&A

问题1：请介绍下分布式事务保证数据最终一致性的具体方案例子。

回答：首先分布式事务涉及到的一致性和CAP中一致性是两个概念，事务ACID属性中的一致性不涉及最终一致性，对于关系型数据库中事务的概念，我的理解都是强一致的（通过原子性和隔离型保证）。只有涉及到某一个节点（内容是相同的情况）多副本之间的复制问题才会涉及到弱一致性或者最终一致性（CAP中C）的问题。而分布式事务本身如果保证了原子性和隔离性，数据库层面就提供了一致性保证，其余的是应用逻辑层面保证。如果问的是数据库主从复制之间的一致性问题，这个事情本质上和事务（ACID的C）的一致性就没有关系了，所以这个问题本身可能有待商榷。

问题2：分布式事务如何支持，现在可以支持多大规模的集群。

回答：基于Mysql的分布式集群方案无法保证严格的分布式事务语义，但是在实际使用的时候看业务情况，如果事务之间不怎么冲突的情况下也是ok的，如果可以改成只涉及一个分库的情况下那就绕开分布式事务的问题了。另外支持的集群，我们其实是根据业务来划分资源的，目前整体资源不能说特别大，千台规模。

问题3:JProxy是否可以支持所有复杂sql查询，主要是夸库的关联查询，具体内部逻辑可否介绍下？

回答：我们目前不支持夸库关联查询，从业务层面来解决。因为大表之间分库以后如果要支持跨库关联查询的话，作为一个OLTP系统在实际生产环境估计就没法用了。

问题4：请介绍下MySQL实际应用中主从复制的方案，以及主从的数据差异会在什么程度？

回答：这个其实更多的是主从之间关注的问题，一般会采用基于mix的模式。另外主从差异这个不同业务不一样，加上严格的监控，正常访问的情况下一般不会出现延迟，但是如果涉及到业务倒数据或者突增的访问量可能会引起延迟，所以这个不太好参考，如果有异常我们都会第一时间及时介入处理。

问题5：长时间SQL不会造成堵塞吗？

回答：主要看这条SQL具体是做什么的，如果是抽数据，就正常抽就可以了。如果有阻塞基本都是因为在MySQL端因为锁冲突等原因造成阻塞，最终可能是这个事务被abort掉或者最终抢到锁成功做完了这个事务。

问题6：请介绍一下JTransfers的工作机制，以及实现过程中最难的部分。

回答：迁移确实是比较刺手的一件事情，要考虑的细节很多。大体的步骤是：我们提交迁移计划，指定什么时间开始迁移，到时间点以后JTransfer就会自动迁移。JTransfer一开始是dump源分库的数据，然后将这些数据恢复到目标实例上，但是在这个期间业务是正常访问的，需要将增量数据迁移完，所以会有追增量过程。当增量追到一定程度，我们会阻塞这个库的访问，最后将剩余的少量数据迁移完。因为最后剩余数据量不多的时候，阻塞过程其实很短暂，所以对业务影响非常小。

最难的部分是：整个迁移过程中的路由变更，要保证路由变更的过程中数据不能写花，且变更以后的路由要准确的推送到JProxy中，由JManager和多个JProxy之间在变更路由的时候采用类似两阶段提交的协议，从而保证路由的变更是正确的。

问题7：可以分享一下JProxy的并发性能优化，以及JProxy中间状态的异常与恢复机制吗？谢谢！

回答：并发性能优化我们主要是通过采用基于事件驱动的网络模型，这种方式的特点是避免上下文切换避免锁的开销，但是代价的话刚才也说了需要考虑得非常周全，把一个上下文切成很多片段，不太符合人类思维。

JProxy中间件状态的异常与恢复机制这个我不是太理解什么含义哈，我的理解是如果jproxy运行过程中访问出异常了怎么处理，如果是某个连接过来的sql出了问题我们的做法是将整个连接涉及到的资源都关闭，把该次查询涉及到的前后端资源清理干净，这样就不会影响到其他客户端的访问。正常来说不应该出现这种情况，所以也需要完善的日志信息以及监控信息。