Scheduler(Dispatcher) Improvement

[huanghe2015]

I'm wondering about the scheduler or dispatcher on the watches' level. Not only does it cause the problem I described in #2994 ,but also it makes some watches starve, like the table below (my interval is 1 minute, and fetch workers work well):

#		Website	Last Checked	Last Changed
247	TypeScript Programing Language - Apps on Google Play   APP	1 minute ago	Not yet
248	Advanced SystemCare Pro v15.5.0.267 免安装便携版   软件更新	41 minutes ago	Not yet
249	上海招考热线-上海市教育考试院官网   考试上海	41 minutes ago	1 month ago
250	Adobe RoboHelp v2019.0.13 CHM\HTML帮助文件制作工具 - 易破解   软件更新	41 minutes ago	Not yet
251	VLC for Android - Apps on Google Play   APP	41 minutes ago	1 week ago
252	React.js Examples & Components - Apps on Google Play   APP	41 minutes ago	Not yet
253	NetSarang Xshell v7.0115 官方个人完全免费多语言版   软件更新	41 minutes ago	Not yet
254	pvpgn   游戏	41 minutes ago	Not yet
255	Adobe Photoshop 2022 v23.1.1.202 中文绿色便携版   软件更新	41 minutes ago	Not yet
256	EdrawMind Pro v10.5.3.202 亿图思维导图中文绿色版   软件更新	41 minutes ago	Not yet

So here's how my ideal scheduler or dispatcher would work (regardless of how many fetch workers there are, the pointer equals fetch workers):

────────────────────────────────────────────────
| Queue with Fixed Oldest Pointer |
|──────────────┬────────────────┬────────────────┬───────────|
| Stage 1: Initial | Stage 2: Operation | Stage 3: Updated |
|──────────────┼────────────────┼────────────────┼───────────|
| [Head] Oldest → Newest | |
| E1(08:00) → E2(09:15) → E3(10:30) → E4(11:45) | |
| ↑ | |
| │ Pointer Always Points to Oldest | |
| └───────────────────────────────────┘ |
| |
| ▶ Pointer → E1(08:00) (oldest) |
| |
|──────────────┼────────────────┼────────────────┼───────────|
| ▼ | |
| Modify E1 time to 12:00, move to tail | |
| |
| [New Head] Oldest → Newest | |
| E2(09:15) → E3(10:30) → E4(11:45) → E1(12:00) | |
| ↑ | |
| │ Pointer Now Points to New Oldest (E2) | |
| └───────────────────────────────────┘ |
| |
| ▶ Pointer auto-moves to E2(09:15) after E1 is moved |
| |
|──────────────┼────────────────┼────────────────┼───────────|
| ▼ | |
| Next Operation: Pointer → E2(09:15) | |
| |
|───────────────────────────────────────────────────────────|
| ▶ Pointer always targets the oldest element (head of queue) |
| ▶ After modifying an element, it moves to tail, |
| and pointer resets to new head (new oldest). |
────────────────────────────────────────────────

[huanghe2015]

Let me think more deeply about the Scheduler (Dispatcher).
Do these watches' intervals(I think it can be renamed as "The maximum time allowed to be next watched") run in hard real-time or soft real-time? Of course, these are soft real-time, but we still need to let all of the watches' "Last check time" equal to or even a little less than the "Interval".
Therefore, the best shape to organize watches, I believe, is a circular queue with only one direction. 
Many pointers(fetchers) are distinctly pointing at a watch. If a pointer's job is done, first modify the last check time and next check time, then move on to the next watch. If the next watch is read and working by another pointer, or the watch's next check time doesn't meet, move on to the next. 
If the fetch time when a pointer working exceeds the limit, the pointer can call the Scheduler(Dispatcher) to add another pointer to work on this queue. (Maybe the condition here isn’t enough, here is the only one I think that needs to be proceeded.)
If a pointer visits all of the nodes and finds that there are no nodes for which the "last fetch time" is less than "interval", "last check time" exceeds the "interval", this pointer can be removed.
So, after the above queue is designed, there are two things to notify that need the administrator to watch: First, if the watches' "last fetch time" exceeds the "interval", it needs to be reported. Second, if the pointers(fetchers) meet the limit of "(Maximum) Number of fetch workers", it needs to be reported.