HangFire分布式后端作业调度框架服务

简介: HangFire 分布式后端作业调度框架服务,我们只需要关心业务逻辑代码,而不用关心调度机制,支持.net framework和.net core

HangFire简述:
分布式后端作业调度框架服务,我们只需要关心业务逻辑代码,而不用关心调度机制,支持.net framework和.net core

HangFire基本结构:
客户端(创建任务)、服务端(执行任务)、数据库(存储任务列表和执行状况)、仪表盘(在网站上对任务进行监控查看和各种操作)

HangFire适用场景:
定时执行任务、循环执行任务、异步执行耗时任务、A任务执行完成再执行B任务、批量执行任务

HangFire官网: https://www.hangfire.io/

HangFire英文文档:http://docs.hangfire.io/en/latest/quick-start.html
HangFire源码地址: https://github.com/HangfireIO


image

实战经验分享:
网上资料不是很多 都是按照官方例子在讲解,缺少很多关键性的概念讲解,导致很多伙计在实战中遇到各种坑。

1、客户端:创建任务-->1、配置HangFire数据库连接 2、创建任务(在创建任务的时候HangFire会自动将任务序列化并存储到数据)

2、服务端:执行任务-->1、配置HangFire数据库连接 2、从HangFire数据库系统表读取客户端创建的任务然后开线程并行执行,任务之间不冲突。(服务端可宿主在Windows服务、控制台程序、IIS中…)

3、数据库:HangFire程序框架表-->创建任务的时候HangFire会自动生成无需关心,但要注意如果采用现有的数据库,必须保证数据库中没有重名的表,否则你懂(aggregatedcounter、counter、distributedlock、hash、job、jobparameter、jobqueue、jobstate、list、server、set、state),数据库可采用 MySQL ,MSSQL,Redis视需要而定

4、仪表盘:展示作业列表执行状态和结果等相关信息-->在.Net WebForm或.Net MVC 或.NetCore MVC网站程序对接HangFire数据库,MVC 对接方式和WebForm略微不同 请参考官方文档


如何正确理解架设部署上述4个板块:
重点说客户端、服务端、仪表盘直之间的关系,数据库就不用多说了

方案1(不推荐):客户端A、服务端B、仪表盘C 分别运行在3个独立的项目中
优缺点:没什么优点,而且AB分开会导致服务端B从数据库提取任务列表,准备反向加载程序集执行任务的时候,在自己的程序代码中找不到对应的业务逻辑代码或者引用类,因为业务逻辑代码是在客户端A项目中创建,自然业务逻辑类及功能代码都在A项目的程序集中,自然找不到。

例子:客户端A创建的作业是引用YourOwnJobLibrary.dll类中 ShowMeTheMoney() 方法,而服务端B中没有引用YourOwnJobLibrary.dll 所以无法执行任务ShowMeTheMoney(),

报错:System.IO.FileNotFoundException
Could not load file or assembly 'DotNetFrameWorkConsoleApplicationHangFire, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. ???????????
System.IO.FileNotFoundException: Could not load file or assembly 'DotNetFrameWorkConsoleApplicationHangFire, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. ???????????
File name: 'DotNetFrameWorkConsoleApplicationHangFire, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName, ObjectHandleOnStack type, ObjectHandleOnStack keepalive)
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean loadTypeFromPartialName)
at System.RuntimeType.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
at System.Type.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase)
at Hangfire.Storage.InvocationData.Deserialize()

解决方案:让服务端B也引用YourOwnJobLibrary.dll即可,但是这并不是我们想要的结果,以后更新服务什么的还得两头更新很麻烦。

方案2(推荐):客户端A、服务端B在同一个项目中,仪表盘C独立网站项目中
优缺点:这样比较合理,更新服务方便,即便没有仪表盘C,作业正常调度执行;适合后台相对固定的作业。
可以将AB放在Windows服务项目中(VS中可以创建),这样系统重启什么的毫无顾虑,更新服务程序的时候只需停止服务->替换程序->开启服务即可。

方案3(还行):客户端A、服务端B、仪表盘C在同一网站项目只能是网站项目,因为仪表盘只能在Web项目(API、WebForm、MVC )中
优缺点:视情况也未尝不可,如果宿主在IIS中,IIS默认20分钟没有人访问会停止,HangFire作业服务也会定制,可将此时间在IIS配置中延长,比较适合任务经常需要灵活变动处理的场景。


重要信息备注:
注1:创建任务可以是在控制台程序Main方法中执行一次把任务Load到数据库,或则在网站上用户点击某个按钮执行后端方法创建。


注2:服务端比较灵活,可宿主在Windows服务、控制台程序、IIS中…

注3:首次启动连接数据库时,会自动生成12张系统表,请确保现有库中不存在以下表名:aggregatedcounter、counter、distributedlock、hash、job、jobparameter、jobqueue、jobstate、list、server、set、state


注4:原则上同一台电脑上只需要1个服务端存在,测试中发现这么一种情况:服务端B宿主在D控制台程序中,因误操作在仪表盘C网站项目中也启动一个HangeFire宿主服务E,最后的结果是服务端B的程序失效,服务端E正常运作,但是仪表盘上显示找不到任务作业对应的程序集,因为程序集在服务端B程序中,如方案1的System.IO.FileNotFoundException…


