首页 文章 精选 留言 我的

精选列表

搜索[GPU调度],共10000篇文章
优秀的个人博客,低调大师

大数据调度

今天,Apache DolphinScheduler 3.2.0 版本在万众期待中终于发布了!在之前的预告中,包括《重磅预告!Apache DolphinScheduler 3.2.0 新功能“剧透”》、《3.2.0 版本预告!Apache DolphinScheduler API 增强相关功能》、《3.2.0 版本预告!远程日志解决 Worker 故障获取不到日志的问题》,以及《3.2.0 终极预告!云原生支持新增 Spark on k8S 支持》文章汇总已经大致覆盖了 3.2.0 版本的全新功能和优化。 现在,来看看新版本的全新“样貌”吧! Release Note: https://github.com/apache/dolphinscheduler/releases/tag/3.2.0 下载地址: https://dolphinscheduler.apache.org/en-us/download/3.2.0 主要更新包括: 添加默认租户 新增多种数据源 新增任务类型 重跑任务时指定工作流向前、向后运行 增加远程日志功能 参数优化 资源中心 增强页面易用性 云原生支持新增 Spark on k8S 支持 增加了部分 Restful API 注册中心增加 ETCD、JDBC 注册中心 架构优化 添加默认租户 在之前的版本中,用户部署完毕后必须手动添加租户。3.2.0 版本中添加了默认租户,方便用户更直接地使用 Apache DolphinScheduler。 新增多种数据源 新增了多个数据源,如 Snowflake、Databend、Kyuubi、Doris、OceanBase、Dameng、AzureSQL、StarRocks、AWS Athena、,并且更新了部分数据源,如 Redshift 增加 Access key。 新增任务类型 新增了多个任务类型,包括: 通用模块中,增加Remote-shell组件、Java Task Cloud模块中,新增 Amazon DMS、Azure Datafactory、AWS Database Migration,增强与各种云的互联互通 机器学习模块中,新增Kubeflow组件(基于云原生构建的机器学习任务工具大合集) 其他模块中,增加 AmazonDatasync、Apache Linkis 并更新了部分任务,如 DataX 支持 Presto,http任务增加output 参数传递,运行批量同时 kill 多个 Yarn 任务: Dependent 支持依赖自己: 支持了 Zeppelin 鉴权; 此外,任务现在可以支持缓存; Sqoop 日志支持隐藏密码; 以及 SQL 任务支持默认切割符: 新增远程日志功能 3.2.0 版本增加了远程日志功能,并同时支持了 Google Cloud Storage、Amazon S3、阿里云 OSS 日志存储,用户可以通过编辑配置文件,把日志存储到云端,解决万一意外情况发生,Woker 日志不存在,用户无法查看日志的问题。 详情参加《3.2.0 版本预告!远程日志解决 Worker 故障获取不到日志的问题》。 参数优化 增加了项目级别参数 调整参数优先级,启动参数最高 增加了内置参数计算规则 增加了文件类型的参数 云原生相关 支持 KEDA 做 worker 自动扩缩容 支持 Terraform 部署到 AWS zk 和 pg 支持多架构 提交 Spark 任务到 Kubernetes(详情见《3.2.0 终极预告!云原生支持新增 Spark on k8S 支持》) 获取 pod 实时日志 自定义 k8s 任务标签 资源中心 增加了 Alibaba Cloud OSS 、Huawei Cloud OBS、Azure Blob Storage的支持,重构资源中心并设计默认使用本地作为存储介质,重新支持了 re-upload。 资源中心容许覆盖上传,优化文件路径,显示文件的全部路径。另外,之前版本中资源中心已经上传的同类型文件只能删除后重新上传,新版本中对本功能进行了优化,可以点击上传按钮进行上传。 支持 reupload 文件 API 增强 3.2.0 版本中,增加了部分 Restful API,包括 taskInstance、workflow state、workflowInstance、workflow and schedule、task relation,且API 触发工作流运行可以获得 instance ID,从而使得 Apache DolphinScheduler 的 API 能力得到显著增强。 详情参见:《3.2.0 版本预告!Apache DolphinScheduler API 增强相关功能》 增加页面易用性 3.2.0 增加了页面易用性和便利性,如增加 workflow instance 跳转到当前工作流、复制工作流名称、调整列宽等操作。 跳转到工作流实例 复制工作流名称 调整列表名称宽度 默认情况下会有 default 租户和本地资源中心,安装后就能使用。 默认租户 允许在 workflow instance 中重新运行任务,任务运行日志更加明确。 可以重新运行任务 json 导出可阅读性加强。 注册中心 增加了 ETCD、JDBC 注册中心。 架构 Alert 支持 HA 单线程更新 Kerberos Worker server 移除了 dao 依赖 接管 task instance 失败的任务 增加动态任务组配置 重构了逻辑任务和远程命令 资源限制(cpu 内存)从原来绝对值改成百分比 支持了 SSO 其中,支持了 SSO 后,用户可以通过 Casdoor 实现 SSO 登录。Casdoor 是基于 OAuth 2.0、OIDC、SAML 和 CAS 的面向 UI 的身份访问管理(IAM)/单点登录(SSO)平台,需要先部署 Casdoor 并获取 `Client ID` 和 `Client secret` 两个字段,再修改 dolphinscheduler-api/src/main/resources/application.yaml 文件配置 SSO。 可以通过以下步骤通过 Casdoor 为 Apache Dolphinscheduler 添加 SSO 功能: security: authentication: # Authentication types (supported types: PASSWORD,LDAP,CASDOOR_SSO) type: CASDOOR_SSO casdoor: # Your Casdoor server url endpoint: client-id: client-secret: # The certificate may be multi-line, you can use `|-` for ease certificate: # Your organization name added in Casdoor organization-name: # Your application name added in Casdoor application-name: # Doplhinscheduler login url redirect-url: http://localhost:5173/login 贡献者列表 感谢@zhongjiajie对此次发版的指导,以及下列贡献者的支持: 106umao, Abingcbc, AliceXiaoLu, BongBongBang, CallMeKingsley97, Chris-Arith, DarkAssassinator, EricGao888, EricPyZhou, FlechazoW, Gallardot, GavinGYM, IT-Kwj, LiXuemin, LucasClt, Mukvin, NoSuchField, Orange-Summer, QuantumXiecao, Radeity, Rianico, SYSU-Coder, SbloodyS, Tianqi-Dotes, TyrantLucifer, ZhongJinHacker, Zzih, ahuljh, alei1206, alextinng, amaoisnb, arlendp, baihongbin, bmk15897, boy-xiaozhang, c3Vu, caishunfeng, calvinjiang, darrkz, davidzollo, dddyszy, devosend, ediconss, eye-gu, fengjian1129, fuchanghai, guowei-su, haibingtown, hantmac, hdygxsj, hezean, hiSandog, hoey94, hstdream, huage1994, imizao, insist777, iuhoay, jackfanwan, jbampton, jieguangzhou, kezhenxu94, kingbabingge, labbomb, lenian, ly109974, lynn-illumio, moonkop, muggleChen, pandong2011, pppppjcc, qianli2022, qindongliang, qingwli, rickchengx, ruanwenjun, sandiegoe, seedscoder, shangeyao, shenyun, simsicon, sketchmind, stalary, tracehh, whhe, xdu-chenrj, xiaomin0322, xinxingi, xuchunlai, xxjingcd, yeahhhz, youzipi, zhangfane, zhangkuantian, zhaohehuhu,zhoufanglu, zhuangchong, zhutong6688, zhuxt2015, zzzhangqi 本文由 白鲸开源科技 提供发布支持!

