注意： 这一章还未完成编辑，你阅读的内容中还存在大量机器翻译的结果
附录A.参考
如果到目前为止，你将了解我对日志的大部分了解；这里有一些你可能想查看的有趣参考。
每个人似乎在同一事物上使用不同的术语，因此将数据库文献与分布式系统的内容连接到与开源世界相关的各种企业软件阵营，这有点令人困惑。但是，这里有一些提示。
学术论文，系统，讲座和博客
- 这些是状态机和主备份复制的良好概述。
- PacificA是用于实现基于日志的分布式存储的通用框架Microsoft系统。
- Spanner-并非每个人都喜欢逻辑上的日志记录时间。Google的新数据库尝试使用物理时间并直接通过处理时钟来确定时钟漂移的不确定性时间戳记作为范围。
- Datanomic：“解构数据库”是Rich Hickey的精彩演讲，Clojure的创建者，在其创业公司的数据库产品上。
- “消息传递系统中的回滚恢复协议调查”我发现这对容错和实际应用非常有用。记录到数据库外部恢复。
- “反应式宣言”-实际上我不太确定反应式是什么意思编程，但我认为它与“事件驱动”的含义相同。有很多信息，但是马丁·奥德斯基（Scala著名）的这一堂课看起来迷人。
- Paxos！莱斯利·兰帕特（Leslie Lamport）曾在该算法的创建过程中有过一段有趣的历史1980年代，但直到1998年才发表，因为评论家不喜欢希腊文寓言中的寓言，他不想更改它。原始论文发表后，人们对此还不太了解。兰珀特再次尝试这次甚至包括一些“有趣的细节”，例如如何放置他的使用实际计算机使用的算法。仍然没有被广泛理解。Fred Schneider和Butler Lampson分别提供了更详细的应用概述真实系统中的Paxos。
一些Google工程师总结了他们在以下方面实现Paxos的经验胖乎乎的我实际上发现所有Paxos论文都很难理解，但尽职尽责在他们中挣扎。
但是你不需要，因为John Ousterhout的这段视频（采用日志结构的文件系统而闻名）将使其变得非常简单。这些不知何故通过将共识算法绘制为交流的展开，而不是纸上的静态陈述。讽刺地，该视频是我认为最容易理解的Paxos概述，是在试图证明Paxos难以理解。“使用Paxos构建可扩展的一致数据存储” —这是一篇很酷的文章使用日志来建立数据存储。之一的合著者Jun也是最早的作者之一卡夫卡的工程师。 - Paxos有竞争对手！实际上，每个地图都更接近日志的实现，可能更适合实际实现：Barbara Liskov撰写的“ Viewstamped Replication”是一种直接建模的早期算法日志复制。Zab是Zookeeper内部使用的算法。RAFT尝试了一种更易于理解的共识算法。该视频John Ousterhout的演讲也很棒。
- 你可以在不同的实际分布式数据库中看到登录操作的作用：PNUTS是一个尝试应用传统的以日志为中心的设计的系统大规模分布式数据库。HBase和Bigtable都给出了现代数据库中日志的另一个示例。LinkedIn自己的分布式数据库Espresso与PNUTS一样，使用日志进行复制，但是通过使用基础表本身作为源采取了稍微不同的方法的日志。
- 如果你发现自己比较喜欢复制算法，那么本文可能帮助你。
- 复制：理论与实践是一本很棒的书，收集了许多摘要关于分布式系统中复制的论文。许多章节在线（对于例如1、4、5、6、7和8）。
- 流处理。总结起来有点太宽泛，但是我有几件事喜欢：“数据流系统中的模型和问题”可能是早期的最佳概述。在这方面的研究。“分布式流处理的高可用性算法”一些随机系统论文：
- “ TelegraphCQ”
- “极光”
- “ NiagaraCQ”
- “离散流”：本文讨论了Spark的流系统。
- “ MillWheel：Internet规模的容错流处理”描述了以下内容之一Google的流处理系统。
- “ Naiad：及时的数据流系统”
企业软件
企业软件界存在类似的问题，但名称不同。
活动采购
据我所知，事件源基本上是状态机复制与融合演化的一种情况。有趣的是，在不同的背景下会再次发明相同的想法。事件源似乎集中在不需要分区的较小的内存用例中。这种应用程序开发方法似乎将事件日志中发生的流处理与应用程序结合在一起。由于当处理足够大以至于需要进行数据分区以进行规模扩展时，这变得相当不平凡，因此我将流处理作为独立的基础结构原语进行处理。
更改数据捕获
从数据库中获取数据的行业很小，这是数据库数据提取的最日志友好的风格。
企业应用程序集成
当你拥有的是诸如CRM或供应链管理软件之类的现成企业软件集合时，这似乎是关于解决数据集成问题的。
复杂事件处理（CEP）
我可以肯定地说，没有人知道这意味着什么或它与流处理的实际区别。区别似乎在于，重点放在无序流以及事件筛选和检测上，而不是聚合上，但是在我看来，这是没有区别的区别。任何擅长一个的系统都应该擅长另一个。
企业服务总线
企业服务总线的概念与我描述的一些思想非常相似围绕数据集成。这个想法似乎在企业软件社区，在网络人士或分布式数据基础架构人群。
开源软件
可以提的开源系统实在太多，这里是一小部分：
- Kafka是“日志即服务”项目，这是本书大部分内容的灵感来源。
- BookKeeper和Hedwig组成了另一个开源的“日志即服务”。比事件数据更针对数据系统内部。
- Akka是Scala的衍生框架。它具有持久性模块，可提供持久性和日志记录。（甚至还有一个用于持久性的Kafka插件。）
- Samza是我们正在LinkedIn上开发的流处理框架。它使用很多本书中的思想，并与Kafka集成为基础日志。
- Storm是一种流行的流处理框架，可与Kafka很好地集成。
- Spark Streaming是Spark的一部分的流处理框架。
- Summingbird是Storm或Hadoop之上的一层，可为你提供方便计算抽象。
关于作者
Jay Kreps是LinkedIn的首席工程师，他是数据基础架构的首席架构师。他是多个开源项目的原始作者，其中包括Voldemort，Kafka，Azkaban和Samza。
版本说明
I♥原书封面上的动物是灰头的爱情鸟（Agapornis cana）。这些鹦鹉也被称为马达加斯加的爱情鸟，是非洲大陆以外唯一的爱情鸟物种。它们也是爱情鸟的最小种类，也是圈养中最难繁殖的物种之一。
成年雌性灰头爱情鸟完全是绿色的。只有成年男性的上胸部和头部呈灰色。完全长大的灰头爱情鸟只有约5英寸长，仅重30克。在野外，这些鸟通常聚集在巨大的鸡群中觅食并寻找伴侣。
尽管在19世纪后期被进口到欧洲进行航空养殖，但是很少有种鸽能够成功繁殖超过一到两代的灰头爱情鸟。这在很大程度上是由于鸟类对低温的不耐性，这使它们在欧洲秋季很难繁殖。甚至设法存活下来的小鸡也不是好宠物，因为它们通常太害羞和太紧张，无法接受人类作为朋友。当前，对这些鸟类有严格的出口规定，因此很难在其原生栖息地之外找到它们。
原书封面图片来自Lydekker的皇家自然历史。原书封面字体为URW Typewriter和Guardian Sans。原书文本字体为Adobe Minion Pro；原书标题字体为Adobe Myriad Condensed；原书代码字体是Dalton Maag的Ubuntu Mono。
章节列表：
网友评论