使用Azure存储表作为具有多个工作者角色的队列进行处理吗?

enl*_*One 3 architecture azure azure-storage

我的应用程序将通过Web角色的多个实例每秒接收1000多个请求/事务.这些角色将为多个存储表中的每个事务写入一条记录(随机,以传播Azure的500个事务/秒限制).现在,我需要一种可靠的方法来使用多个Worker Roles处理/聚合这些数据,并将结果写入我的SQL数据库.AKA,这需要横向扩展.

我需要保留/存档存储表后处理中的所有事务,因此我可以使用一组表用于队列,并在处理它们时将它们移动到存档表中,或者可能有一种方法可以在一张桌子上这样做,不确定.

对于在我的工作角色中分配这些队列中的当前工作负载的机制,您会建议什么?显然,每个角色都必须了解每个其他角色的工作原理,因此它们只能处理无人认领的事务.我认为每个角色将从队列中检索1000条记录作为单个工作负载,并且多个工作者角色可以在同一队列上工作.

我应该将工作者角色"状态"保留在缓存中,也许在SQL服务器中.

非常感谢您的建议.

Fer*_*eia 8

我建议您使用正确的队列服务来实现此功能,而不是尝试通过表服务实现排队.这样,您就不必实现复杂的逻辑来了解哪些记录已被处理(当您考虑容错和可能的错误时,逻辑变得困难,尤其是在具有非常有限的事务能力的表存储等服务中).尝试可靠地协调多个工作人员,考虑所有可能的故障情况,同时可扩展,这是我不会在应用程序级别尝试的.

例如:

  1. Web角色接收表示事务的请求;
  2. Web角色将数据写入多个表;
  3. Web角色向表示具有某个唯一ID的事务的队列服务发送消息(例如,如果没有其他合适的主键,则为请求ID).
  4. worker角色从队列中提取消息.
  5. 对于每个消息,worker角色从表存储中检索对应于消息的唯一标识符的对象集.
  6. worker角色根据需要聚合数据并将其写入SQL数据库.

笔记:

  1. 使用队列服务(来自存储)或服务总线队列.
  2. 在许多队列之间传播负载以实现可伸缩性.
  3. 务必在所有级别应用适当的处理以解决瞬态故障.
  4. 处理多次处理相同消息的可能性(处理应该是幂等的).

  • 我认为 Fernando 的观点是,您将从队列中获取一条消息,然后从表存储中检索 1000 个相关项目,因此从队列中获取消息将非常快,因为它只是一个小请求和一个对表存储的请求(存储所有如果以这种方式编写它们是有效的,那么一个 blob 中的相关项也可能是一种选择)。幂等是关于能够处理相同的数据两次并仍然得到相同的结果。这将如何影响您将取决于您要实现的目标 (2认同)