需要实时修改的数据如何做分布式,分布式定时任务调度框架实践
大家好,关于需要实时修改的数据如何做分布式很多朋友都还不太明白,不过没关系,因为今天小编就来为大家分享关于分布式定时任务调度框架实践的知识点,相信应该可以解决大家的一些困惑和问题,如果碰巧可以解决您的问题,还望关注下本站哦,希望对各位有所帮助!
如何在Excel表格中实现数据的实时更新
这有两种情况:
1、在同一工作簿下的所有表格都是相同格式,需要在任一工作表中更改内容时,其他工作表的内容同步更改。
在左下角的工作表标签位置,单击鼠标右键,“选定全部工作表”,将所有工作表处于组合状态,此时,在任一工作表所做的修改将同步到其他所有组合的工作表。
2、工作表的结构相同,但顺序不同,在Sheet1中进行数据修改,对应的其他工作表相应数据修改。
在各个工作表建立=VLOOKUP(A2,Sheet1!A:B,2,0)当Sheet1的B列数据发生改变时,对应其他所有工作表A列同名对应的B列数据发生改变。
如何编写一个分布式数据库
某种程度上看来,数据库作为整个系统的核心,这句话其实并不夸张,数据库的选型关系到上层业务代码实现的方方面面,现在比较流行的架构方案是上层业务逻辑微服务化,并且结合分布式缓存,这套框架已经基本能做到上层业务的弹性扩展,但是最底层的数据存储还是很难去中心化(除非整个技术栈中去除关系型数据库(RDBMS),全部采用 NoSQL)。所以,经常是 RDBMS成为整个系统的瓶颈。
在长期的斗争中,大家总结出了很多方式来扩展最底层的关系型数据库:
1.主从,一主多从,双写,通过队列暂存请求...这些方案其实并没有解决问题,写入仍然是单点,而且对于 DBA的挑战比较大,今天我们暂时就不讨论了。
2.通过中间件 Sharding,常见的开源方案有: Cobar, TDDL, Vitess, Kingshard, MyCat等,这些方案的思路是拦截 SQL的请求通过 sharding key和一定规则,将请求转发/广播到不同的 MySQL实例上,从而实现水平扩展的效果,这个方案基本解决了单点写入的问题,对于业务来说整体的吞吐也上来了,看上去不错,这个方案是大多数业务遇到性能瓶颈的解决方案,但是缺点也是有的:
1)大多中间件都没有解决动态扩容的问题,多采用了静态的路由策略,扩容一般还处于人工 x2的状态,对 DBA要求比较高。
2)从一定程度上来说都放弃了事务,这是由于一条语句有可能会涉及到多个数据库实例,实现分布式事务是一个比较难的事情,我们后面会详细的介绍。
3)对业务不透明,需要指定 sharding key,心智负担较大
分布式定时任务调度框架实践
分布式任务调度框架几乎是每个大型应用必备的工具,本文介绍了任务调度框架使用的需求背景和痛点,对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践,并分析了这几种框架的优劣势和对自身业务的思考。
一、业务背景
1.1为什么需要使用定时任务调度
(1)时间驱动处理场景:整点发送优惠券,每天更新收益,每天刷新标签数据和人群数据。
(2)批量处理数据:按月批量统计报表数据,批量更新短信状态,实时性要求不高。
(3)异步执行解耦:活动状态刷新,异步执行离线查询,与内部逻辑解耦。
1.2使用需求和痛点
(1)任务执行监控告警能力。
(2)任务可灵活动态配置,无需重启。
(3)业务透明,低耦合,配置精简,开发方便。
(4)易测试。
(5)高可用,无单点故障。
(6)任务不可重复执行,防止逻辑异常。
(7)大任务的分发并行处理能力。
二、开源框架实践与探索
2.1 Java原生 Timer和
ScheduledExecutorService
2.1.1 Timer使用
Timer缺陷:
由于上述缺陷,尽量不要使用Timer, idea中也会明确提示,使用ScheduledThreadPoolExecutor替代Timer。
2.1.2 ScheduledExecutorService使用
ScheduledExecutorService对于Timer的缺陷进行了修补,首先ScheduledExecutorService内部实现是ScheduledThreadPool线程池,可以支持多个任务并发执行。
对于某一个线程执行的任务出现异常,也会处理,不会影响其他线程任务的执行,另外ScheduledExecutorService是基于时间间隔的延迟,执行不会由于系统时间的改变发生变化。
当然,ScheduledExecutorService也有自己的局限性:只能根据任务的延迟来进行调度,无法满足基于绝对时间和日历调度的需求。
2.2 Spring Task
2.2.1 Spring Task使用
spring task是spring自主开发的轻量级定时任务框架,不需要依赖其他额外的包,配置较为简单。
此处使用注解配置
2.2.2 Spring Task缺陷
Spring Task本身不支持持久化,也没有推出官方的分布式集群模式,只能靠开发者在业务应用中自己手动扩展实现,无法满足可视化,易配置的需求。
2.3永远经典的 Quartz
2.3.1基本介绍
Quartz框架是Java领域最著名的开源任务调度工具,也是目前事实上的定时任务标准,几乎全部的开源定时任务框架都是基于Quartz核心调度构建而成。
2.3.2原理解析
核心组件和架构
关键概念
(1) Scheduler:任务调度器,是执行任务调度的控制器。本质上是一个计划调度容器,注册了全部Trigger和对应的JobDetail,使用线程池作为任务运行的基础组件,提高任务执行效率。
(2) Trigger:触发器,用于定义任务调度的时间规则,告诉任务调度器什么时候触发任务,其中CronTrigger是基于cron表达式构建的功能强大的触发器。
(3) Calendar:日历特定时间点的集合。一个trigger可以包含多个Calendar,可用于排除或包含某些时间点。
(4) JobDetail:是一个可执行的工作,用来描述Job实现类及其它相关的静态信息,如Job的名称、监听器等相关信息。
(5) Job:任务执行接口,只有一个execute方法,用于执行真正的业务逻辑。
(6) JobStore:任务存储方式,主要有RAMJobStore和JDBCJobStore,RAMJobStore是存储在JVM的内存中,有丢失和数量受限的风险,JDBCJobStore是将任务信息持久化到数据库中,支持集群。
2.3.3实践说明
(1)关于Quartz的基本使用
(2)业务使用要满足动态修改和重启不丢失,一般需要使用数据库进行保存。
(3)组件化
(4)扩展
2.3.4缺陷和不足
(1)需要把任务信息持久化到业务数据表,和业务有耦合。
(2)调度逻辑和执行逻辑并存于同一个项目中,在机器性能固定的情况下,业务和调度之间不可避免地会相互影响。
(3)quartz集群模式下,是通过数据库独占锁来唯一获取任务,任务执行并没有实现完善的负载均衡机制。
2.4轻量级神器 XXL-JOB
2.4.1基本介绍
XXL-JOB是一个轻量级分布式任务调度平台,主打特点是平台化,易部署,开发迅速、学习简单、轻量级、易扩展,代码仍在持续更新中。
主要提供了任务的动态配置管理、任务监控和统计报表以及调度日志几大功能模块,支持多种运行模式和路由策略,可基于对应执行器机器集群数量进行简单分片数据处理。
2.4.2原理解析
2.1.0版本前核心调度模块都是基于quartz框架,2.1.0版本开始自研调度组件,移除quartz依赖,使用时间轮调度。
2.4.3实践说明
详细配置和介绍参考官方文档。
2.4.3.1 demo使用:
@JobHandler(value="offlineTaskJobHandler"),实现业务逻辑即可。(注:此次引入了dubbo,后文介绍)。
(滑动可查看)
示例2:分片广播任务。
(滑动可查看)
2.4.3.2整合dubbo
(1)引入dubbo-spring-boot-starter和业务facade jar包依赖。
(滑动可查看)
(2)配置文件加入dubbo消费端配置(可根据环境定义多个配置文件,通过profile切换)。
(滑动可查看)
(3)代码中通过@Reference注入facade接口即可。
(滑动可查看)
(4)启动程序加入@EnableDubboConfiguration注解。
(滑动可查看)
2.4.4任务可视化配置
内置了平台项目,方便了开发者对任务的管理和执行日志的监控,并提供了一些便于测试的功能。
2.4.5扩展
(1)任务监控和报表的优化。
(2)任务报警方式的扩展,比如加入告警中心,提供内部消息,短信告警。
(3)对实际业务内部执行出现异常情况下的不同监控告警和重试策略。
2.5高可用 Elastic-Job
2.5.1基本介绍
Elastic-Job是一个分布式调度解决方案,由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。
Elastic-Job-Lite定位为轻量级无中心化解决方案,使用jar包的形式提供分布式任务的协调服务。
Elastic-Job-Cloud使用Mesos+ Docker的解决方案,额外提供资源治理、应用分发以及进程隔离等服务。
可惜的是已经两年没有迭代更新记录。
2.5.2原理解析
2.5.3实践说明
2.5.3.1 demo使用
(1)安装zookeeper,配置注册中心config,配置文件加入注册中心zk的配置。
(滑动可查看)
(滑动可查看)
(2)配置数据源config,并配置文件中加入数据源配置。
(滑动可查看)
(滑动可查看)
(3)配置事件config。
(滑动可查看)
(4)为了便于灵活配置不同的任务触发事件,加入ElasticSimpleJob注解。
(滑动可查看)
(5)对配置进行初始化。
(滑动可查看)
(6)实现 SimpleJob接口,按上文中方法整合dubbo,完成业务逻辑。
(滑动可查看)
2.6其余开源框架
(1) Saturn:Saturn是唯品会开源的一个分布式任务调度平台,在Elastic Job的基础上进行了改造。
(2) SIA-TASK:是宜信开源的分布式任务调度平台。
三、优劣势对比和业务场景适配思考
业务思考:
四、结语
对于并发场景不是特别高的系统来说,xxl-job配置部署简单易用,不需要引入多余的组件,同时提供了可视化的控制台,使用起来非常友好,是一个比较好的选择。希望直接利用开源分布式框架能力的系统,建议根据自身的情况来进行合适的选型。
附:参考文献
高可用架构
改变互联网的构建方式