动态任务执行框架想法篇

栏目: Groovy · 发布时间: 5年前

内容简介:对于后端而言,数据订正可算是非常非常频繁且常见的事情了,常见的有DB、缓存、内存等数据源中的数据订正,对于非应用内存而言,其他有实体或者可以直接通过官方的提供的控制台连接进行修改的数据订正,相对比较简单,而对于应用内存,如果没有应用内通知并处理相关逻辑,多半就只能重启应用来实现刷新内存缓存了当然我这里说的也不是内存数据更新,最近遇到的一个问题就是redis缓存中的数据有问题,需要订正,而并不是简单的把数据删了就行,需要根据某些数据,做一些计算,然后得出新的数据,并写回到缓存这样看来好像也不太麻烦,如果没有

对于后端而言,数据订正可算是非常非常频繁且常见的事情了,常见的有DB、缓存、内存等数据源中的数据订正,对于非应用内存而言,其他有实体或者可以直接通过官方的提供的控制台连接进行修改的数据订正,相对比较简单,而对于应用内存,如果没有应用内通知并处理相关逻辑,多半就只能重启应用来实现刷新内存缓存了

当然我这里说的也不是内存数据更新,最近遇到的一个问题就是 redis 缓存中的数据有问题,需要订正,而并不是简单的把数据删了就行,需要根据某些数据,做一些计算,然后得出新的数据,并写回到缓存

这样看来好像也不太麻烦,如果没有第三方依赖,大不了写个 python 脚本或者 php 脚本,重新算一下,也没什么毛病

然而实际情况却并不是这样,问题有以下几点:

  • 数据经过ProtoBuf进行编码存入redis,反序列化是个问题
  • 数据计算有依赖外部服务,如只能通过rpc调用第三方接口,而rpc框架没有提供php或python的sdk

基于此,就想也米有办法,可以直接搞一个项目,可以执行Groovy脚本,在Groovy脚本中实现数据订正逻辑?需求如下

  • 支持Groovy脚本的动态更新(支持动态新增,删除和修改脚本)
  • Groovy脚本可友好的访问我们需要的外部资源

II. 设计

根据上面的想法,一个简单的设计思路就新鲜出炉了,我们的框架核心只需要支持两点即可:

  • 实时加载脚本
  • 运行脚本

当然为了扩展,以及提供更优雅的使用环境,则需要支持:

  • 丰富的插件支持
    • json序列化插件
    • http插件
    • rpc插件
    • redis缓存插件
    • 自定义各种插件
  • 插件可动态加载就更棒了
  • 避免蛋疼的jar包冲突

1. 项目结构

项目结构图大致如下

动态任务执行框架想法篇

2. 流程说明

a. Task Watcher

主要用来监听所有的Task变动,包括新增,删除or修改脚本,然后将最新的脚本捞出来,扔给框架

b. execute

主体的执行逻辑,主要是解析task(即groovy脚本),并根据task的变更事件,来决定是新增,删除还是更新任务,然后从任务池中停掉旧的任务,执行新的任务

c. plugin

这里提供丰富的第三方插件,供task调用

2. 实现

对于实现,未完待续,下一篇再说

II. 其他

1.一灰灰Blog: https://liuyueyi.github.io/hexblog

一灰灰的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

有限与无限的游戏

有限与无限的游戏

[美]詹姆斯·卡斯 / 马小悟、余倩 / 电子工业出版社 / 2013-10 / 35.00元

在这本书中,詹姆斯·卡斯向我们展示了世界上两种类型的「游戏」:「有限的游戏」和「无限的游戏」。 有限的游戏,其目的在于赢得胜利;无限的游戏,却旨在让游戏永远进行下去。有限的游戏在边界内玩,无限的游戏玩的就是边界。有限的游戏具有一个确定的开始和结束,拥有特定的赢家,规则的存在就是为了保证游戏会结束。无限的游戏既没有确定的开始和结束,也没有赢家,它的目的在于将更多的人带入到游戏本身中来,从而延续......一起来看看 《有限与无限的游戏》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

MD5 加密
MD5 加密

MD5 加密工具

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换