Closed flycash closed 1 year ago
我们最初期的时候会提供一个最简单的 MySQL 的实现。该 MySQL 实现将不会考虑任何的分库分表事情。
但是依旧有一些东西是可以考虑：
任务存储的一个基本思路是：
一个任务被设置好之后，会存储一份配置信息。而存储实现会定时轮询这个配置数据表，而后针对配置计算出来每一次调度的时间点，保存好。存储实现另外还会定时轮询这个计算好的任务表，找到近期要被执行的任务（例如一分钟内就会被调度的）缓存到内存。如果时间到了，那么就会被丢过去 channel 里面。调度核心从 channel 里面获取任务。
这里涉及到两个轮询，都是可能成为性能瓶颈的地方。 第一个轮询：如果我们假设有数百万数千万的任务，那么配置表扫描一遍就要很长时间； 第二个轮询：同样如果我们有数百万数千万的任务，那么扫描出来近期要调度的任务，也需要很长的时间；
这里可能考虑的优化是： 针对第一个轮询：每一个任务被调度完成之后，会生成下一个调度信息。例如12.20 零点调度了一次之后，就生成下一次调度的任务。这意味着，在任务创建的时候，需要生成第一个调度信息，后面就依赖于这样不断传递了。但是需要做好容错，例如在一个调度完成之后，没来得及生成下一次的调度信息，那么我们需要能够有手段找到并且进行重试； 针对第二个轮询：这个地方能够优化的手段不多。它存在两个隐患：数据库表数据很多，扫描一次很慢；任务太多，缓存起来导致内存消耗殆尽；
即便是一个最简单的基于 MySQL 的实现，也是蛮复杂的。
这个设计已经过时了，我重新开启一个
flycash
commented
1 year ago flycash
commented
1 year ago
我们最初期的时候会提供一个最简单的 MySQL 的实现。该 MySQL 实现将不会考虑任何的分库分表事情。
但是依旧有一些东西是可以考虑：
任务存储的一个基本思路是：
一个任务被设置好之后，会存储一份配置信息。而存储实现会定时轮询这个配置数据表，而后针对配置计算出来每一次调度的时间点，保存好。存储实现另外还会定时轮询这个计算好的任务表，找到近期要被执行的任务（例如一分钟内就会被调度的）缓存到内存。如果时间到了，那么就会被丢过去 channel 里面。调度核心从 channel 里面获取任务。
这里涉及到两个轮询，都是可能成为性能瓶颈的地方。 第一个轮询：如果我们假设有数百万数千万的任务，那么配置表扫描一遍就要很长时间； 第二个轮询：同样如果我们有数百万数千万的任务，那么扫描出来近期要调度的任务，也需要很长的时间；
这里可能考虑的优化是： 针对第一个轮询：每一个任务被调度完成之后，会生成下一个调度信息。例如12.20 零点调度了一次之后，就生成下一次调度的任务。这意味着，在任务创建的时候，需要生成第一个调度信息，后面就依赖于这样不断传递了。但是需要做好容错，例如在一个调度完成之后，没来得及生成下一次的调度信息，那么我们需要能够有手段找到并且进行重试； 针对第二个轮询：这个地方能够优化的手段不多。它存在两个隐患：数据库表数据很多，扫描一次很慢；任务太多，缓存起来导致内存消耗殆尽；
即便是一个最简单的基于 MySQL 的实现，也是蛮复杂的。