773 Star 1.5K Fork 351

开源中国 / Gitee Feedback

 / 详情

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

已拒绝
Task
创建于  
2018-05-10 15:46

现象描述

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

重现步骤

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

报错信息

评论 (1)

sruby 创建了任务
sruby 更新了任务
# 测试

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

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分片跟现有的方案好像没什么区别,都会存在锁。
Yashin 任务状态待办的 修改为已拒绝
诺墨 将工作项从 任务 迁移到 Task
Yashin 任务类型任务 修改为Task

登录 后才可以发表评论

状态
负责人
项目
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
开始日期   -   截止日期
-
置顶选项
优先级
预计工期 (小时)
参与者(2)
340906 nocnob 1645687775 56580 sruby001 1578915701
Ruby
1
https://gitee.com/oschina/git-osc.git
git@gitee.com:oschina/git-osc.git
oschina
git-osc
Gitee Feedback

搜索帮助