数据的异步处理

Question

此时，我正在尝试将异步tcp服务器组装在一起，以接收数据，然后我想要处理这些数据，提取值并插入到sql服务器。

我认为最好的基本概念是，一旦数据被接收并确认为整个消息，就应该将消息传递给某种类型的集合，等待以FIFO为基础的处理，后者将解析这些值并插入到sql服务器。我想这就是所谓的消费者/生产者模式。

我一直在研究最好的集合/方法，到目前为止，我已经看到了使用异步/等待的BlockingCollection、ConcurrentCollection和BufferBlock，我认为这可能是最好的方法，但老实说，我不确定。

我发现最好的例子是Stephen的博客，特别是本文http://blog.stephencleary.com/2012/11/async-producerconsumer-queue-using.html

我的主要保留意见是，我绝不想放慢或中断信息的接收，这对我来说是建议使用多个生产者/消费者的例子，可以在上面的链接上看到，但我想知道的是；

• 在我的假设中，我是正确的还是在我的场景中有一种更合适的方法来做到这一点。
• 如果我的假设是正确的，任何人都可以在考虑到我的用例的情况下提出实现这一点的最佳方法。

所有的帮助都是非常感谢的。

Answer 1

此时，我正在尝试将异步tcp服务器组装在一起，以接收数据，然后我想要处理这些数据，提取值并插入到sql服务器。

这种情况有一个常见的陷阱。当工作尚未完成时，将成功报告给客户通常是错误的。大多数时候，我都看过这个设计，这是因为开发人员，而不是客户，或者出于技术原因，自己强加了一个高效的“需求”。因此，首先，后退一步，确保在操作尚未实际完成时，您确实希望将“成功完成”消息返回给客户端。

如果你确信这就是你想要做的，那么还有一个你必须问的问题:丢失请求是否可以接受？也就是说，在您告诉客户端操作成功完成之后，如果操作实际上还没有完成，系统还会稳定吗？

这个问题的答案通常是“不”。此时，最常见的体系结构解决方案是拥有一个进程外可靠队列(如Azure队列或MSMQ)，并有一个独立的后端(如Azure worker角色或Win32服务)来处理队列消息。这无疑使体系结构复杂化，但如果系统必须尽早返回完成消息，并且不能丢失消息，则这将是一个必要的复杂问题。

另一方面，如果丢失消息是可以接受的，那么您可以将它们保存在内存中.只有在这种情况下，您才能使用我的博客中提到的内存生产者/消费者类型之一。这是一种非常罕见的情况，但确实不时发生。

Answer 2

一般来说，我会避免在这类工作中使用BlockingCollection和朋友。这样做会鼓励您将整个系统架构成一个单一的过程，这是可伸缩性和可靠性的敌人。

我第二个斯蒂芬·克利里的建议使用进程外队列来管理工作.我不认为这必然会使体系结构复杂化--事实上，我认为它可以使事情变得更简单一些。具体来说，原始需求(“组装异步tcp服务器”)的一个主要复杂性消失了。异步TCP服务器编写起来很麻烦，而且很容易出错--为什么不干脆跳过这部分，把所有精力都集中在后处理代码上呢？

当我构建这样一个系统时，我使用了一个红表作为任务队列。任务被序列化为JSON，客户机将使用鲁普什命令将其任务添加到队列中。辅助进程从队列BLPOP中检索下一个任务，执行他们的任务，然后返回到等待下一个任务。

优势：

• 没有锁。所有同步都来自Redis (或您选择的任何任务队列)。
• 系统中的所有东西都是单线程的。多线程是很难的。
• 我可以随意旋转任意数量的工作进程，跨越任意多个节点。