开源中国 2018 年度最后一场技术盛会邀你来约~错过就要等明年啦!点此立即预约

开源中国 / Gitee FeedbackRuby

Watch 747 Star 1.1k Fork 328

Issues的文本编辑功能格式无法保留

任务
待办的
sruby  创建于

现象描述

  1. 编辑提交后文字都挤在了一块;(https://gitee.com/xuxueli0323/xxl-job/issues/IJOIY#note_923025
  2. 有序列表无法正常使用,没法自动生成下一行;

重现步骤

编辑好之后使用了几次有序列表,然后又delete了有序列表,再手工添加序号。

报错信息

340906_lowkey2046 共2人参与

评论 (1)

340906_lowkey2046
李葵 2018-05-11 10:04 成员
# 测试

场景:批量数据下发到下游系统。 

1. 下发的流程:
  a. 获取待下发业务数据-》b. 更新业务数据状态为下发中-》c. 数据下发-》d. 更新业务数据状态为已下发。 
2. 原有的任务是使用quarzjob,存在的问题是: 按照数据的业务类别分片,每类数据数量差别较大导致各个节点负载不均匀,下发速度慢; 
4. 优点: 按照业务类别分组后,每个节点只处理一个类别的数据,不存在并发问题。

现在计划的修改方案: 
1. 建立一个单任务,任务只获取特定数量的数据进行下发。 
2. 提高任务的调度频率,任务在各个执行器节点并发执行。
3. 任务并发执行,在a、b两个流程节点加锁,避免数据重复下发。

问题: 

1. 执行器节点宕机后,已经调度成功还未执行的任务会持久化下来吗?重启后能够继续执行?
2. 请问方案存在什么问题?还有那些可以提升的地方?
3. 分片对于这种场景能否提升性能?个人认为按照业务数据id做hash分片跟现有的方案好像没什么区别,都会存在锁。

测试

场景:批量数据下发到下游系统。

  1. 下发的流程: a. 获取待下发业务数据-》b. 更新业务数据状态为下发中-》c. 数据下发-》d. 更新业务数据状态为已下发。
  2. 原有的任务是使用quarzjob,存在的问题是: 按照数据的业务类别分片,每类数据数量差别较大导致各个节点负载不均匀,下发速度慢;
  3. 优点: 按照业务类别分组后,每个节点只处理一个类别的数据,不存在并发问题。

现在计划的修改方案:

  1. 建立一个单任务,任务只获取特定数量的数据进行下发。
  2. 提高任务的调度频率,任务在各个执行器节点并发执行。
  3. 任务并发执行,在a、b两个流程节点加锁,避免数据重复下发。

问题:

  1. 执行器节点宕机后,已经调度成功还未执行的任务会持久化下来吗?重启后能够继续执行?
  2. 请问方案存在什么问题?还有那些可以提升的地方?
  3. 分片对于这种场景能否提升性能?个人认为按照业务数据id做hash分片跟现有的方案好像没什么区别,都会存在锁。

登录 后才可以发表评论

负责人
标签
未设置
里程碑
关联分支
开始时间
未设置
结束时间
未设置
置顶选项
优先级

搜索帮助