append-only 策略 浅说

我在前面其他内容中说到kafka时，聊到append-only，想着要么单独以这个为维度来从另一个视角讲些东西

个人浅见

首先顾名思义啊，append-only是仅追加。也就是数据的存储是不会改变原有内容的，是追加在后面进行记录的。追加写入的操作通常比随机写入高效，因为它减少了写操作需要的磁盘寻址时间

数据变化记录都追加保存在后面？听起来像日志是吧，对的。大量日志相关的内容用到了Append-only这种策略。既然数据只追加在末尾，那就意味着数据完整，具有可追溯性。既然可追溯，有历史记录，那就意味着有时间概念，所以可以联想到时间序列的数据。既然写操作只是按时序追加到后面留下记录，那么写操作就会变得简单。也就意味着可以承载大的吞吐量。既然如此，也适合分布式。所以可以看到，apeend-only策略这种思考方式，可以在很多地方被采用，或者部分采用。

举点栗子

1. 比如啊，mysql
谈及mysql，大家或许都知道那啥，mvcc，多版本并发控制是吧。以及MySQL的主从复制是吧。我就随缘讲了，我对更深的底层原理也不甚了解，我就简单讲下内容：

• mvcc，我们知道innleDB引擎下，mysql给每个表都维护着一些隐藏列，像事务快照id，回滚指针等。当一个事务过来时，根据事务快照id等列来判断当前事务应该读取哪个版本的数据。如果发生更新删除等操作，会先创建一个版本，并将其加到版本链中，去这里找当前事务该读哪个版本的数据。事务在提交时会在数据行上标记新的版本。由此可见它不需要加锁，所以是无锁读取数据的，减少了锁竞争，提高了并发。 InnoDB引擎默认配置下通过MVCC提供可重复读的隔离级别。
  • 讲到现在好像没有append-only的想法是吧。其实在一定程度上已经用到了。比如对于每个被更新的行，InnoDB不会直接覆盖原有数据，而是创建一个新版本，同时可能在Undo日志中记录旧版本数据。当需要查看旧快照时，可以通过Undo日志构建相应的数据版本。这为事务恢复以及快照访问提供了一定的基础。但是这个日志并不是不可删除，InnoDB会利用后台进程（如purge线程）清理不再需要的行版本，以避免无限制增长。
• MySQL的主从复制。我们知道市面上有些工具可以将某个mysql数据库表的操作变更同步到另一个数据库的表里。其实这便是基于mysql的binlog日志。binlog是实现MySQL异步复制的关键。从库只需要重放主库的日志就可以达到复制。这个二进制的binlog日志（在my.cnf配置）不会记录单纯的select语句内容，它记录了增删改以及DDL的操作，而这个日志记录方式就是append-only。那我们知道sql有的很复杂，所以记录的格式有记录简单sql的，也有记录行数据变化的，并支持根据时间或文件大小进行切分。所以正是binlog采取append-only策略来记录所有历史，才得以让数据可以被恢复，被审计

2，比如kafka
前面说过很多次了，kafka的消息是以日志形式追加记录的，我们在代码里常说消费后自动提交还是手动提交偏移量，或者说消息丢失了等，打个比方就是读日记本时，从第50行开始读，读100行，但是由于注意力不集中（比如网络波动，处理逻辑异常等导致偏移量没有提交或者消费明明失败了却依然提交），还以为这次的读取已经完事了，然后下次就从第150行开始读了（或者再次重复读一遍50到150）。消费端的消息丢失其实某种程度上可以认为没有丢，它是在kafka的日志里的，可以在日志里找回后重新消费的，于是就有了一些预防的措施，什么告知，改手动提交等等。具体kafka的相关可以看其他文章内容，这里不赘述

3. 比如redis的 AOF日志
你猜他为啥叫AOF ············(Append-Only File)
我们都知道redis的持久化有RDB快照形式，也有AOF日志文件持久化方式。RDB虽然已经提供了全量数据的持久化能力，但是定期执行的话，还是会有丢失近期操作的数据变化。这时就可以结合AOF日志，对日志内的记录进行重放就可以恢复数据。所以每当 Redis 执行一个写操作（如插入、更新、删除）时，该操作会被以文本形式追加到 AOF 文件的末尾。可以通过配置（appendfsync）来控制 AOF 文件的同步策略，常见的同步策略有：
always：在每次写操作后立即对 AOF 文件调用 fsync，性能较低但数据非常安全。
everysec：每秒对 AOF 文件进行一次 fsync，提供性能和安全性的良好平衡。
no：由操作系统自行决定何时 fsync，性能最佳，但在系统崩溃时可能会丢失最后的几秒数据。
当然了日志因为完整详细所以容易变得庞大，所以有日志重写机制。