Scheduled Firebase/Cloud 功能重叠问题
Scheduled Firebase/Cloud Functions Overlapping Problem
我有一个每三分钟运行一次的计划函数。
它应该查看数据库 (firestore)，查询相关用户，向他们发送电子邮件或执行其他数据库操作。
向用户发送电子邮件后，它会使用字段 'sent_to_today:true' 更新用户。
如果 sent_to_today == true，该函数将在大约 24 小时内不会触及该用户，这是预期的。
但是，因为我有很多用户，并且该函数正在做很多工作，所以当它用 sent_to_today:true 更新用户时，另一个调用会预先到达该用户并处理他们以发送电子邮件.
这会导致某些用户两次收到相同的电子邮件。
我有哪些选择可以确保这种情况不会发生？
数据模型（简化）：
users (Collection)
--- userId (document)
--- sent_to_today [Boolean]
--- NextUpdateTime [String representing a Timestamp in ISO String]
函数运行时，if ("Now" >= NextUpdateTime) && (sent_to_today==false)，处理用户，否则跳过。
如何确保用户每天只被一次调用处理，而不是多次？
正如我所说，当它们被一个函数调用处理时（将“sent_to_today”设置为 true），下一次调用会到达那个用户并处理它们。
如果能更好地构建数据或使用任何其他逻辑方法，我们将不胜感激。
这是我正在考虑的一个想法：
- 每次调用都会在开始时设置全局文档的字段“ex: busy_right_now : true”，完成后再次将其设置为 false。如果后续调用在当前调用完成之前运行，则如果 busy_right_now 仍为 true.
，则它不执行任何操作
选项 1.
你认为你的函数可以十分钟调用一次，而不是每三分钟调用一次吗？如果是 - 只需修改调度程序，并确保 'max instances' 属性为“1”。由于函数超时只有540秒，10分钟（600秒）足够避免重叠。
选项 2.
选择用于处理的firestore文档时，云功能会修改某些属性 - 即__state - 并将其值设置为IN_PROGRESS例如。处理完成后（发送电子邮件），该属性值将再次修改 - 例如 DONE。因此，如果该函数选取了一个文档，该文档在 __state 属性中具有值 IN_PROGRESS - 它会简单地忽略并继续下一个文档。
缺点 - 如果函数崩溃 - 可能会有 IN_PROGRESS 状态的文档，应该有一些机制来监视和解决这种情况。
选项 3.
一个云函数贯穿 firestore 集合，对于每个要处理的文档，发送一条 pubsub 消息，触发另一个云函数。该文件仅适用于一份 Firestore 文件。然而 'state machine' 控件是必需的（如上面的选项 2）。选项 3 的好处 - 功能之间的专业化程度更高，并且可能有许多 'second' 云功能 运行 并行。
我有一个每三分钟运行一次的计划函数。
它应该查看数据库 (firestore)，查询相关用户，向他们发送电子邮件或执行其他数据库操作。
向用户发送电子邮件后，它会使用字段 'sent_to_today:true' 更新用户。
如果 sent_to_today == true，该函数将在大约 24 小时内不会触及该用户，这是预期的。
但是，因为我有很多用户，并且该函数正在做很多工作，所以当它用 sent_to_today:true 更新用户时，另一个调用会预先到达该用户并处理他们以发送电子邮件.
这会导致某些用户两次收到相同的电子邮件。
我有哪些选择可以确保这种情况不会发生？
数据模型（简化）：
users (Collection)
--- userId (document)
--- sent_to_today [Boolean]
--- NextUpdateTime [String representing a Timestamp in ISO String]
函数运行时，if ("Now" >= NextUpdateTime) && (sent_to_today==false)，处理用户，否则跳过。
如何确保用户每天只被一次调用处理，而不是多次？
正如我所说，当它们被一个函数调用处理时（将“sent_to_today”设置为 true），下一次调用会到达那个用户并处理它们。
如果能更好地构建数据或使用任何其他逻辑方法，我们将不胜感激。
这是我正在考虑的一个想法：
- 每次调用都会在开始时设置全局文档的字段“ex: busy_right_now : true”，完成后再次将其设置为 false。如果后续调用在当前调用完成之前运行，则如果 busy_right_now 仍为 true. ，则它不执行任何操作
选项 1.
你认为你的函数可以十分钟调用一次，而不是每三分钟调用一次吗？如果是 - 只需修改调度程序，并确保 'max instances' 属性为“1”。由于函数超时只有540秒，10分钟（600秒）足够避免重叠。
选项 2.
选择用于处理的firestore文档时，云功能会修改某些属性 - 即__state - 并将其值设置为IN_PROGRESS例如。处理完成后（发送电子邮件），该属性值将再次修改 - 例如 DONE。因此，如果该函数选取了一个文档，该文档在 __state 属性中具有值 IN_PROGRESS - 它会简单地忽略并继续下一个文档。
缺点 - 如果函数崩溃 - 可能会有 IN_PROGRESS 状态的文档，应该有一些机制来监视和解决这种情况。
选项 3.
一个云函数贯穿 firestore 集合，对于每个要处理的文档，发送一条 pubsub 消息，触发另一个云函数。该文件仅适用于一份 Firestore 文件。然而 'state machine' 控件是必需的（如上面的选项 2）。选项 3 的好处 - 功能之间的专业化程度更高，并且可能有许多 'second' 云功能 运行 并行。