优秀的个人博客,低调大师

基于Saga的分布式事务调度落地

全文4104字,预计阅读时间12分钟。 一、背景 随着微服务架构的兴起,越来越多的公司都对自身的业务架构进行了微服务化。在微服务架构中,随着服务的逐渐拆分,数据库的私有化已成为业界不成文的规定。因此伴随着微服务拆分所带来的数据一致性的问题也愈发严重,如何解决该问题成为微服务架构落地过程中一个非常重要的问题。由此我们引出分布式事务这一概念,用来解决上述背景带来的问题。在介绍分布式事务之前先让我们回顾一下什么是事务。 二、事务 事务是数据库操作的最小工作单元,是作为单个逻辑工作单元执行的一系列操作;这些操作作为一个整体一起向系统提交,要么都执行、要么都不执行;事务具有ACID四大属性。 A(Atomic):原子性,构成事务的所有操作,要么都执行完成,要么全部不执行,不可能出现部分成功部分失败的情况。 C(Consistency):一致性,在事务执行前后,数据库的一致性约束没有被破坏。比如:数据库约束账户余额必须大于0,所以设置为无符号数,在此约束下,A只有100元,但要转出200元,此时数据库会保持对约束的一致性,触发执行回滚。 I(Isolation):隔离性,数据库中的事务一般都是并发的,隔离性是指并发的两个事务的执行互不干扰,一个事务不能看到其他事务的运行过程的中间状态。通过配置事务隔离级别可以比避免脏读、重复读问题。 D(Durability):持久性,事务完成之后,该事务对数据的更改会持久到数据库,且不会被回滚。 了解完了事务的基本概念,接着让我们看看什么是分布式事务。 三、分布式事务 在分布式系统中,一个应用系统拆分为独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成的事务称为分布式事务。 从架构角度出发,分布式事务基本涉及到两大类。 第一类:一个事务请求只涉及单体服务,但是会操作多张数据库表,多个数据库表操作完成才表示最终完成。 第二类:一个事务涉及多个服务,同时每个服务可能连接着一个或者多个数据库,需要协同多个独立的服务访问多个数据存储最终才能完成。 我们常见的分布式事务来保证数据的一致性的方法分为两类:强一致性、最终一致性。 采用强一致性的分布式事务的方案:通常采用两段式提交协议2PC、三段式提交协议3PC。在微服务架构中,该种方式不太适合,原因如下: 由于微服务间无法直接进行数据访问,微服务间互相调用通常通过RPC或Http API进行,所以已经无法使用TM统一管理微服务的RM 不同的微服务使用的数据源类型可能完全不同,如果微服务使用了NoSQL之类不原生支持事务的数据库,业务的事务很难实现 即使微服务使用的数据源都支持事务,那么如果使用一个大事务将许多微服务的事务管理起来,这个大事务维持的时间,将比本地事务长几个数量级。如此长时间的事务及跨服务的事务,将为产生很多锁及数据不可用,严重影响系统性能 因此我们一般采用最终一致性来保证分布式系统的一致性。 常见的最终一致性的分布式事务解决方案有:事件通知模式(本地异步事件服务模式、外部事件服务模式、MQ事务消息模式、最大努力通知模式)、事务补偿模式(Saga、TCC)。我们通过调研上述解决方案总结出了以下特性: 下面我们通过一个业务场景来了解一下什么是分布式事务,并且我们创新行业是用什么方案来解决数据一致性问题的。 四、业务场景 假设有一个积分签到系统,里面有一个签到兑换积分从而兑换物品的功能场景。 我们要做的事情如下: 用户签到成功、增加用户积分 用户创建兑换物品订单,订单状态为已支付 扣除用户积分 扣减物品库存 创建物流出库单 针对以上的业务场景,我们应该如何实现分布式事务来满足业务需要。下面主要讲事务补偿模式来实现分布式事务。 4.1 TCC 模式 TCC是将整体业务逻辑的每一个事务提交分成了Try,Confirm,Cancel三个操作。 Try:完成业务的准备工作 Confirm:完成业务的提交工作 Cancel:完成业务的回滚工作 针对上述业务场景,按照业务背景要做的事情,实现一个TCC的分布式事务。 如果要实现一个TCC的分布式事务,首先要做的是了解业务的主流程以及各个接口提供的业务含义,不直接完成这个业务操作,而是完成一个Try(预处理)操作。 例如:给用户添加积分,我们不直接添加积分,先预处理添加积分。扣物品库存我们也不直接扣库存,先冻结将扣掉的库存。具体如下图 如果Try的逻辑都成功,TCC开始执行业务的Confirm操作,完成整个事务流程。添加用户积分扣库存等操作。如果Try的逻辑部分成功,有部分有问题,那么开始执行Cancel操作,撤销之前执行的所有操作。 总体对于TCC模式来说,要做一个分布式事务,业务中的一个接口需要完成3个逻辑的改造,Try-Confirm-Cancel。 服务调用链路依次执行Try逻辑 如果都正常的话,执行Confirm逻辑,完成整个业务流程 如果部分服务的Try逻辑有问题,会执行Cancel逻辑,撤销之前执行的所有操作 TCC模式对于业务的侵入性比较强,流程比较繁琐。各个业务侧都需要支持升级。对于我们创新行业来说,成本有点大,我们选择了另一种模式来实现分布式事务——Saga模式。 4.2 Saga模式 Saga是一种纯业务补偿模式,其设计理念为,业务在调用的时候正常提交,当一个服务失败的时候,所有其依赖的上游服务都进行业务补偿操作。 Saga的基本概念: saga:长事务,long live transaction 每个本地事务有对应的补偿事务 执行情况 正常:T1 -> T2 -> T3 -> … -> Tn 异常:T1 -> T2 -> T3(异常)-> C3 -> C2 -> C1 Saga两种恢复策略: backward recovery,向后恢复,补偿所有已完成的事务(回滚操作) forward recovery,向前恢复,重试失败的事务,假设每个子事务最终都会成功(重试操作) Saga事务的优缺点: 优点:模型比TCC更简单,只需业务方提供事务执行接口transaction、事务取消补偿接口cancel 缺点:直接执行事务执行接口transaction,可能有副作用(无论是否回滚,都会执行事务接口的逻辑,举例:A账号向B账号转账,T1事务对A用户扣款,T2事务对B用户加款,T1执行成功,同时产生了一条扣款记录,T2执行失败需要回滚T2和T1,在这个过程中的副作用是A账号能感知到金额变化和扣款记录) 针对上述业务背景,我们对于业务侧只需要支持事务提交的接口( T )和失败补偿的接口( C )即可。具体流程如下图: 对于Saga事务来说只有完成跟未完成两种状态。无论是事务全部执行成功,还是全部补偿成功都视为完成状态。出现异常导致流程中断为未完成状态。我们针对于业务提交的流程的Http Code状态来区分是执行向前恢复(重试),还是向后补偿(回滚)。对于没有补偿 C 的业务,我们将采取向前恢复,直到成功。对于异常情况,使用离线补偿的方式对未完成的Saga事务进行重做,如长时间无法完成将触发报警,人工处理。 我们行创基于上述saga模型研发了Saga的事务协调器,具体执行流程如下: 业务方使用需要实现对应事务的执行方法和补偿方法,采用上报分布式事务的方式进行操作,事务上报的数据属性简介: Name:本次流程的名称 OID:请求流程ID,必须唯一 Process:每个子流程的属性简介(类型为list,按照顺序执行) Transaction:执行事务的流程 Call:服务调用的方式,HTTP调用时传GET、POST等 ServiceName:服务名称 ServiceMethod:调用服务的方法名称,HTTP传请求的URL Body:POST body,string类型 Query:Get Query,map[string]interfase{} oid:订单ID, 必传,必须唯一,用于幂等性校验等 Compensate:执行失败的补偿流程 Call:服务调用的方式,HTTP调用时传GET、POST等 ServiceName:服务名称 ServiceMethod:调用服务的方法名称,HTTP传请求的URL Body:POST body,string类型 Query:Get Query,map[string]interfase{} oid:订单ID, 必传,必须唯一,用于幂等性校验等 业务方按上述规则上报数据,该事务会最终保证数据一致性,要么全部成功,要么都失败回滚。 我们创新行业采用Saga模型来实现分布式事务,来解决日常微服务拆分带来的数据一致性的问题,满足了我们日常的产品功能的需要,解决了棘手的问题。 五、总结 针对分布式事务的解决方案都有各自的特点,没有一个最优的方案,需要结合实际的应用场景选择合适的模式。 2PC 和 3PC 是一种强一致性事务,不过还是有数据不一致,阻塞等风险,而且只能用在数据库层面。 Saga、TCC是一种补偿性事务的思想,对业务入侵较大,需要业务方实现对应的方法。 本地消息、事务消息和最大努力通知其实都是最终一致性事务,因此适用于一些对时间不敏感的业务。 推荐阅读: 云原生时代的搜索服务算力管理 浅谈小程序开源业务架构建设之路 百度小程序包流式下载安装优化 前端工程化之FaaS SSR方案 日志中台不重不丢实现浅谈 百度ToB垂类账号权限平台的设计与实践

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册