我们正在考虑通过Salesforce出站消息传递（SOM）将我们的平台与Salesforce集成。客户端每次更新Salesforce中的对象时，SOM都会使用更新的对象（一次调用中最多可以有100个对象）调用我们的Webservice端点。我们的Web服务需要更新我们数据库中的相应记录。处理大量数据
除1个问题外，SOM对我们的目的非常有效。
某些客户端会进行大规模的夜间更新。 200,000-500,000个对象更新并不罕见。这意味着我们将在非常短的时间内获得包含100个对象的2000-5000个电话。如果多个客户端执行彼此接近的大规模更新，我们的Web服务将会被大量数据淹没。
要处理这个大容量/尖峰Web服务器将在应用程序服务器上为SOM调用中的每个对象创建消息。另一个进程将从Message Queue获取消息并更新数据库。
MSMQ is only limited by hardware所以应该能够处理数百万，而我们清楚积压的消息。
主要问题是这种处理大量数据/ web服务调用的好设计？有更好的方法吗？
如果您担心自己的系统能够在短时间内处理来自salesforce的大量数据，那么可能应该查看replication api。这更像是一种拉动模式。当你准备好消费更多的数据时，你打电话给salesforce。
编辑补充说，如果在队列中存储的消息是比做消息的最终处理（这似乎是这里的情况下），使用消息队列显著便宜似乎是个不错的计划。我只是名义上熟悉MSMQ。但假设它与许多免费的JMS队列一样远程企业级，它应该能够胜任这项任务。
我们考虑过复制API（拉模型）。 Push模式更适合我们的系统，因为客户数据更可能与Salesforce数据同步。 – mob1lejunkie 2012-02-27 21:21:04
销售团队保证有时间尝试交付OBM？考虑这个问题的答案，你可以随时调用getUpdated（）。不要说一个更好，只需要考虑一下。 – 2012-02-28 02:48:12
好点。我没有发现任何时间尝试交付的保证。 – mob1lejunkie 2012-02-28 03:55:34
你只是寻找一个简单的队列基本上存储异步Web服务请求的休闲有序的处理，而不是同步？如果是这样，那么成熟的MQ服务就太过于夸张了。这是一个相当简单的（减去显而易见的多线程陷阱）来生成一个能够存储100个k个工作请求的内存中队列，并且可以将其状态刷新到磁盘或者由DB支持。即使从头开始，虽然有很多用于Java和.NET的轻量级库可以帮助解决这个问题。
像Redis的NoSQL的解决方案将是可行的选择太（Redis的可能优于相比，由于列表和哈希原生支持，再加上易磁盘刷新其他的NoSQL选项）。 Amazon SQS会在云中为您提供疯狂便宜且可扩展的消息存储，如果您正在寻求恢复能力，这将是一个优势 - 您可以一次性将您的处理端点随时关闭几个小时，而对最终客户端没有明显的可见性，并且所有您可以使用AWS“开箱即用”的酷玩具。
我不会为每个消息存储一个对象，而是根据您的本地消息队列存储一组对象（一个SOM消息）。请记住，一旦你向salesforce回复了Ack，你就需要拥有消息持久化/恢复等所有权，我认为MSMQ是一个很好的选择。
一种替代方法是让他们在Salesforce排队等待，如果您的听众过度劳累，它可能会拒绝来自Salesforce的请求，并且Salesforce会重新发送消息并稍后重试（依此类推，长达24小时）如果爆裂能力是你唯一关心的问题，这将有助于解决这个问题。（这假定你没有及时性要求，因为你会失去控制重试发生的时间）
我们打算立即回应Ack，然后在远程MSMQ上创建消息。目前考虑为每个对象创建1条消息，因为MSMQ消息的大小限制为4MB。目标是尽可能多地同步数据，所以Nack响应不是一个可行的解决方案（尽管我们已经考虑过）。 – mob1lejunkie 2012-02-27 22:30:40
5000通话的方式少于400,000消息限制，你担心什么问题？ – superfell 2012-02-27 06:04:58
我已经重写了我的问题，希望问题更清楚。 – mob1lejunkie 2012-02-27 22:05:51