I / O完成端口可以帮助数据库而不是文件写入吗？

Question

我正在阅读IOCP，据我所知，到目前为止，异步写入仅适用于写入文件的上下文。通过“文件”，我不是指磁盘文件，而是Windows上的“文件”类型输出设备。

我计划以某种方式使用IOCP来实现从客户端获取消息的服务器，然后将这些消息异步写入数据库（MySQL或SQLite）。但是，根据我的理解，IOCP中的异步写入涉及将要写入的数据传递给设备驱动程序 - 并且提到“设备驱动程序”似乎排除了在数据库上使用IOCP和异步写入的可能性，因为存在从应用程序编写者的角度来看，没有“设备驱动程序”涉及写入数据库。

那么，IOCP实际上可以帮助实现写入数据库的服务器吗？我有一种唠叨的感觉，我误解了一些东西。

如果IOCP在这种情况下无法提供帮助，是否有任何关于我应该考虑实现在Windows上执行异步写入数据库的服务器的建议？

Answer 1

通常，数据库会为您提供用于写入的API。这通常会隐藏它所做的所有复杂事情。有时，该API可能是通用的，可以与许多数据库一起使用，例如OLE-DB和ODBC，有时API可能是特定于数据库的。

您使用的数据库不太可能会公开一个低级别的API，以便使用IOCP，尽管它可能在内部使用IOCP。

您可能想要问的是，我可以使用异步写入来写入我的数据库，也就是说，您可以在不阻塞正在执行“关闭”的线程的情况下触发数据库写入。

虽然IOCP'友好'数据库API会很好，当你的服务器的其余部分使用IOCP与自己的日志文件和套接字读/写通信时，你可以获得的最好的是使用线程池来允许你发出数据库API所需的阻塞调用，而不会阻止服务器执行的其余工作。我倾向于将其称为“业务逻辑线程池”，它与我用于所有非阻塞I / O的IOCP线程池分开。

我写了一些文章，用于构建使用这种设计写入数据库的服务器，并且可以找到代码和文章链接here。

Answer 2

Io Completion Ports是一种通用机制，可以通过多种方式实现可扩展性。

在“最佳”情况下，Io完成端口与正在使用重叠Io的OS句柄相关联。但实际上这根本不是一个要求：即使所有使用的API都阻塞和/或不公开所需的句柄，Io完成端口机制也足以提供可伸缩性。

在一个非常简单的模型中，可以使用CreateIoCompletionPort - 调用PostQueuedCompletionStatus来创建用户定义的“作业”。在GetQueuedCompletionStatus上创建所有循环的工作线程池 - 并在处理排队作业时简单地在工作线程内调用阻塞Io例程。每次其中一个工作线程阻塞任何内核函数时，Io完成端口机制将看到并发计数低，并释放另一个工作线程。

显然，使用这种方式，活动工作线程的数量可以超过并发计数，但是，假设作业是对称的，当线程返回到其“GetQueuedCompletionStatus”调用时，它应该很快自行解决。

Answer 3

当您写入文件时，它们可以在任何地方提供帮助，并且在任何文件发生时都不想阻止。很难想象一个数据库想要这个，除了写出完整性无关紧要的文本日志文件。

Answer 4

IOCP在实施数据库时可以提供很多帮助。

IOCP与FILE_FLAG_NO_BUFFERING和FILE_FLAG_WRITE_THROUGH结合使用，正确对齐的块可让数据库引擎控制缓存行为，避免不必要的重复缓存和块复制，以正确的顺序进行写入，控制哪些写入可以同时进行，等

当然需要实现数据库才能使用这些功能，使用SQLite和Mysql可以获得其他功能。

有关如何帮助实施数据库的更多详细信息，Gray和Reuter的“事务处理：概念和技术”是一个很好的参考。