操作系统buffered I/O对DBMS完整性存在哪些威胁？

主流关系型数据库（如InnoDB、PostgreSQL）默认优先使用自有缓存池+Direct I/O绕过操作系统页缓存，而非使用Buffered I/O，本质是因为通用OS的Buffered I/O逻辑未适配DBMS的事务ACID要求，会引入以下几类明确的完整性威胁：

• 事务持久性失效风险：Buffered I/O模式下，应用层调用write()写入的数据只会先存到OS的页缓存中，并不会立即落盘。OS默认会根据自身策略延迟刷脏（通常间隔30s左右），如果此时发生操作系统崩溃、断电等异常，已提交的事务数据会直接丢失，直接违反事务ACID的持久性要求。哪怕DBMS层面调用了fsync()强制刷盘，部分OS实现中fsync()也仅保证把数据提交到磁盘缓存，若磁盘本身未开启断电保护，仍然存在丢数可能。
• 脏页刷写顺序不可控风险：DBMS的WAL（预写日志）机制要求必须先写日志再写数据页，且日志的刷盘顺序必须严格匹配事务提交顺序。但OS的页缓存刷脏策略是全局通用的，不会感知DBMS的逻辑依赖关系，可能出现数据页先刷盘、对应的日志还未落盘的情况，一旦此时发生异常，重启后DBMS无法通过WAL恢复到一致状态，直接导致数据页损坏、事务回滚失败。
• 双缓存冗余带来的一致性风险：如果DBMS同时使用自有缓存和OS Buffered I/O，同一份数据会在两个缓存中各存一份，当DBMS修改自有缓存中的数据后，OS页缓存中还是旧数据，如果其他进程直接读取文件或者OS主动触发了旧数据的刷写，就会出现数据不一致的问题。此外双缓存还会导致内存浪费，同样的内存空间无法被DBMS用来优化查询性能。
• 内存回收导致的异常中断风险：OS的页缓存属于系统可回收内存，当系统内存不足时，OS会主动回收页缓存中的脏页，触发强制刷盘，这个过程可能会阻塞DBMS的写入请求，极端情况下甚至会导致DBMS进程被OOM killer误杀，造成未刷盘的数据丢失。

补充说明：部分云托管DBMS会在使用Buffered I/O的同时配合云盘的原子写、多副本同步机制规避上述风险，但物理机部署的开源DBMS仍然默认推荐使用Direct I/O绕过OS缓存，结合自身的缓存池、WAL刷盘策略保障数据完整性。

内容的提问来源于stack exchange，提问作者John Bossi