在模式隔离的多租户应用程序中设计 /实施交易量式盒模式
我有一个多租户应用程序。租户数据是根据模式隔离的。
我想实现交易量输出模式，在该模式中，我想将事件存储在表中（在同一交易中），然后以后用作业发送事件。
我打算将活动表保留在每个租户模式中，以便可以通过同一交易进行更新。我无法将事件表保存在共同的（应用程序）架构中，因为那时我无法在同一交易中更新表...
现在我的问题是工作（Quartz / spring基于基于Quartz / spring）如何知道需要检查所有架构的事件吗？可以有几个租户模式可以处理任何事件。
I have a multi-tenant application. The tenants data is isolated based on schema.
I want to implement a transactional outbox pattern, where I want to store the events in a table (in same transaction)and then send events later with a job.
I am planning to keep the events table in each tenant schema, so that it can be updated in the same transaction. I cannot keep the events table in common (application) schema because then I cannot update the table in same transaction...
Now my problem is how will the job (quartz / spring based) know which all schema needs to be checked for events? There can be several tenant schema where there were no events to be processed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种方法是用CDC替换CRON作业（MySQL的bin日志）。您可以在CDC处理程序中进行整个处理，也可以使用它来更新一些中央表，以跟踪租户有新消息。
One approach is to replace cron jobs with CDC (bin logs for MySQL). You can do the entire processing in the CDC handler or you can use it to update some central table that keeps track of which tenant has new messages.
如果您正在实现发出框模式，则在每个模式中跟踪所有事件表是一项繁琐的工作。
这是一个更好的量子盒模式： https://betterprogramming.pub/an-alternative'rel =“ nofollow noreferrer” -To Outbox-Pattern-7564562843AE
在2阶段消息中，无需维护CRON工作来检查事件。取而代之的是，您编写检查背包服务，以返回本地交易是否已投入。当DTM无法确定是否实施本地交易时，它将调用检查背包服务。
原则是，正在进行的所有交易都记录在DTM服务器中，并且服务器中有CRON作业将检查交易超时。当超时发生时，DTM服务器将回到检查背包服务，以确定是否已投入本地交易。
2相消息比Outbox容易得多，并且需要更少的代码。
If you are implementing OutBox pattern, it is a cumbersome job to track all event table in each schema.
Here is a better OutBox patter: https://betterprogramming.pub/an-alternative-to-outbox-pattern-7564562843ae
In 2-phase messages, there is no need to maintain cron jobs to check events. Instead, you write check-back services which return whether the local transactions has been committed. When DTM can not determine whether the local transactions has been committed, it will call the check-back services.
The principle is that, all transactions in progress is recorded in DTM server, and there are cron jobs in the server which will check timeouts of transactions. When timeouts happens, DTM server will callback the check-back service to determine whether the local transactions has been committed.
The 2-phase messages is much easier than OutBox, and require much less code.