基于MySQL 的抢占式存储引擎实现 任务2：抢占优化

[flycash]

前置条件：#10 已经完成

在 #10 任务1 的基础上，你需要做这个改进： 对于续约来说，你启用一个延时队列，可以使用 ekit 里面的延时队列，即维持一个 goroutine 每次都从队列里面获取一个已经被抢占的任务，在获取到之后就要开始续约。

注意，它和 #10 的区别就是用一个延时队列 + 一个 goroutine 取代了原本一个任务一个 goroutine 的模型，达到了优化性能的效果。

但是在启用了延时队列之后就会有一个问题：一个 Goroutine 可能根本来不及续约。比如说一个任务已经到了可以续约的时间，但是因为数据库性能之类的问题，导致一直没有把它取出来续约。

有两种可行的优化方案：

• 开多个 goroutine 从队列里面拿需要续约的任务，拿到了之后就各自续约。这个可以作为一个参数；
• 还是保留一个 goroutine，但是会尝试一次性把所有的需要续约的任务从队列里面取出来，然后使用一个 UPDATE 语句（或者说批量更新）续约成功。但是这个我只是认为具备可行性，但是问题比较多，尤其是在考虑后续负载均衡，会出现一个问题，即当前节点抢占了任务，但是续约失败，因为当前节点负载很高了，所以别的节点已经抢走了这个任务（整个过程也可以看做是任务窃取）。那么批量更新的时候就需要知道哪些续约成功了，但是哪些没有；

总体上来说，我认为在当下我们的数据库没有考虑采用分库分表功能的时候，批量更新还是蛮不错的。和负载均衡的冲突，我们可以后面继续讨论，至少负载均衡怎么做，我还没一个非常优秀毫无破绽的设计。

[hookokoko]

@flycash 不太确定我这种下面说的情况对你说的批量更新理解的是不是正确

我理解的这种批量更新的方案会有续约延迟的问题。 因为我从延迟队列中取任务时，不可能在同一时刻出队，所以这里出队的时候需要设置一个等待时间范围，比如拿到5s内需要续约任务，那么续约的误差最多可能有5s。

[flycash]

@flycash 不太确定我这种下面说的情况对你说的批量更新理解的是不是正确

我理解的这种批量更新的方案会有续约延迟的问题。 因为我从延迟队列中取任务时，不可能在同一时刻出队，所以这里出队的时候需要设置一个等待时间范围，比如拿到5s内需要续约任务，那么续约的误差最多可能有5s。

这里我们采用一种比较宽松的策略，就是续约不需要非常精确。比如说一分钟续约一次，那么连续两次或者三次续约失败才算是没续约。因此你其实有很多时间；

或者照你说的，秒级别的差距是可以理解的。我们最开始在考虑这个任务调度的时候，对于时间的保证就不要很精确，因为太难了。