我正在创建一个赌场类型的游戏，允许用户在一个事件上下注，我计划使用Microsoft Azure作为处理和数据存储的后端（表存储）。我正在寻找有关如何验证信息的任何想法，并通知用户任何更新的信息。
理念： 该应用程序允许用户对事件进行下注，例如在线博彩公司（PaddyPower，Ladbrokes等）。
工作流程：
情景（简化）：
流程：
解决方案1 - 使用队列： 当用户下注时，消息将被放入队列（由所有用户使用）并由工作者角色处理。
如果发生的事情对于该事件发生的投注太迟，或者该投注最终赢得了投注，则需要通知他们结果。
因此，每个活动用户都拥有自己的队列，客户端应用程序会轮询该队列以进行任何更新。这将允许客户端应用程序接收任何通知并将其显示给用户。
解决方案2 - 使用WCF＆amp;队列： 当用户下注时，他们会连接到WCF服务并进行事件开始检查，并会立即通知他们任何问题。
将任何通知发回给用户的唯一方法是使用解决方案1中的队列方法。
注意：的
那么哪种解决方案是理想的，还是有更好的解决方案？
答案 0 :(得分：0)
我正在做与你几乎完全相同的事情。仔细考虑后，我已经完成以下任务：
SQL Azure / EF模型。使用和扩展更容易 服务总线队列。 具有工作者角色的控制台应用程序的VM。虽然我们将转移到工作人员或Web作业来执行此操作，但我们可以使用VM上的控制台应用程序并使用任务计划程序快速监视和部署。
如果我们做对了并且所有可能的例外等都消失了，我们将转向可扩展的工作角色或Web作业。
答案 1 :(得分：0)
我建议您查看CQRS模式，特别是本文档涵盖的参考实现的详细信息：CQRS Journey。
参考实现使用Azure，我认为它非常适合您描述的系统。此外，它提供了一种极具可扩展性和弹性的架构。
答案 2 :(得分：0)
如果我是你，我会花时间计划如何设置PartitionKey + RowKey组合，以支持来自Table Storage的快速查询。仅仅因为查询表中的数据，特别是没有PartitionKey / RowKey，相对较慢。我学到了很多东西：）
答案 3 :(得分：0)
新技术可能有点早，但可以考虑使用Orleans
哦，不要排除将SQL Azure用于您的用户信息...尤其是涉及到财务时。 NOSQL不仅仅是持久性的全部而且最终......
答案 4 :(得分：0)
您的解决方案看起来不错，但您可以在 SignalR 上进行轮询，这样可以提高性能。 3件事的组合也应该有效 1. Web角色 2.工人角色 3. WCF服务 - 自我托管在工作者角色
使用SignalR很好，因为您永远不知道何时进行轮询，因此将此任务委派给服务器/角色