Open menghuan123 opened 2 years ago
byteTCC针对事务处理的优化,主要体现在事务处理流程和技术实现两个层面,包括但不限于以下几个方面: a) 跳过不必要的cancel逻辑,如:分支节点在Try阶段异常且本地事务也回滚情况下,byteTCC在rollback阶段将不再调用该本地事务包含业务服务的cancel操作; b) 跳过不必要的本地事务,如:当分支事务已经进入commit/rollback或者被标记rollbackOnly情况下,仍然收到Try请求,则在开启事务时直接抛出异常中断该Try操作;如果Try请求收到时,分支事务尚未进入commit/rollback,但该Try执行过程中,分支事务进入commit/rollback且未(也不能)confirm/cancel该Try请求,则后续该Try操作执行完毕时,对应本地事务将会被byteTCC直接回滚; c) 当分支事务多次参与一个全局事务时(比如:A服务多次调用B服务;或调用链中形成了环;或多个服务都调用了同一个公共服务),byteTCC会将该事务分支分配在首次传播给它事务上下文的分支节点下,之后由其进行单次的commit/rollback通知,而不会收到多次commit/rollback调用; d) 事务日志优化: 涉及事务日志记录及清理等,细节问题这里就不展开了; e) 远程调用的优化:尽可能避免不必要的远程调用。byteTCC除了会向分支节点发送commit/rollback请求外,并没有额外的请求开销;并且,byteTCC会视情况优化commit/rollback调度策略,比如上文所述业务调用链路中存在环的情况。 f) 去中心化设计:byteTCC并不要求一个中心的事务调度服务,它只需要按事务粒度和自己的上一级及下一级节点进行配合即可完成一个事务,因此,在大量请求情况下可以做到线性扩展。
综上,目前版本的byteTCC已完成大量的优化策略,未来也仍然还有一些优化策略可被添加到byteTCC实现中。如有兴趣了解,敬请关注byteTCC之后版本。
byteTCC针对事务处理的优化,主要体现在事务处理流程和技术实现两个层面,包括但不限于以下几个方面: a) 跳过不必要的cancel逻辑,如:分支节点在Try阶段异常且本地事务也回滚情况下,byteTCC在rollback阶段将不再调用该本地事务包含业务服务的cancel操作; b) 跳过不必要的本地事务,如:当分支事务已经进入commit/rollback或者被标记rollbackOnly情况下,仍然收到Try请求,则在开启事务时直接抛出异常中断该Try操作;如果Try请求收到时,分支事务尚未进入commit/rollback,但该Try执行过程中,分支事务进入commit/rollback且未(也不能)confirm/cancel该Try请求,则后续该Try操作执行完毕时,对应本地事务将会被byteTCC直接回滚; c) 当分支事务多次参与一个全局事务时(比如:A服务多次调用B服务;或调用链中形成了环;或多个服务都调用了同一个公共服务),byteTCC会将该事务分支分配在首次传播给它事务上下文的分支节点下,之后由其进行单次的commit/rollback通知,而不会收到多次commit/rollback调用; d) 事务日志优化: 涉及事务日志记录及清理等,细节问题这里就不展开了; e) 远程调用的优化:尽可能避免不必要的远程调用。byteTCC除了会向分支节点发送commit/rollback请求外,并没有额外的请求开销;并且,byteTCC会视情况优化commit/rollback调度策略,比如上文所述业务调用链路中存在环的情况。 f) 去中心化设计:byteTCC并不要求一个中心的事务调度服务,它只需要按事务粒度和自己的上一级及下一级节点进行配合即可完成一个事务,因此,在大量请求情况下可以做到线性扩展。
综上,目前版本的byteTCC已完成大量的优化策略,未来也仍然还有一些优化策略可被添加到byteTCC实现中。如有兴趣了解,敬请关注byteTCC之后版本。 想知道这里(事务日志优化: 涉及事务日志记录及清理等)这里具体是做了什么优化,其他的优化点挺清楚的
请问下bytetcc对事务处理性能有什么优化?