传统数据库的写放大问题是怎么回事？

传统数据库存在严重的写放大问题，以单机MySQL 为例，执行写操作会导致日志落盘，同时后台线程也会异步地将脏数据刷盘。另外，为了避免页断裂，进行刷脏页的过程还需要将数据页写入Double-Write 区域。如果考虑生产环境中的主备复制，如图下图 所示，AZ（Availablity Zone）1 和AZ 2 分别部署一个MySQL 实例做同步镜像复制，底层存储采用EBS（Amazon Elastic Block Store），并且每个EBS 还有自己的一份镜像，另外部署S3（Amazon Simple Storage Service）进行Redo 日志和Binlog 日志归档，以支持基于时间点的恢复。从流程上来看，每个步骤都需要传递5种类型的元数据，包括Redo、Binlog、Data-Page、Double-Write 和Frm。由于是基于镜像的同步复制，因此图中的步骤是①、③、⑤顺序执行的。这种模型的响应时间非常糟糕，因为要进行4 次网络I/O，且其中3 次是同步串行的。从存储角度来看，数据在EBS 上存了4 份，因此需要4 份都写成功才能返回。所以在这种架构下，无论是I/O 量还是串行化模型都会导致性能非常糟糕。

以上内容摘自《云原生数据库原理与实践》，这本书可以在电子工业出版社天猫店购买。