我希望有人可以帮助我更好地编写此方法。在我有多个用户同时点击该方法之前，该方法一直有效。我开始使用async / await进行工作，但是我不知道它是否对我有用。最大的问题是我们有一个临时表/工作表，要保存到该表中，然后针对该表执行存储过程，该表将执行一些操作并在完成后清除该表。表中的数据是特定于用户的，因此我们只需要其中的数据供用户执行存储过程。如果其他数据进入那里，则会使事情变得混乱。这就是为什么我在继续之前要检查表以确保为空的原因。
简而言之，我如何才能使这种方法真正以RESTful方式工作，并为许多用户提供可伸缩性？
cd答案 0 :(得分：0)
您可能想在这里重新考虑您的方法。听起来您有一个现有解决方案，其中涉及一个存储过程来处理这些暂存记录，并且可能需要一些时间才能完成。 sproc假定所有登台记录都与其设计要处理的任务相关。在该proc运行时对多个请求进行排队会导致问题。
您应该考虑的第一件事是将调用分为两个部分：1.暂存数据。 2.轮询结果。无需进行API调用就可以等待存储过程完成，它可以将结果传回指示数据是否成功暂存的结果，并且客户端代码可以移交给第二部分，该第二部分用于轮询该工作的结果。轮询可以针对单个作业ID，也可以基于上次轮询日期/时间和自该日期/时间以来修改的轮询记录。 （如果适用，这可以允许客户端“查看”其他用户启动的作业）
关于登台和存储过程，应将作业标识符添加到登台表。登台表中的每一行都有一个作业ID，该作业记录跟踪有关请求的一些基本详细信息，包括：它什么时候开始的？是谁开始的？完成了吗？它是什么状态？ （排队，开始，完成，失败等）。失败原因是什么？ （如果适用）应使用作业ID开始存储过程，或查询任何未启动的作业并处理该作业或该组作业的暂存记录。当存储的proc完成处理一组记录时，它将更新作业行，并清除暂存记录。我甚至考虑将登台记录清除为每天下班后运行的计划任务，以避免对该表上的数据库进行不必要的锁定。 （删除每晚已完成/失败的暂存行和/或作业。）
希望设计系统以适应可以同时成功处理的多个请求，或者该过程的所有步骤都可以按顺序进行标识和处理，但是在上一个请求完成之前，不让一个请求排队。 / p>