分布式事务框架选择与实践 (分布式事务框架)
seata分布式事务原理是什么?
Seata框架是一个业务层的XA(两阶段提交)解决方案。在理解Seata分布式事务机制前,我们先回顾一下数据库层面的XA方案。
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。
Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
![分布式事务框架](https://tyye.cn/zb_users/theme/tpure/style/images/lazyload.png)
Transaction Manager (TM): 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
分布式任务调度框架选型,如何选择一个合适的框架?
首先,这种框架现在市面上是有的。 强烈建议,不要重复造轮子。 先介绍几种比较主流的。 Elastic-Job,是当当网开源的分布式调度解决方案,支持任务分片功能,可以充分利用资源。 Elastic-Job有两个独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。 具体实现可以参考官方教程。 其整体架构图如下。 Elastic-Job的特点: 1、分布式调度 2、作业高可用 3、任务分片执行。 另外,还有其他的一些框架,可以对比使用。 比如TBSchedule是阿里巴巴开源的分布式调度框架,完全由java实现,目前被应用于淘宝,阿里巴巴,支付宝,京东, 汽车 之家等。 大众点评开源的xxl-job,也是应用比较广泛的分布式调度任务。 目前我使用过的有 Elastic-Job和xxl-job。 两者功能都很强大,后台管理也比较完善。 很容易上手。 都可以满足日常的工作需要。 区别就是 Elastic-Job依赖zk,但是xxl-job不依赖zk,只依赖数据库。 目前市面上应该还有一些其他的框架,但是以上是比较主流的,可以根据自己的需要来选择。 切记不要重复造轮子,造轮子需要大量的时间去验证。 会让你在坑里爬不出来。 -JOB -Job Elastic-Job 是一个分布式调度解决方案,由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。 定位为轻量级无中心化解决方案,使用 jar 包的形式提供分布式任务的协调服务。 支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。 分布式调度解决方案,由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。 Elastic-Job-Lite定位为轻量级无中心化解决方案,使用jar包的形式提供分布式任务的协调服务。 选择该项目可以满足大多数it企业的需求。 Elastic-Job-Cloud使用Mesos + Docker的解决方案,额外提供资源治理、应用分发以及进程隔离等服务。 轻量级无中心化:Elastic-Job-Lite并无作业调度中心节点,而是基于部署作业框架的程序在到达相应时间点时各自触发调度。 灵活的增删改查作业,集中式管理调度作业 支持高可用:一旦执行作业的服务器崩溃,等待执行的服务器将会在下次作业启动时替补执行。 开启失效转移功能效果更好,可以保证在本次作业执行时崩溃,备机立即启动替补执行。 支持分片:作业分片一致性,保证同一分片在分布式环境中仅一个执行实例 任务监控:通过监听Elastic-Job-Lite的zookeeper注册中心的几个关键节点即可完成作业运行状态监控功能 一致性:使用zookeeper作为注册中心,为了保证作业的在分布式场景下的一致性,一旦作业与注册中心无法通信,运行中的作业会立刻停止执行,但作业的进程不会退出,这样做的目的是为了防止作业重分片时,将与注册中心失去联系的节点执行的分片分配给另外节点,导致同一分片在两个节点中同时执行。 同时支持动态扩容,将任务拆分为n个任务项后,各个服务器分别执行各自分配到的任务项。 一旦有新的服务器加入集群,或现有服务器下线,elastic-job将在保留本次任务执行不变的情况下,下次任务开始前触发任务重分片 opencron是一个功能完善且通用的开源定时任务调度系统,拥有先进可靠的自动化任务管理调度功能,提供可操作的 web 图形化管理满足多种场景下各种复杂的定时任务调度,同时集成了 linux 实时监控、webssh 等功能特性 支持集群和分布式,但是没有友好的管理界面,功能单一,对于管理调用的任务比较困难。 quartz使用数据库锁。 在quartz的集群解决方案里有张表scheduler_locks,quartz采用了悲观锁的方式对triggers表进行行加锁,以保证任务同步的正确性。 一旦某一个节点上面的线程获取了该锁,那么这个Job就会在这台机器上被执行,同时这个锁就会被这台机器占用。 同时另外一台机器也会想要触发这个任务,但是锁已经被占用了,就只能等待,直到这个锁被释放。 quartz的分布式调度策略是以数据库为边界资源的一种异步策略。 各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。 同时多个节点的异步运行保证了服务的可靠。 但这种策略有自己的局限性:集群特性对于高CPU使用率的任务效果很好,但是对于大量的短任务,各个节点都会抢占数据库锁,这样就出现大量的线程等待资源。 这种情况随着节点的增加会越来越严重。 缺点:quartz的分布式只是解决了高可用的问题,并没有解决任务分片的问题,还是会有单机处理的极限。 Saturn基于当当Elastic Job代码基础上自主研发的任务调度系统,是唯品会开源的分布式作业调度平台,取代传统的Linux Cron/Spring Batch Job的方式,做到统一配置,统一监控,任务高可用以及分片并发处理。 主要是去中心化,高可用,可分片,动态扩容,有认证和授权功能。 主要特性支持多种语言作业,语言无关(Java/Go/C++/PHP/Python/Ruby/shell) 支持秒级调度 支持作业分片并行执行 支持依赖作业串行执行 支持作业高可用和智能负载均衡 支持异常检测和自动失败转移 支持异地容灾 支持多个集群部署 支持跨机房区域部署 支持弹性动态扩容 支持优先级和权重设置 支持docker容器,容器化友好 支持cron时间表达式 支持多个时间段暂停执行控制 支持超时告警和超时强杀控制 支持灰度发布 支持异常、超时和无法高可用作业监控告警和简易的故障排除 支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计 优点:源码清晰,学习入手容易。 应用部署简单,提供运维控制台,集中管理作业,运维控制台功能强大,提供作业统计报表 ,告警,增删改查作业,作业统一配置。 最后一个是国内团队封装的 前端时间研究了两款分布式任务调度框架,一个是XXL-Job,现在非常主流,很多常见的一些公司都在使用,像滴滴美团这样的公司都在用,这也是一款开源产品,下载下来导入IDEA就可以使用,分调度器和执行器和管理UI,有很美观的UI界面,可以对任务做增删改查,以及支持自定义开发,有很详细的帮助文档,还提供有demo,傻瓜式的,很简单,亮点是提供了管理界面。 另一个是Quartz,这个组件单机和集群都支持,单机的话是RAMJobStore任务存储,而要支持集群的话,就要将配置改成数据库方式,Quartz提供的有十几张表,其分布式的原理是利用了数据库的行锁,Quartz很简单,也是一款轻量级的开源产品,我们公司一直用这款组件,很成熟无Bug,推荐使用! springcloudtask,springclouddataflow,正在学习中
免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。