我们在 1.0 中有一个履行脚本，该脚本根据 SKU 和其他参数从自定义记录中提取序列号。有一个基于 SKU 创建的搜索，并使用第一个可用记录。搜索条件之一是你不是与密钥关联的最终用户。
我们正在努力将脚本转换为 2.0。我无法弄清楚的是，如果脚本(例如将上述功能放入 MR 脚本的 Map 函数中(将在多个队列/实例上运行，这是否意味着 2 个实例可能会命中自定义记录的相同条目？有什么解决方法可以确保 Map 函数的 X 实例不会使用相同的 SN/Key 结束我们？在 2.0 中发生这种情况的方式是 Map 的两个实例同时对自定义记录发出搜索请求并获得相同的结果，因为第一个 Map 尚未完成处理并将密钥标记为已使用(更新密钥上的最终用户信息(。
有没有更好的方法在 2.0 中完成此操作，或者我是否需要创建另一个自定义记录，脚本必须读取该记录才能从中提取密钥。如果表被锁定，我是否可以实施等待？
感谢
这里最好的办法可能是将分配过程分成两部分或对其进行重组，以便最终得到一个计划脚本，并给出一个显式队列。这样，您对序列号的访问将被序列化，您无需执行任何额外的工作。如果需要有关使用 SS2 处理大批的提示，请参阅 https://github.com/BKnights/KotN-Netsuite-2 以获取大批处理可能需要的实用程序脚本。
如果这是不可能的，那么我所做的是： 创建另一个名为"锁定表"的自定义记录。它必须至少具有 id 和文本字段。创建一个记录并记下其内部 ID。如果将其保留为名称列，请为其指定一个反映其用途的名称。
当您想要提取序列号时，您可以： 使用查找字段功能从锁定表中读取。如果不是 0，则执行等待*。 如果为 0，则生成一个从 0 到 MAX_SAFE_INTEGER 的随机整数。
尝试使用提交字段函数将其写入"锁定表"。然后马上读回来。如果它包含您的随机数，那么您就有锁。如果没有，请等待*。
如果您有锁，请继续分配序列号。通过写回 0 来释放锁。
- 等： 这在 NS 中很难。由于我不希望 s/n 分配花费太多时间，我有时会启动等待，因为只是简单地循环完成我希望的 CPU 密集型任务，直到一段时间过去之前没有治理成本。