C# 数据的异步处理

此时，我正在尝试组合一个异步tcp服务器来接收数据，然后我要处理这些数据，提取值并插入sql server

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

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

我找到的最好的例子是斯蒂芬·克利里的博客，特别是这篇文章，

我的主要保留意见是，我决不想减慢或中断信息的接收，我认为这会建议使用多个生产者/消费者示例，可以在上面的链接中看到，但我想知道的是

• 我的假设是否正确，或者在我的场景中是否有更合适的方法来实现这一点
• 如果我的假设是正确的，考虑到我的用例，有人能建议实现这个的最佳方法吗

非常感谢您的任何帮助

此时，我正在尝试组合一个异步tcp服务器来接收数据，然后我要处理这些数据，提取值并插入sql server

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

如果您确定这就是您想要做的，那么您必须问另一个问题：丢失请求是否可以接受？也就是说，在您告诉客户操作成功完成后，如果操作实际上从未完成，系统是否仍然稳定

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

---

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

一般来说，我会避免使用BlockingCollection和friends进行此类工作。这样做会鼓励您将整个系统构建到单个流程中，这是可伸缩性和可靠性的敌人

我建议使用进程外队列来管理工作。我不同意这必然会使体系结构复杂化，但事实上，我认为它可以使事情变得简单一些。具体来说，原始需求的一个主要复杂性（“组装一个异步tcp服务器”）消失了。异步TCP服务器是一个很难写的东西，而且很容易出错——为什么不干脆跳过这一部分，把所有精力都放在后处理代码上呢

当我构建这样一个系统时，我使用了一个队列作为任务队列。任务被序列化为JSON，客户端将使用命令将其任务添加到队列中。工作进程从队列中检索下一个任务，完成自己的工作，然后返回等待下一个任务

优点：

• 没有锁。所有同步都是从Redis（或您选择的任何任务队列）免费提供的
• 系统中的所有内容都是单线程的。多线程是很难的
• 我可以自由地启动任意多个工作进程，跨越任意多个节点

---

如果您不介意我问您，在什么情况下请求会丢失或操作不会完成。例如，是否会引发异常？任何可能导致意外服务器关闭的事件。这可能从电源线绊倒到安装Microsoft更新修补程序后重新启动。服务器意外关闭的原因可以减轻，但永远不会消除，因此必须编写软件来处理该故障场景。啊，对了，我明白了，如果有10个x字节[]，情况就是这样等待处理，而服务器/应用程序由于某种原因被终止或断开连接，这些未处理的消息基本上将永远消失，而对于进程外队列，您只需继续处理队列中的任何项目，因为这些项目已提交到某个存储位置。@JohnyHarkness:没错。中的客户端这个案例是gps设备，因此我无法控制它们如何传输数据。唯一的选择是将它们指向tcp端口并读取传输的字节。是否可以使用消息队列执行此操作，并让工作进程读取从队列传输的字节？对于Redis，您需要一些轻量级守护进程来接收来自GPS设备的消息并将其转换为RPUSH命令。我很想知道是否有一个“无协议”的消息队列系统——只需获取原始TCP数据包并将其放入可靠队列进行后期处理。看起来这应该是可能的（而且很有用！）