DistributedLog的无状态代理分层架构

[[Apache BookKeeper的核心抽象与写入流程]]作为基石解决了分布式日志的核心问题，但它相对底层——如果要在大型组织中被广泛复用，首要问题是简单性：用户应该思考的是”命名的、无止尽的日志流”，而不是一串数字编号的Ledger。DistributedLog在BookKeeper之上做了两层封装。第一层是日志段：一条DistributedLog日志被切分成多个日志段，每个日志段对应一个BookKeeper的Ledger，新日志段在一定时间后或旧日志段写满时被创建；因为日志段大小相近，很容易被均匀分散到整个集群中；日志删除支持两种方式——精确的truncation（适合数据库这类复制状态机场景，需要严格控制哪个位置之前的数据不再需要）和基于时间的自动过期（适合不需要严格控制的数据分析场景）。第二层是无状态代理服务：写入端引入”Write Proxy”，负责管理每个日志的ownership、并在Proxy Server宕机时failover到其他Proxy Server——这里刻意使用”ownership tracking”而不是”leadership election”这个说法，因为BookKeeper已经通过内置的fencing机制保证了多写者场景下的一致性，Write Proxy不需要像共识算法那样严格的leader选举要求，因此可以设计成一个无状态服务，能随时被迁移和failover；读取端引入”Read Proxy”，负责缓存最近的数据，支持成百上千个reader同时读取同一个日志。因为Write Proxy和Read Proxy都是无状态服务，它们可以很容易地运行在Mesos、Docker、Amazon EC2这类集群环境中，实现Auto-Scaling，同时把服务层和存储层的扩展能力彻底解耦、可以分别独立扩展。这套设计揭示的可迁移原理是：把”有状态的持久化与一致性”完全下沉到底层存储（BookKeeper），上层的代理服务层完全不持有状态、只做路由和缓存，这种”状态下沉、服务层无状态化”的分层思路，正是让整个系统能在云环境里弹性伸缩的关键前提。