the-end.md

结束语及参考资料

1. 学术论文、系统、讨论和博客
2. 值得关注的开源软件

如果你从头一直读到了这，那么我对日志的理解你大部分都知道了。

这里再给一些有意思参考资料，你可以再去看看。

人们会用不同的术语描述同一事物，当你从数据库系统到分布式系统、从各类企业级应用软件到广阔的开源世界查看资料时， 这会让人有一些困惑。无论如何，在大方向上还是有一些共同之处。

学术论文、系统、讨论和博客

• 关于状态机和主备份复制的概述。
• PacificA是实施微软基于日志的分布式存储系统的通用架构。
• Spanner —— 并不是每个人都支持把逻辑时间用于他们的日志，Google最新的数据库就尝试使用物理时间，并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。
• Datanomic：解构数据库是 Rich Hickey （Clojure的创建者）在它的首个数据库产品中的重要陈述之一。
• 在消息传递系统中回滚恢复协议的调查。 我发现这是有关容错处理和通过日志在数据库之外完成恢复的实际应用的很不错的介绍。
• 反应式宣言（Reactive Manifesto） —— 我其实并不清楚反应式编程（reactive programming）的确切涵义，但是我想它和『事件驱动』指的是同一件事。 这个链接并没有太多的信息，但 Martin Odersky （Scala大拿）讲授的这个课程很精彩。
• Paxos!
  1. 原论文在这里。 关于作者 Leslie Lamport 发表的这篇论文有个有趣的历史：他在80年代就发明了这个算法，但直到1998年才发表出论文，原因是评审组不喜欢论文中的希腊寓言，而他又不愿修改。
  2. 甚至于论文发布以后，人们还是不怎么理解。Lamport 再次尝试，这次甚至包含了一些『无趣的细节』，关于如何在新型自动化计算机上应用算法的细节。 但算法仍然没有得到广泛的理解。
  3. Fred Schneider和Butler Lampson分别给出了更多细节关于在实时系统中如何应用Paxos。
  4. 一些Google的工程师总结了他们在Chubby中实现Paxos的经验。
  5. 我发现所有关于Paxos的论文理解起来很痛苦，但是值得我们费大力气弄懂。你不必忍受这样的痛苦了，因为日志结构的文件系统的大师John Ousterhout的这个视频 让这一切变得相当的容易。这些一致性算法用展开的通信图表述的更好，而不是在论文中通过静态的描述来说明。颇为讽刺的是，这个视频录制的初衷是告诉人们Paxos很难理解。
  6. 使用Paxos来构造规模一致的数据存储。这是一篇很棒的介绍使用日志来构造数据存储的文章，Jun 是文章的共同作者之一，他也是Kafka最早期的工程师之一。
• Paxos有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。
  1. 由 Barbara Liskov 提出的视图戳复现是直接进行日志复现建模的较早的算法。
  2. Zab是Zookeeper所使用的算法。
  3. RAFT是易于理解的一致性算法之一。由 John Ousterhout 讲授的这个视频非常的棒。
• 你可以的看到在不同的实时分布式数据库中动作日志角色：
  1. PNUTS是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统。
  2. Hbase和Bigtable都是在目前的数据库系统中使用日志的样例。
  3. LinkedIn自己的分布式数据库Espresso和PNUTs一样，使用日志来复现，但有一个小的差异是它使用自己底层的表做为日志的来源。
• 如果你正在做一致性算法选型，这篇论文会对你所有帮助。
• 复现：理论与实践，这是收录了分布式系统一致性的大量论文的一本巨著。网上有该书的诸多章节（1，4，5，6，7，8）。
• 流处理：这个话题要总结的内容过于宽泛，但还是有几件我所关注的要提一下：
  1. 在数据流系统中建模和相关事件：它可能是研究这一领域的最佳概述之一。
  2. 分布处式流处理的高可用性算法。
  3. 随机系统的一些论文：
     • TelegraphCQ
     • Aurora
     • NiagaraCQ
     • 离散流：这篇论文讨论了Spark的流式系统。
     • MillWheel 它是Google的流处理系统之一。
     • Naiad：一个实时数据流系统

企业级软件存在着同样的问题，只是名称不同，或者规模较小，或者是XML格式的。哈哈，开个玩笑。

• 事件驱动 —— 据我所知：它就是企业级应用的工程师们常说的『状态机的复现』。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。 这种机制在应用开发中看起来是把发生在日志事件中的『流处理』和应用关联起来。因此变得不那么琐碎： 当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。
• 变更数据捕获 —— 在数据库之外会有些对于数据的舍入处理，这些处理绝大多数都是日志友好的数据扩展。
• 企业级应用集成，当你有一些现成的类似客户类系管理CRM和供应链管理SCM的软件时，它似乎可以解决数据集成的问题。
• 复杂事件处理（CEP）没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。
• 企业服务总线（ESB） —— 我认为企业服务总线的概念类似于我所描述的数据集成。在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌生的。

值得关注的开源软件

• Kafka是把日志作为服务的一个项目，是后边所列各项的基础。
• Bookeeper 和Hedwig 另外的两个开源的『把日志作为服务』的项目。它们更关注的是数据库系统内部构件而不是事件数据。
• Databus是提供类似日志的数据库表的覆盖层的系统。
• Akka 是用于Scala的Actor框架。它有一个事件驱动的插件，提供持久化和记录。
• Samza是我们在LinkedIn中用到的流处理框架，它用到了本文论述的诸多理念，同时与Kafka集成来作为底层的日志。
• Storm是广泛使用的可以很好的与Kafka集成的流处理框架之一。
• Spark Streaming一个流处理框架，是Spark的一部分。
• Summingbird是在Storm或Hadoop之上的一层，提供了便利的计算抽象。

对于这一领域，我将持续关注，如果您知道一些我遗漏的内容，请您告知。

最后我留给你的信息是这个： 😸

---

« 第四部分：系统建设　　　　译跋 »