我们有自动登录到不同的网站和网站帐户上执行一些操作。它要求只有一个机器人可以同时登录到一个特定的帐户，以避免自动化流程中的不一致性。
我们有一个存储网站凭据的表：
|---------------------|------------------|------------------------|------------------------|
| id | email | locked_at | last_fetched_at |
|---------------------|------------------|------------------------|------------------------|
| 1 | abc@gmail.com |2020-09-14 14:35:35 UTC |2020-09-14 14:35:35 UTC |
|---------------------|------------------|------------------------|------------------------|
| 2 | def@gmail.com | NULL | NULL |
|---------------------|------------------|------------------------|------------------------|
| 3 | xyz@gmail.com |2020-09-14 14:35:35 UTC |2020-09-14 14:35:35 UTC |
|---------------------|------------------|------------------------|------------------------|
| 4 | ran@gmail.com | NULL | NULL |
|---------------------|------------------|------------------------|------------------------|准确地说，我们使用此查询获取凭据：
SELECT `credentials`.* FROM `credentials` WHERE `credentials`.`locked_at` IS NULL ORDER BY last_fetched_at asc LIMIT 1然后，我们用当前时间更新locked\u at字段，以锁定凭证行以进行下一个进程。
这发生在node.js应用程序中，mysql作为后端数据库，多个bot进程同时访问。我们希望确保两个进程不会获得相同的凭据&used transactions/select for update使此操作原子化，但到目前为止还没有成功的方法/查询。
我们对任何第三方集成都持开放态度，比如redis，或者node中有什么东西可以用来实现这一点。
谢谢你抽出时间。
1条答案
按热度按时间44u64gxh1#
这里的挑战是如何处理将中断预期流的各种异常以及如何从中恢复。为了设计实际的解决方案，您需要考虑平均进程时间、有多少个bot在多少个网站上工作、失败的严重性以及是否可以将其作为一个副进程来修复。如果网站在您的控制范围内（不是第三方网站），我更愿意使用消息传递（pub-sub）类型的解决方案，您的基础结构将通知网站上的代理处理更新，并且同一代理确保一次只进行一次更新（根据您的要求）。
如果这种类型的设置不可能，那么你的下一个赌注就是使用@akina所建议的东西，但也要为可能发生的每一个陷阱想出一个恢复行动，包括处理比赛条件、机器人超时或返回未完成的任务、网站返回意外的响应，等等。如果有人不注意这个过程并调整它来处理长期以来你一定会看到的每一个意外的惊喜，这可能会让你有点累。