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