结束语
如果你对于本文中所谈到的关于日志的大部内容，如下内容是您可以参考的其它资料。对于同一事务人们会用不同的术语，这会让人有一些困惑，从数据库系统到分布式系统，从各类企业级应用软件到广阔的开源世界。无论如何，在大方向上还是有一些共同之处。
学术论文、系统、评论和博客
关于状态机和主备份复现的概述。
PacificA是实施微软基于日志的分布式存储系统的通用架构。
Spanner-并不是每个人都支持把逻辑时间用于他们的日志，Google最新的数据库就尝试使用物理时间，并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。
Datanomic:解构数据库，它是Rich Hickey在它的首个数据库产品中的的重要陈述之一，Rich Hickey是Clojure的创建者。
在消息传递系统中回卷恢复协议的调查。我发现这个有助于引入容错处理和数据库以外的应用系统日志恢复。
Reactive Manifesto-事实上我并不清楚反应编程的确切涵义，但是我想它和“事件驱动”指的是同一件事。这个链接并没有太多的讯息，但由久富盛史的Martin Odersky讲授的课程是很有吸引力的。
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来构造规模一致的数据存储。
Paxos有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。
1)由Barbara Liskov提出的视图戳复现是直接进行日志复现建模的较早的算法。
2)Zab是Zookeeper所使用的算法。
3)RAFT是易于理解的一致性算法之一。由John Ousterhout讲授的这个视频非常的棒。
你可以的看到在不同的实时分布式数据库中动作日志角色：
1)PNUTS是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统。
2)Hbase和Bigtable都是在目前的数据库系统中使用日志的样例。
3)LinkedIn自己的分布式数据库Espresso和PNUTs一样，使用日志来复现，但有一个小的差异是它使用自己底层的表做为日志的来源。
流处理：这个话题要总结的内容过于宽泛，但还是有几件我所关注的要提一下：
1)TelegraphCQ
2)Aurora
3)NiagaraCQ
4)离散流：这篇论文讨论了Spark的流式系统。
5)MillWheel 它是Google的流处理系统之一。
6)Naiad：一个实时数据流系统
7)在数据流系统中建模和相关事件：它可能是研究这一领域的非常好的概述之一。
8)分布处式流处理的高可用性算法。
企业级软件存在着同样的问题，只是名称不同，或者规模较小，或者是XML格式的。哈哈，开个玩笑。
事件驱动——据我所知：它就是企业级应用的工程师们常说的“状态机的复现”。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。这种机制在应用开发中看起来是把发生在日志事件中的“流处理”和应用关联起来。因此变得不那么琐碎：当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。
变更数据捕获–在数据库之外会有些对于数据的舍入处理，这些处理绝大多数都是日志友好的数据扩展。
企业级应用集成，当你有一些现成的类似客户类系管理CRM和供应链管理SCM的软件时，它似乎可以解决数据集成的问题。
复杂事件处理(CEP)，没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。
企业服务总线(ESB)——我认为企业服务总线的概念类似于我所描述的数据集成。在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌生的。
