在基于事件的系统中并发地处理唯一性

Handling uniqueness concurrently in event-based systems

本文关键字：系统 并发 唯一性 处理 于事件 事件      更新时间：2023-09-26

在我现在从事的项目中，我们面临着我们所说的挑战。挑战有成员和参与者。成员是可以访问挑战的每个人(可以是单个用户或用户组)，参与者以每个用户为基础跟踪参与的统计数据。

每次添加新的挑战成员时，都会重新计算挑战参与者。这是基于事件发生的，因此挑战成员触发created事件，挑战参与者侦听该事件。

当同时创建两个挑战成员时，问题就出现了，这意味着事件也被触发两次，并且代码的两次执行是并发运行的。说明:

challenge.getMembers();
challenge.getParticipants();
// calculations
foreach member not in participants, create participant

如前所述，当上述代码并发运行时，更具体地说，当第二次执行在第一次创建参与者条目之前到达getParticipants时，问题就出现了。两个执行都看到一些参与者缺失，并创建它们。这意味着我们现在有一些用户的挑战参与者的重复条目。

目前我们解决这个问题的方法是在挑战参与者的challenge_id, user_id上有一个唯一的索引。但是，当违反约束时，忽略错误确实感觉有点脏。这也使得检查其他SQL错误变得更加困难，因为所有错误都只是传递给回调，然后我们必须检查错误字符串的内容，看看它是我们喜欢的错误(惟一性冲突)，还是我们不喜欢的错误(如错误语法)，应该处理。

此代码将在多个服务器上运行，因此即使使用了muts，我们也不能保证代码不会并发运行。我们也不介意它并发地运行不同的挑战，只要它不是并发地运行同一个挑战。有人对处理这种类型的并发合并有什么建议吗?

既然您说您不介意为不同的挑战并发运行代码，那么您可以在挑战表中拥有一个具有状态的列。然后你会发出UPDATE challenges SET state = {locked} WHERE id = {id} AND state = {unlocked}。如果查询成功并且受影响的行数等于1，那么您可以继续更新参与者并在之后解锁挑战。如果查询没有影响任何行，那么挑战可能正在被其他执行线程更新，因此您可能希望跳过此步骤或计划稍后重新运行。

如果你走这条路，那么你需要小心解锁你的挑战，并做一些事情，以防止他们被卡住，如果其中一个线程崩溃在更新的中间，没有解锁它的挑战。例如，你可以有state = {thread id}，然后你可以检测哪些线程是死的，并解锁他们的挑战。

相关文章：