我们不断的拆分schema，说了为了下一步的分库做准备，但是由此带来的代价也是显而易见的，我们的分布式事务在不断的增多。我们期望利用分布式事务来保证数据的一致性，但是其带来的影响也是不容忽视的。
摘录他人语：分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的 。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下，分布式事务才能够顺利完成，只要有一个工作不正常，整个事务就不能完成。这样，系统的可用性就相当于参加分布式事务的各实例的可用性之积，实例越多，可用性下降越明显。从性能和可伸缩性角度看，首先是事务的总持续时间通常是各实例操作时间之和，因为一个事务中的各个操作通常是顺序执行的，这样事务的响应时间就会增加很多；其次是一般Web应用的事务都不大，单机操作时间也就几毫秒甚至不到1毫秒，一但涉及到分布式事务，提交时节点间的网络通信往返过程也为毫秒级别，对事务响应时间的影响也不可忽视。由于事务持续时间延长， 事务对相关资源的锁定时间也相应增加，从而可能严重增加了并发冲突，影响到系统吞吐率和可伸缩性 。
如此这般，我们当初分库的目的是为了缓解主库的压力，解决热点资源锁的问题，以期这些问题解决后，能够提高系统的吞吐率。但是当我们schema分离，大量使用分布式事务的时候，新的问题来了， 事务时间增长， 系统的响应可能仍然无法提高，还有一个就是每个事务节点都可能成为瓶颈，毕竟是一根绳子上的蚱蜢，一个有问题，大家一样的都是死翘翘。 我们的目的没有达到， 反而是增加了DBA的工作量。
如果大家一定要使用分布式事务，请仔细想想如下问题
1. 这步操作一定得在事务当中吗？这步操作如果没完成或者失败了，值得回滚整个事务吗？难道没有优雅的补偿措施或者容错措施？
2. 分布式事务涉及到的点，必须的这么多？必须得实时的操作这一大串？不能通过通知类操作去精简掉某些点？
3. 在发起分布式事务之后，你是不是做了事务无关的操作，尽管这些操作跟事务无关？（如，读取数据、计算、等用户返回消息、等其他模块的调用返回等等）要知道事务应该尽快结束。
4. 你没有把一些读操作也算在事务里面了吧？这是很容易犯的错误，你在事务中 Enlist 了一个 select 操作。
5. 你的操作，某些步骤可以等全部操作完成之后再执行.这类操作具有明显的通知类特点。通知类操作是说，我给你一个通知，并且我保证通知到了你；你必须吃下这个通知，并且保证处理成功，但是你不必我一通知你你就处理。这样的操作很明显可以用另外一个任务去搞。
原则是，尽量缩短事务时间。
评论