Facebook 公布 Apollo，一种新的用于在线低延迟存储的 NoSQL 数据库

来自 Facebook 核心数据组的 Jeff Johnson 周三在 QCon 纽约的演讲中公布了 Apollo，它是 Facebook 的一种类似于 Paxos 的 NoSQL 数据库。Apollo 构建于 Apache Thrift 2 RPC 框架，采用 C++11 开发，是一种分层存储系统，所有数据被划分到 Shard，非常类似于 HBase 中的区域服务器。Johnson 表示它最大的好处是在线低延迟存储，特别是在 Flash 和内存中。

区别于面向文档和键值的存储，Apollo 是一种修改的数据结构，允许你存储 Map、队列、树以及键值等等。系统中每个单独的数据块都非常小，从 1 字节到 1MB，而所有的总大小则从 1MB 到 10+PB。它支持的服务器从最少三台到数千台之多。

每个 Shard 有四个组件。第一个是 Quorum 一致性协议，它基于来自斯坦福的强 Leader 一致性协议 Raft 。Johnson 说他的团队非常喜欢 Raft 的一个原因是 Leader 的故障恢复非常好定义，因为就是 Quorum 视图的变化。话虽如此，他说这真的不比 Multi-paxos 简单：

我们不得不做大量的工作，从让你异步读写磁盘到处理 Follower 忙于后台事务等场景，因为服务器上有其它东西或者磁盘非常慢，错误检查等等。

第二个组件是存储。目前主存储基于 RocksDB ，是一种构建于 Google LevelDB 的 Key/Value 存储结构。虽然它是 Key/Value 存储，Facebook 使用它来模拟其它数据结构。Apollo 被设计为可以存储未知的结构，团队也正在增加对 MySQL 的支持以作为一种替代存储引擎。

第三个组件是客户端 API，它拥有 read() 和 write() 方法。Apollo 在 Shard 层执行的所有操作都是原子操作，因此你可以描述前置条件，如果满足，它返回 reads 或 writes。代码示例如下：

read(conditions : {map(m1).contains(x)}, 
    reads : {deque(d2).back()})

上面的代码表示“如果 Map m1 包含 x，就返回双端队列（Deque）d2 的 back 上的值。”

你能将任意多个条件和任意数量的 Read 结合在一起。

Write 也非常类似，同样允许你描述条件：

write(conditions : {ver(k1) == v}, reads : {}, 
     writes : {val(k1) := x})

最后一个组件是容错状态机（Fault Tolerant State Machine，FTSM）。它们主要由系统代码使用，但也可以被用户代码使用。每个 FTSM 都属于 Shard，例如，在一个有三台机器的 Shard 中，它们全部同时执行相同的代码。它们能存取每台机器的持久化存储。最重要的是，如果一个节点故障，代码将按所有节点都同意的正确顺序继续执行。

状态机还被用于负载均衡、数据迁移、Shard 创建和销毁，以及协调跨 Shard 事务。状态机也存在外部副作用，例如它们能发送 RPC 请求到远程机器，但不论何时它们要变更持久化状态，都必须提交给 Raft 以取得所有服务器的同意。

Facebook 目前将 Apollo 用于替换 Memcached 的一些应用场景，同时 Johnson 也明确表示 Facebook 大规模地使用了 Memcached。该公司同时正在尝试使用它作为一种可靠的队列系统，用于发送 Facebook 消息到 iOS、Android 和运营商 SMS。它也可能用于更快速的分析。

Apollo 仍处于开发阶段，还没有开源，但 Johnson 说那是 Facebook 寻求并乐意去做的方式。Johnson 的演示稿已经提供给 QCon 纽约的参会者，在适当的时候会发布给所有人。

查看英文原文： Facebook Announces Apollo, a New NoSQL Database for On-line Low Latency Storage