Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schduler: 完全事件驱动设计 - 解耦 Storage 层 #17

Open
flycash opened this issue May 23, 2023 · 2 comments
Open

schduler: 完全事件驱动设计 - 解耦 Storage 层 #17

flycash opened this issue May 23, 2023 · 2 comments

Comments

@flycash
Copy link
Contributor

flycash commented May 23, 2023

仅限中文

目前的代码还是很凌乱的,当然,这是我的锅。

那么这里首要问题是:最开始的设计是事件驱动,从而让 scheduler 和 storage 只保持最轻度的耦合。

在预期中,scheduler 和 storage 只通过事件通信。换一句话来说,Scheduler 的任何实现,除了调用一下 Strorager 里面的 Events 方法以外,不会再调用任何方法。所有的信息传递都是通过各种 Event 来达成的。

那么目前的 Scheduler 实现还没有做到这一点,里面强依赖于 MySQL 实现的一些细节。

所以目标就是让 shecudler 包只调用一下 Events 方法。那么最关键的是重构这一段代码:
image

从设计的角度说,scheduler 完全不知道你下层是 MySQL,也更加不知道你用了 CAS 操作。

这里就会有一个问题,即如何在 Scheduler 和 Storage 之间传递信息呢?比如说在基于关系数据库的时候,有 Execution 的概念,那么怎么传递 Execution ID 这种东西呢?

有两个选择:

  • 认为 Execution 是整个系统所有实现都应该有的一个概念,那么可以在 Event 里面带上 Execution ID
  • 认为 Execution 是部分实现才有的概念,那么可以在 Event 里面设计一个 map 字段,叫做 Attribute,是一个 <string, any> 的映射关系。而后把 Executrion id 放在里面。

Scheduler 正常来说是不会关注 Execution 的,它虽然隐含了 Execution 这个概念,但是它并不强求 Storage 的底层实现,一定会持久化 Execution。

@flycash
Copy link
Contributor Author

flycash commented May 23, 2023

我合并代码的时候可能已经引入了很多 BUG ,所以在实现的时候要小心一些

@flycash
Copy link
Contributor Author

flycash commented Jun 6, 2023

image
你要想办法解决在 Storage 和 Scheduler 之间传递必要的信息。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔖 Ready
Development

No branches or pull requests

1 participant