注5:HangFire执行的任务里面如果涉及到C盘创建文件夹 可能会因为权限问题 创建失败,采用管理员权限运行程序即可创建

实例:按照方案2思路测试

  1. 创建一个.net core 2.0控制台项目(.net framework/.net core2.0都行)

  2. 安装nuget Hangfire(针对控制台程序可以只安装Hangfire.core即可 )

  3. 安装nuget HangFire.MySql.Core(.net framework 也引用此包 如果用HangFire.MySql 下面的配置数据库链接事变)

  4. 安装好后就可以在Main方法中使用了

image

注:控制台程序关闭,也就是HangFire宿主程序停止,作业无法继续执行,想检测服务作业是否在执行,可定时往记事本中写入当前时间。

5、网站(.net core)中配置HangFire仪表盘:( .net framework 的网站配置不一样 尚未测试)
image

注1:app.UseHangfireDashboard(); 是让网站仅仅可以访问HangFire数据库的作业详情,不负责业务代码的执行。

注2:app.UseHangfireServer();是让HangFire服务宿主在Web程序中,参加上面方案2和方案3,如果是方案2则不应该添加此语句,方案3则添加此语句。


运行项目访问HangFire仪表盘: http://localhost:56013/hangfire/
image

image
其他参考链接: http://blog.csdn.net/quryktcs/article/details/71331727

目录
打赏
0
0
0
1
1
分享
相关文章
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
分布式爬虫框架Scrapy-Redis实战指南
在Java中使用Seata框架实现分布式事务的详细步骤
通过以上步骤,利用 Seata 框架可以实现较为简单的分布式事务处理。在实际应用中,还需要根据具体业务需求进行更详细的配置和处理。同时,要注意处理各种异常情况,以确保分布式事务的正确执行。
在Java中实现分布式事务的常用框架和方法
总之,选择合适的分布式事务框架和方法需要综合考虑业务需求、性能、复杂度等因素。不同的框架和方法都有其特点和适用场景,需要根据具体情况进行评估和选择。同时,随着技术的不断发展,分布式事务的解决方案也在不断更新和完善,以更好地满足业务的需求。你还可以进一步深入研究和了解这些框架和方法,以便在实际应用中更好地实现分布式事务管理。
陪练,代练,护航,代打小程序源码/前端UNIAPP-VUE2.0开发 后端Thinkphp6管理/具备家政服务的综合型平台
这款APP通过技术创新,将代练、家政、娱乐社交等场景融合,打造“全能型生活服务生态圈”。以代练为切入点,提供模块化代码支持快速搭建平台,结合智能匹配与技能审核机制,拓展家政服务和商业管理功能。技术架构具备高安全性和扩展性,支持多业务复用,如押金冻结、录屏监控等功能跨领域应用。商业模式多元,包括交易抽成、增值服务及广告联名,同时设计跨领域积分体系提升用户粘性,实现生态共生与B端赋能。
36 9
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
79 14
文生图架构设计原来如此简单之分布式服务
深入浅出Node.js后端框架
【10月更文挑战第34天】在数字化时代,后端开发如同一座桥梁,连接着用户界面与数据处理的两端。本文将通过Node.js这一轻量级、高效的平台,带领读者领略后端框架的魅力。我们将从基础概念出发,逐步深入到实战应用,最后探讨如何通过代码示例来巩固学习成果,使读者能够在理论与实践之间架起自己的桥梁。
构建高效Java后端与前端交互的定时任务调度系统
通过以上步骤,我们构建了一个高效的Java后端与前端交互的定时任务调度系统。该系统使用Spring Boot作为后端框架,Quartz作为任务调度器,并通过前端界面实现用户交互。此系统可以应用于各种需要定时任务调度的业务场景,如数据同步、报告生成和系统监控等。
63 9
常见的分布式定时任务调度框架
分布式定时任务调度框架用于在分布式系统中管理和调度定时任务,确保任务按预定时间和频率执行。其核心概念包括Job(任务)、Trigger(触发器)、Executor(执行器)和Scheduler(调度器)。这类框架应具备任务管理、任务监控、良好的可扩展性和高可用性等功能。常用的Java生态中的分布式任务调度框架有Quartz Scheduler、ElasticJob和XXL-JOB。
1475 66
新一代 Cron-Job分布式调度平台,v1.0.5版本发布!
增加标签路由能力和多项功能优化!其中Tag标签路由的功能,测试环境多迭代场景下,可通过给任务配置Tag标签,实现任务路由到不同的执行器上。
29 0
MaxFrame:链接大数据与AI的高效分布式计算框架深度评测与实践!
阿里云推出的MaxFrame是链接大数据与AI的分布式Python计算框架,提供类似Pandas的操作接口和分布式处理能力。本文从部署、功能验证到实际场景全面评测MaxFrame,涵盖分布式Pandas操作、大语言模型数据预处理及企业级应用。结果显示,MaxFrame在处理大规模数据时性能显著提升,代码兼容性强,适合从数据清洗到训练数据生成的全链路场景...
139 5
MaxFrame:链接大数据与AI的高效分布式计算框架深度评测与实践!

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等