We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
仅限中文
目前的代码还是很凌乱的,当然,这是我的锅。
那么这里首要问题是:最开始的设计是事件驱动,从而让 scheduler 和 storage 只保持最轻度的耦合。
在预期中,scheduler 和 storage 只通过事件通信。换一句话来说,Scheduler 的任何实现,除了调用一下 Strorager 里面的 Events 方法以外,不会再调用任何方法。所有的信息传递都是通过各种 Event 来达成的。
那么目前的 Scheduler 实现还没有做到这一点,里面强依赖于 MySQL 实现的一些细节。
所以目标就是让 shecudler 包只调用一下 Events 方法。那么最关键的是重构这一段代码:
从设计的角度说,scheduler 完全不知道你下层是 MySQL,也更加不知道你用了 CAS 操作。
这里就会有一个问题,即如何在 Scheduler 和 Storage 之间传递信息呢?比如说在基于关系数据库的时候,有 Execution 的概念,那么怎么传递 Execution ID 这种东西呢?
有两个选择:
Scheduler 正常来说是不会关注 Execution 的,它虽然隐含了 Execution 这个概念,但是它并不强求 Storage 的底层实现,一定会持久化 Execution。
The text was updated successfully, but these errors were encountered:
我合并代码的时候可能已经引入了很多 BUG ,所以在实现的时候要小心一些
Sorry, something went wrong.
你要想办法解决在 Storage 和 Scheduler 之间传递必要的信息。
No branches or pull requests
仅限中文
目前的代码还是很凌乱的,当然,这是我的锅。
那么这里首要问题是:最开始的设计是事件驱动,从而让 scheduler 和 storage 只保持最轻度的耦合。
在预期中,scheduler 和 storage 只通过事件通信。换一句话来说,Scheduler 的任何实现,除了调用一下 Strorager 里面的 Events 方法以外,不会再调用任何方法。所有的信息传递都是通过各种 Event 来达成的。
那么目前的 Scheduler 实现还没有做到这一点,里面强依赖于 MySQL 实现的一些细节。
所以目标就是让 shecudler 包只调用一下 Events 方法。那么最关键的是重构这一段代码:
从设计的角度说,scheduler 完全不知道你下层是 MySQL,也更加不知道你用了 CAS 操作。
这里就会有一个问题,即如何在 Scheduler 和 Storage 之间传递信息呢?比如说在基于关系数据库的时候,有 Execution 的概念,那么怎么传递 Execution ID 这种东西呢?
有两个选择:
Scheduler 正常来说是不会关注 Execution 的,它虽然隐含了 Execution 这个概念,但是它并不强求 Storage 的底层实现,一定会持久化 Execution。
The text was updated successfully, but these errors were encountered: