分层时间轮的实现

想知道多个 Level 时候，最上层 level 到期后（比如 23 点 59 分 59 秒），大量任务需要重新分配 bucket ，如何保证系统平稳呢？

时间轮主要用来解决啥问题

@momowei #2 定时任务？

以前为了完成 KPI ，在公司手撸了一个时间轮

@dlmy 图画得好啊，怎么学的

@sngxx 用了 4 年 DDD ，画了 8000 多张图，纯手撸练出来的

@momowei 延时队列

@dlmy 你这个是什么工具画的啊

这个不是顺手就来的吗？没个项目中都要收录一个，C++版，go 版，C#版，php 版

@NoKey draw.io

看 kafka 的源码, 2, 300 行代码就能撸一个出来.

@dlmy #4 太牛了

@aliipay 每次到点，都是将目标槽位的链表摘下，换一个新的上去；异步处理摘下的链表中的任务，互不影响

@IIInsomnia 如果任务数量巨大，怎么保证能在一个最小定时间隔周期内完成呢，如果完不成就可能会导致任务丢失或者推迟到下一个分层完成

@aliipay 并发执行的，每个任务的执行都是独立的，且只会在最小的那个分层执行

@aliipay 时间轮是保证任务到时间被执行即可，至于执行多久跟时间轮无关了

任务优先级没有体现出来， 当来了一个优先级很高的任务，如果机器 CPU ， 内存使用多， 会导致优先级高的任务，无法快速完成， 需要把正在执行的低优先级任务的中间数据和状态存盘，停止这个任务，释放内存。 当高优先级任务执行完成以后， 在从文件里面恢复低优先级任务执行，继续执行。

兄弟，虽然你的代码一顿操作猛如虎，但是 Benchmark 性能好像比不过直接 go 出去然后 sleep 啊

@doraemonki 直接 go sleep ，任务量大，你得有多少协程在等待阻塞

@IIInsomnia #19 要限制携程数量直接用 goroutine pool 就好了，goroutine 阻塞本身是一个健康的操作，有什么问题吗。我这边实际测试下来 timewheel 任务调度性能与定时器精度都比不过直接 sleep ，你这个时间轮性能优化在哪里呢，要不写一个 benchmark 实际场景比较一下？内存角度，从 go1.21 开始 100w 个 goroutine 也只需要 400M 内存，我认为这也不算高吧。附代码: https://www.codecopy.cn/post/cr388c

@doraemonki 如果有大量的定时任务需要等待几个小时甚至几天呢？你觉得你的服务还会有资源可用吗？ goroutine pool 池子该多大呢？池子被耗尽，短时间内无法回收；而时间轮不会，说白了就是一个使用场景的问题，时间轮是有特定使用场景的

@IIInsomnia #21 这个场景确实是我没考虑到