处理大量数据

Question

我们正在考虑通过Salesforce Outbound Messaging（SOM）将我们的平台与Salesforce集成。每次客户端更新Salesforce中的对象时，SOM都会使用更新的对象调用我们的Webservice端点（一次调用最多100个对象）。我们的Web服务需要更新数据库中的相应记录。

SOM在我们的目的下工作得非常好，除了1个问题。

有些客户会进行大规模的夜间更新。更新200,000-500,000个对象并不罕见。这意味着我们将在很短的时间内获得2,000-5,000次100对象的通话。如果多个客户端进行彼此接近的批量更新，我们的Web服务将会被大量数据所淹没。

要处理这个大卷/尖峰，Web服务器将在应用服务器上为SOM调用中的每个对象创建消息。另一个进程将从Message Queue获取消息并更新数据库。

MSMQ is only limited by hardware所以我们应该能够处理数百万条消息，同时清除积压。

主要问题是这个用于处理大量数据/网络服务呼叫的好设计？有更好的方法吗？

Answer 1

如果您担心系统能够在短时间内处理来自salesforce的大量数据，那么您应该查看replication api。它更像是拉模型。当您准备好消耗更多数据时，可以调用salesforce。

编辑添加如果在队列中存储消息比执行消息的最终处理（这里似乎是这种情况）要便宜得多，使用消息队列似乎是一个好计划。我只是名义上熟悉MSMQ。但是假设它与许多免费的JMS队列一样远程作为企业级，它应该可以完成任务。

Answer 2

您是否只是在寻找一个简单的队列，它基本上存储了异步订购处理的Web服务请求，而不是同步？如果是这样，完全成熟的MQ服务就是过度杀伤。生成一个能够存储100个工作请求的内存队列，并且可以将其状态刷新到磁盘或由DB支持，这是一个相当简单（减去明显的多线程陷阱）。即使从头开始，尽管有大量的Java和.NET轻量级库可以帮助解决这个问题。

像Redis这样的NoSQL解决方案也是可行的选择（与其他NoSQL选项相比，Redis可能更优越，因为本机支持列表和哈希，以及简单的磁盘刷新）。亚马逊SQS会在云中为您提供疯狂的廉价+可扩展的消息存储，如果您正在寻找弹性，这将是一个加分 - 您可以自由地将您的处理端点一次性删除数小时，而对最终客户端没有明显的可见性，并且所有使用AWS“开箱即用”的酷玩具。

Answer 3

我不会为每条消息存储一个对象，而是为每个本地消息队列存储一组对象（一条SOM消息）。请记住，一旦您使用Ack回复salesforce，您需要获取消息持久性/恢复等的所有权，我认为MSMQ非常合适。

另一种方法是让他们在Salesforce排队，如果你的监听器工作过度，它可以从Salesforce中解除请求，Salesforce会重新排队并稍后再次尝试（依此类推，最多24小时），如果突发容量是你唯一关注的问题，这将有助于此。 （这假设您没有及时性要求，因为您将无法控制这些重试的时间）