解决方案:我所读过的最好的一篇分布式技术文章

　　解决方案:我所读过的最好的一篇分布式技术文章

　　（点击上方公众号快速关注）。

　　资料来源：foreach_break，

　　前言

　　这是一份学习笔记。

　　学习材料来自Jay Kreps的日志博客文章。

　　原文很长，但我坚持阅读，收获颇丰，对 Jay 的技术能力、架构能力和对分布式系统的深刻理解印象深刻。同时，他有点沾沾自喜，因为他的一些理解与周杰伦的观点相吻合。

　　Jay Kreps是前LinkedIn首席参谋工程师，Confluent现任联合创始人兼首席执行官，以及Kafka和Samza的主要作者。

　　所谓笔记，读文章背，因为周杰伦哥自己在这一章里组织得太好了，他自己的科学素养和哲学素养也很高，所以他觉得很精彩的就不省略了。

　　I. 信息来源

　　日志：每个软件工程师都应该知道的关于实时数据的统一抽象（）

　　2. 注意事项

　　2.1 日志的值

　　1）日志是以下系统的核心：

　　2）日志可能与计算机一样古老，是分布式数据系统和实时计算系统的核心。

　　3）日志有很多名称：

　　4）不懂日志，就不能完全看懂

　　它

　　2.2 什么是日志？

　　2.2.1 概述

　　记录的顺序定义了时间等概念。

　　因为越靠左，记录越早。

　　条目的序号作为一种时间戳的概念，以及记录的顺序作为时间的概念可能看起来很奇怪，但正如您很快就会发现的那样，它可以很容易地将“时间”与任何特定的物理时钟分离。

　　日志与普通文件和表没有太大区别。

　　这样，你可能会觉得日志这么简单，还有需要讨论的吗？

　　其实日志的核心含义是：

　　日志记录发生了什么以及何时发生。

　　而这个通常是分布式系统最核心的东西。

　　请注意，这里有必要澄清几个概念：

　　2.2.2 数据库中的日志

　　Log的起源是未知的，就像发明二进制查找的人一样，很难意识到这项发明是一项发明。

　　日志早在IBM的System R中就出现了。

　　在数据库中，当数据库崩溃时，您需要使各种数据结构和索引保持同步。

　　为了确保原子性和持久性，数据库需要在修改数据结构和索引之前记录要修改的内容。

　　因此，日志记录何时发生某些事情，每个表和索引本身就是此历史信息的映射。

　　由于日志是立即持久的，因此在发生崩溃时，它将成为还原其他持久结构的可靠来源。

　　日志已经从 ACID 功能的实现发展成为数据库之间数据复制的一种方式。

　　显然，数据库中发生的一系列数据变化已经成为维持数据库之间同步最需要的信息。

　　Oracle，MySQL和PostgreSQL都收录日志传输协议，该协议将部分日志发送到用于持久复制的从属服务器。Oracle

　　的XStreams和GoldenState使用日志作为通用数据订阅机制，为非Oracle数据库提供订阅数据。

　　MySQL和PostgreSQL提供了类似的组件，这些组件是数据系统架构的核心。

　　面向机器的日志不仅可以用于数据库，还可以用于：

　　2.2.3 分布式系统中的日志

　　日志解决了分布式数据系统中的两个重要问题：

　　1） 有序数据更改

　　2） 数据分发

　　所谓的状态机复制原理：

　　如果两个确定性进程，从相同的状态开始，以相同的顺序，接收相同的输入，那么它们将产生相同的输出并以相同的状态结束。

　　确定性意味着处理过程与时间无关，并且处理结果不受其他输入的影响。

　　可以通过非确定性示例来理解：

　　所谓状态可以是机器上的任何数据，无论是在机器的内存中，还是处理完成后的磁盘上。值得注意的是，相同的

　　输入以相同的顺序产生相同的结果，这就是为什么日志如此重要的原因，这是一个直观的概念：如果你将相同的日志输入两个确定性程序，它们将产生相同的输出。

　　在分布式系统的构建中，认识到这一点，可以使：

　　让所有机器做同样的事情，协议是：

　　构建分布式、一致的日志系统，为所有处理系统提供输入。

　　日志系统的作用是分散所有输入流之上的不确定性，并确保处理相同输入的所有复制节点同步。

　　这种方法最好的一点是，您可以将索引日志的时间戳视为所有复制节点的时钟：通过使用复制节点处理的日志

　　中最大的时间戳作为复制节点的唯一 ID，时间戳与日志相结合可以唯一地表示节点的整个状态。

　　还有许多方法可以应用此方法：

　　从理论上讲，我们可以记录一系列机器指令，或者调用的方法的名称和参数，只要数据处理过程的行为相同，这些过程就可以保证节点之间的一致性。

　　玩数据库的人通常以不同的方式处理逻辑日志和物理日志：

　　对于分布式系统，通常有两种方法来处理复制和数据处理：

　　1） 状态机模型（主动 – 主动）

　　2） 主回模型（主动 – 被动）

　　如下图所示：

　　为了理解上述两种方法之间的区别，让我们看一个简单的例子：

　　现在，集群需要提供一个简单的服务来执行算术运算，例如加法和乘法。最初，维护一个数字，例如 0。

　　上面的例子也说明了为什么顺序是复制节点之间一致性的关键因素，如果这些操作的顺序被打乱，将获得不同的结果。

　　分布式日志，可以作为一些共识算法的数据结构：

　　表示有关下一个值的一系列决策的日志。

　　2.2.4 更新日志

　　从数据库的角度来看，记录数据更改的一组更改日志和表是双重且可互操作的。

　　1） 基于记录数据更改的日志，可以重构处于特定状态的表（也可以是非关系存储系统中带有键的记录）。

　　2）相反，如果表发生变化，则可以在日志中计算更改。

　　这正是您想要的准实时副本的秘密所在！

　　这与版本控制的作用非常相似：管理分布式、并发、状态更改。

　　版本控制工具（用于维护反映更改的修补程序）本质上是日志，您可以与签出的分支快照进行交互，该快照等效于数据库中的表。您会发现复制在版本控制和分布式系统中都是基于日志的：更新版本时，只需提取反映版本更改的修补程序并将其应用于当前分支快照。

　　2.3 数据集成

　　2.3.1 数据集成的含义数据

　　集成是为组织中的所有服务和系统提供数据。

　　事实上，数据的有效利用非常符合马斯洛的需求层次。

　　金字塔的底部是采集数据并将其集成到应用程序中（无论是实时计算引擎，文本文件还是Python脚本）。

　　并且需要转换这些数据，以保持易于阅读和处理的统一、标准化和整洁的格式。

　　一旦满足了上述要求，就可以开始考虑各种数据处理方法，如map-reduce或实时查询系统。

　　显然，如果没有可靠、完整的数据流，Hadoop 只是一个昂贵的、难以集成的加热器（集群是耗电的吗？）。

　　相反，如果可以确保数据流可靠、可用且完整，则可以考虑更高级的游戏玩法、更好的数据模型以及一致、更易于理解的语义。

　　然后，注意力可以转移到可视化、报告、算法和预测（挖掘器、深度）上。

　　2.3.2 数据集成的两种复杂性

　　事件事件

　　数据记录事件如何发生，而不仅仅是发生的情况，通常用作应用程序日志，因为它通常由应用程序系统写入。但这实际上混淆了日志的功能。

　　事实上，谷歌的财富是由建立在（用户）点击流和好恶（体验）上的关联管道产生的，点击流和展示是事件。

　　各种专业数据系统的爆炸式增长

　　为什么这些系统存在：

　　显然，将数据集成到这样的系统中对于数据集成来说是极其困难的。

　　2.3.3 基于日志结构的数据流

　　可以根据日志对每个逻辑数据源进行建模。

　　数据源可以是记录事件（命中和 PV）的应用程序，也可以是接受更改的数据库表。

　　每个订阅者都尽快从这些数据源生成的日志中获取新记录，将其应用于本地存储系统，并改善其在日志中的读取偏移。订阅者可以是任何数据系统，例如缓存、Hadoop、另一个站点的数据库或搜索引擎。

　　登录事实上，提供了一个逻辑时钟，用于测量不同订阅者

　　的状态以响应数据变化，因为这些订阅者在日志中具有不同且独立的读取偏移量，这就像时间意义上的“时刻”。

　　考虑这样一个示例、数据库和一些缓存服务器：

　　

　　日志提供了同步所有缓存服务器并推送它们所处的“时刻”的能力。

　　假设我们写一个编号为 X 的日志，读取来自缓存服务器

　　的数据，为了不读取旧数据，我们只需要确保在缓存服务器将数据（同步）复制到 X 位置之前我们不会从该缓存中读取任何内容。

　　此外，日志还提供了充当缓冲区的功能，以异步方式支持生产者和使用者的行为。

　　支持异步的最关键原因之一是订阅系统可能会崩溃，离线进行维护，然后重新上线，在这种情况下，每个订阅者都按照自己的节奏使用数据。

　　批处理系统（如 Hadoop 或数据仓库）使用数据

　　每小时或每天一次，而实时系统通常在几秒钟内消耗数据。

　　数据源或日志对使用数据的订阅者一无所知，因此需要在管道中无缝添加和删除订阅者。

　　更重要的是，订阅者只需要知道日志，不需要知道他们消费的数据来源，无论是RDBMS，Hadoop还是新流行的K-V数据库。之所以讨论日志，而不是消息系统，是因为不同的消息系统

　　保证了不同的特性，而word消息系统很难完全准确地表达某种语义，因为消息系统更重要的是重定向消息。

　　但是，日志可以理解为提供持久性保证和强有序语义的消息系统，这在通信系统中称为原子广播。

　　2.4 LinkedIn

　　LinkedIn目前的主要系统包括（注：2013年）：

　　每个系统在其专业领域都提供专门的高级功能。

　　（这一段太长太长了，周杰伦哥很擅长，所以挑重点记住！

　　1）引入数据流的概念是因为在Oracle数据库中的表之上建立了抽象缓存层，为搜索引擎索引构建和社交图谱更新提供扩展能力。

　　2）为了更好的处理LinkedIn的一些推荐算法，我开始构建Hadoop集群，但团队在这方面的经验还不多，所以我走了不少弯路。

　　3）一开始，这只是一个粗略的想法，即将数据从Oracle数据仓库中提取出来并将其扔到Hadoop中是可以的。结果发现：首先，从Oracle数据仓库快速导出数据是一场噩梦;其次，也是更糟糕的是，数据仓库中的一些数据没有得到正确处理，导致Hadoop批处理任务无法按预期输出结果，并且通过Hadoop批处理执行的任务通常是不可逆的，尤其是在报告出来之后。

　　4）最后，团队离开数据仓库，直接进入数据库和日志作为数据源。接下来，建造了一个轮子：K-V 存储（伏地魔）。

　　5）即使是像数据复制这样普通的工作也会占用团队的大量时间来处理，更糟糕的是，一旦数据处理管道中存在一个点，Hadoop立即变得浪费，因为无论算法在错误数据上运行多么出色，只有一个后果，那就是产生更多错误的数据。

　　6）即使团队在高度抽象上构建了一些东西，每个数据源也需要特定的配置，这是许多错误和失败的根源。

　　7）大量的程序员想要跟进，每个程序员都有大量的想法，集成这个系统，添加这个功能，集成这个功能，或者想要自定义数据源。

　　8）周杰伦弟兄开始意识到：

　　首先，他们修建的管道虽然还很粗糙，但价值极高。即使解决数据在新系统（如Hadoop）中可用的问题，也可以解锁大量可能性。以前难以进行的计算开始成为可能。只需从其他系统解锁数据并集成它们，即可轻松创建新产品和分析。其次，很明显，可靠的数据加载

　　需要更坚实的支持，如果可以捕获所有结构，Hadoop数据加载可以完全自动化，而无需添加新数据源或手动修改数据的模式。数据会神奇地出现在HDFS中，当添加新的数据源时，Hive的表会自动自适应地生成相应的列。

　　第三，数据覆盖面远远不够。很难处理许多新的数据源。

　　9）为了解决添加新数据源后的数据加载问题，团队开始了这样的尝试：

　　很快，他们发现这行不通，因为发布和订阅，生产和消费，数据流通常仍然是双向的，这变成了O（n^2）问题。

　　所以，他们需要的是这样的模型：

　　每个使用者都需要与数据源隔离，理想情况下只与一个数据存储库交互，该存储库为他们提供对任意数据的访问权限。

　　10）消息系统+日志=卡夫卡，卡夫卡诞生了。

　　2.5 日志ETL与数据仓库的关系

　　2.5.1 数据仓库

　　1） 一个干净、结构化、集成的数据存储库，用于分析。

　　2）虽然这个想法很棒，但获取数据的方式有点过时了：定期从数据库中获取数据并将其转换为更易读的格式。

　　3）以前的数据仓库问题是干净的数据和数据仓库是高度耦合的。

　　数据仓库应该是一组查询功能的集合，服务于报表、搜索、广告热分析，包括计数、聚合、过滤等操作，所以它应该是一个批处理系统。

　　但是干净数据与这种批处理系统的高度耦合意味着这些数据不能被实时系统消费，例如搜索引擎索引，实时计算和实时监控系统等。

　　2.5.2 ETL

　　Jay认为ETL只做两件事：

　　1）数据提取和清理，从特定系统解锁数据

　　2）重构数据，以便可以通过数据仓库进行查询。例如，更改数据类型以适应关系数据库的类型，将架构转换为星形或雪花图案，或将其分解为面向列的存储格式。

　　但是将这两件事结合在一起是一个大问题，因为集成的、干净的数据应该被其他实时系统、索引系统和低延迟处理系统使用。数据仓库团队

　　负责采集和清理数据，但这些数据的生产者往往不知道数据仓库团队的数据处理需求，导致数据难以提取和清理。

　　同时，由于核心业务团队对跟上公司其他部门的步伐不敏感，真正可以处理的数据覆盖率很低，数据流很脆弱，很难快速响应变化。

　　所以，一个更好的方法：

　　如果要在干净的数据集上做一些搜索、实时监控趋势图、实时告警，不宜使用原创数据仓库或Hadoop集群作为基础设施。更糟糕的是，ETL为数据仓库构建的数据加载系统对其他（实时）系统几乎没有用处。

　　最好的模型是完成在数据发布者发布数据之前进行数据

　　清理过程，因为只有发布者最了解其数据的外观。在此阶段完成的所有操作都应该是令人满意的无损和可逆的。

　　所有丰富的语义或附加值的实时转换都应在原创日志后处理之后进行后处理，包括为事件数据建立会话或添加某些感兴趣的字段。原创日志仍然可以单独使用，但此类实时应用程序也会派生新的参数化日志。

　　最后，只有与特定目标系统相对应的数据聚合操作才应成为数据加载的一部分，例如转换为星形或雪花图案，以便在数据仓库中进行分析和报告。因为这个阶段，就像传统的ETL一样，由于一个非常干净和标准化的数据流，（带日志）现在非常简单。

　　2.6 日志文件和事件

　　一

　　以日志为核心的架构还有一个额外的好处，那就是易于实现无耦合、事件驱动的系统。

　　捕获用户活动和系统变化的传统方法是将这些信息写入文本日志，然后将其提取到数据仓库或 Hadoop 集群中进行聚合和处理，这类似于前面描述的数据仓库和 ETL 问题：数据与数据仓库高度耦合。

　　在LinkedIn，它构建了一个基于kafka的事件数据处理系统。为各种操作定义了数百种事件类型，从 PV、广告展示、搜索到服务调用和应用程序异常。

　　要了解上述事件驱动系统的好处，请考虑一个简单的事件示例：

　　在“工作机会”页上，提供机会。此页面应仅负责如何呈现机会，不应收录太多其他逻辑。但是，您会发现在相当大的网站中执行此操作很容易涉及越来越多的与演示机会无关的逻辑。

　　例如，我们要集成以下系统功能：

　　1）我们需要将数据发送到Hadoop和数据仓库进行离线处理。

　　2）我们需要计算页面浏览量，以确保某些视图不是用于抓取Web内容或任何东西。

　　3） 我们需要汇总此页面上的浏览信息，以显示在业务机会发布商的分析页面上。

　　4）我们需要记录一个用户浏览这个页面的历史记录，以确保我们为这个用户提供任何适合这个用户的工作机会，有价值和良好的体验，而不是一遍又一遍地反复向这个用户展示一个机会（想想只有老婆不在家的时候才能玩的游戏， 红绿蓝闪烁的特效，配上轰轰烈烈的DJ风格舞曲，或是事业巅峰和穿短裙的女生的摇摆焦点，再点击发现是标题党的广告！）。

　　5）我们的推荐系统需要记录此页面的浏览历史记录，以正确跟踪此工作机会的受欢迎程度。

　　很快，仅显示机会的页面的逻辑变得复杂。当我们把这个机会也添加到移动端时，我们也不得不迁移逻辑，这增加了复杂性。诀窍是，在此页面上工作的工程师需要了解其他系统，以确保正确集成上述功能。

　　这只是一个非常简单的例子，在实践中，情况只会变得更加复杂。

　　事件驱动可以使这变得容易。负责展示机会的页面

　　只需要展示机会并记录一些与演示相关的因素，例如工作机会的属性、查看页面的人员以及其他有用的演示相关信息。页面不需要维护其他系统的知识和知识，例如推荐系统、安全系统、机会发布者分析系统、数据仓库等，所有这些系统只需要以订阅者的身份订阅事件，然后独立处理，而提供机会的页面不需要修改新的订阅者或消费者加入。

　　2.7 构建可扩展日志

　　分离发布者和订阅者并不是什么新鲜事，但日志系统很难确保多个订阅者可以实时处理消息，同时确保可扩展性。如果日志构建

　　速度不快、开销低且可扩展，那么在此日志系统之上构建的所有好处都消失了。

　　许多人可能认为日志记录系统在分布式系统中是一项缓慢而昂贵的工作，并且仅用于处理元数据等信息，类似于 ZooKeeper 更适合处理的内容。

　　但是LinkedIn现在每天在kafka中处理600亿次不同的消息写入（如果算上数据中心镜像，则为数千亿次写入）。

　　周杰伦兄弟，他们是怎么做到的？

　　1） 对日志进行分区

　　2） 通过批量读取和写入优化吞吐量

　　3） 避免不必要的数据复制

　　通过将日志切片为多个分区来提供可扩展性：

　　1）每个分区都是有序日志，但分区之间没有全局顺序。

　　2）将消息写入哪个分区完全由编写器控制，方法是根据某种类型的键（例如user_id）对其进行拆分。

　　3）拆分允许在不协调分片的情况下执行日志的附加操作，同时保证系统的吞吐量与Kafka集群的大小呈线性相关。

　　4）虽然没有全局顺序（实际上有成千上万的消费者或订阅者，讨论他们的全局顺序通常没有什么价值），但Kafka提供了一个保证，发送方以什么顺序向一个分区发送消息，以及消息从这个分区传递的顺序（以什么顺序，以什么顺序）。

　　5）每个分区按照配置的编号进行复制，如果一个领导节点挂起，其他节点将成为新的主节点。

　　6）一个日志，就像文件系统一样，线性读写模式可以优化，这样一个小的读写日志就可以组成更大的、高吞吐量的操作。卡夫卡在这件事上做得很艰难。批处理用于各种场景，例如客户端向服务器发送数据、将数据写入磁盘、在服务器之间复制数据、向消费者传输数据、确认提交数据等。

　　7）最后，Kafka对内存日志，磁盘日志和通过网络发送的日志使用非常简单的二进制格式，以方便使用各种优化技术，例如零拷贝数据传输。

　　许多优化技术结合在一起，允许您以磁盘或网络可以提供的最大容量读取和写入数据，即使内存已满也是如此。

　　2.8 日志和实时处理

　　你认为周杰伦提供了一种如此漂亮的方法来复制数据并复制它吗？

　　你！错！完成！日志是

　　流式处理的另一种说法，日志是流处理的核心。

　　2.8.1 什么是流处理

　　？

　　周杰伦哥认为：

　　1）流处理是连续数据处理的基础设施。

　　2）流处理的计算模型，如MapReduce或其他分布式处理框架，只需要保证低延迟。

　　3）批处理式数据采集模式导致批量式数据处理模式。

　　4）连续的数据采集模式，导致连续的数据处理模式。

　　5）杰伊哥讲解美国人口普查方式解释批处理。

　　在LinkedIn，活动数据和数据库更改都是连续的。

　　

　　批处理每天处理数据，类似于连续计算，将窗口设置为一天。

　　因此，流处理是一个这样的过程：

　　6）在处理数据时，有时间的概念，不需要维护数据的静态快照，因此结果可以以用户定义的频率输出，而无需等待数据集达到某个“结束”状态。

　　7）从这个意义上说，流处理是批处理的泛化，鉴于实时数据的普及，这是一个极其重要的泛化。

　　8）许多商业公司无法构建流处理引擎，通常是因为他们无法构建流数据采集引擎。

　　9） 流处理弥合了实时响应服务和离线批处理基础设施之间的差距。

　　10）日志系统，解决了流处理模式下的许多关键问题，其中最大的问题是如何在实时多订阅者模式下提供可用数据（流数据采集）。

　　2.9 数据流图

　　关于流处理最有趣的事情是它扩展了源的概念。

　　无论是日志、源还是事件，逐行数据记录都来自应用程序的活动。

　　但是，流式处理还允许我们处理来自其他源的数据，这些数据与提供给消费者的原创数据一样好，并且这些派生源可以收录任何级别的复杂性。

　　流处理任务应如下所示：从日志中读取数据并将输出写入日志或其他系统。

　　作为输入和输出日志，进程本身和其他进程连接起来形成一个图。

　　事实上，以日志为中心的系统允许您从组织捕获、转换和流式传输数据，作为一系列日志和写入日志处理的组合。

　　流处理程序不必很高：它可以是一个进程或一组进程，但可以提供一些额外的基础结构和支持，以便更轻松地管理用于处理的代码。

　　引入日志有两个目的：

　　1）确保数据集可以支持多个订阅者模式并且有序。

　　2）可以用作应用程序的缓冲区。这一点很重要，因为在异步数据处理过程中，如果上游生产者更快地生成数据并且使用者无法跟上，则要么阻塞该过程，要么引入缓冲区，要么丢弃数据。

　　丢弃数据似乎不是一个好的选择，阻塞处理进程会导致处理进程在所有数据流的处理图中卡住.log另一方面是一个大的、超大的、非常大的缓冲区，它允许重启处理进程，这样如果一个进程失败， 它不会影响流处理图中的其他进程。这对于大型组织扩展数据流至关重要，因为不同的团队有不同的处理任务，显然整个流处理过程不会因为一个任务中的错误而停滞不前。

　　Storm 和 Samza 就是这样的流处理引擎，它们都可以使用 Kafka 或其他类似的系统作为它们的日志系统。

　　（注：周杰伦哥哥挺凶悍的，卡夫卡在前，三轮在后。

　　2.10 有状态实时处理许多流处理

　　引擎是无状态的，一次一条记录，但许多用例需要在一定的时间窗口内进行复杂的计数、聚合和联接操作才能进行流处理。

　　例如，在点击流中，联接用户信息。

　　然后，此用例需要状态支持。在处理数据的地方，需要维护特定数据的状态。

　　问题是，在处理器可能挂断的情况下，如何保持正确？

　　在内存中维护状态可能是最简单的，但它不会承受崩溃。

　　如果状态仅在某个时间窗口内保持，则当发生挂起或故障时，则可以将处理直接重放回窗口的开头，但如果窗口长达 1 小时，则可能不起作用。

　　另一种简单的解决方案是将状态存储在远程存储系统或数据库中，但这会丢失数据的局部性并产生大量的网络往返。

　　回想一下上面提到的数据库中表和日志的双重性。

　　可以使用本地存储或索引来维护状态的流处理组件：

　　通过记录有关本地索引的更改日志，它用于在崩溃后还原状态。实际上，此机制还揭示了一种通用状态，该状态可以存储为任意索引类型，并与输入流同时进行共分区。

　　当处理过程崩溃时，它可以从更改日志中恢复索引，更改日志充当本地状态基于时间备份的某种增量记录的转换器。

　　这种机制也提供了一个非常优雅的能力：进程本身的状态也可以记录为日志，显然其他进程可以订阅这个状态。

　　结合数据库中的日志技术，对于数据集成的场景，你经常可以做非常强大的事情：

　　通过从数据库中提取日志并在各种流处理系统中为它们编制索引，可以联接不同的事件流。

　　2.11 日志合并

　　显然，不可能使用日志来记录全职和全职状态变化信息。

　　Kafka 使用日志合并或日志垃圾回收技术：

　　1） 对于事件数据，Kafka 只保留一个时间窗口（可按时间配置为天或按空间配置）。

　　2）对于键控更新，Kafka使用压缩技术。这种类型的日志可用于通过另一个系统中的重放技术重建源系统的状态。

　　如果全时保存日志，随着时间的推移，数据会越来越大，重放过程也会越来越长。

　　Kafka 不是简单地丢弃旧的日志信息，而是使用合并方法来丢弃过时的记录，例如消息的主键最近是否更新。

　　2.12 系统构建

　　2.12.1 分布式系统

　　日志，在数据流系统和分布式数据库的数据集成中所扮演的角色是相同的：

　　您可以将组织中的应用程序和数据流视为单个分布式数据库。

　　将面向查询的独立系统（如 Redis、SOLR、Hive 表等）视为特殊的数据顶级索引。

　　将 Storm 和 Samza 等流处理系统视为精心设计的触发器或物化视图机制。

　　各种数据系统，爆发式涌现，其实这种复杂性早已存在。在关系数据库

　　的鼎盛时期，公司或组织的光学关系数据库有很多种。显然，不可能

　　把所有东西都扔到Hadoop集群中，并期望它能解决所有问题。那么，如何构建一个好的系统，可能是这样的：

　　要构建一个分布式系统，每个组件都是一个小集群，每个集群可能无法提供完整的安全性、性能隔离或良好的可扩展性，但每个问题都可以（专业地）解决。

　　Jay认为，各种系统之所以爆炸式增长，是因为构建一个强大的分布式系统非常困难。如果将用例限制为查询等简单场景，则每个系统都有足够的能力来解决问题，但很难集成这些系统。

　　杰伊弟兄认为，未来构建系统有三种可能：

　　1）维持现状。在这种情况下，数据集成仍然是最大的问题，因此外部日志系统很重要（kafka！）

　　2）一个强大的（关系数据库，如辉煌的日子）系统似乎不太可能解决所有问题。

　　3）新一代系统大多是开源的，这揭示了第三种可能：数据基础设施可以离散化为一组服务，以及面向应用的系统API，每个都不完整，但可以专业解决专门的问题，其实现有的Java技术栈可见一斑：

　　从某个

　　从这个角度来看，构建这样的分布式系统就像某个版本的乐高。这显然与更关心 API 的最终用户没有太大关系，但它揭示了构建健壮系统并保持简单性的途径：

　　显然，如果构建分布式系统的时间从几年下降到几周，构建大型独立系统的复杂性就会消失，而这肯定是因为出现了更可靠和灵活的“构建块”。

　　2.12.2 登录在系统建设中的作用

　　如果系统受外部日志系统支持，

　　那么每个独立的系统都可以通过共享一个日志来降低自身的复杂性，Jay Ge认为日志的作用是：

　　1）处理数据一致性问题。可以通过序列化节点上的并发操作来实现即时和最终一致性。

　　2） 提供节点间的数据复制。

　　3）提供“提交”的语义。例如，如果您认为写入操作不会丢失，则为操作确认。

　　4） 提供外部系统可以订阅的源。

　　5） 提供在节点因故障而丢失数据时恢复或重建新复制节点的功能。

　　6） 处理节点之间的负载均衡。

　　以上可能是完整分布式系统中应该提供的大多数功能（Jay 确实喜欢 Log！剩下的就是客户端 API，构建索引等内容（如全文索引）需要获取所有分区，而针对主键的查询只需要提取分区中的数据。

　　（那剩下的就照顾好了，周杰伦哥哥！

　　该系统可以分为两个逻辑组件（这种强大的理解和力量）：

　　1） 日志层

　　2） 服务层

　　日志层以序列化和有序的方式捕获状态更改，而服务层存储外部查询所需的索引，例如，K-V 存储可能需要 B 树和稳定索引，而搜索服务需要倒排索引。

　　写入操作可以直接输入到日志层中，也可以通过服务层代理。写入日志会产生逻辑时间戳（日志索引），例如数字 ID，如果系统已分区，则服务层和日志层将具有相同的分区（但它们各自的机器编号可能不同）。

　　服务层订阅日志层，并在以

　　最快的速度顺序存储日志，并将数据和状态变化同步到自己的本地索引中。

　　客户端将获得读写语义：

　　通过携带写入任一节点（服务节点）的时间时间戳Layer 接收此查询，将时间戳

　　与其本地索引进行比较，如有必要，为了防止返回过期的旧数据，请推迟请求的执行，直到此服务节点的索引同步跟上时间戳。

　　服务层中的节点可能需要也可能不需要知道领导者的概念。在许多简单的用例中，服务层无法构建领导节点，因为日志是事实的来源。

　　还有一个问题是如何处理节点故障后的恢复。这可以通过在日志中保留固定大小的时间窗口同时维护数据的快照来完成。您还可以让 Log 保留数据的完整备份，并使用日志合并技术完成 Log 本身的垃圾回收。这种方法将服务层的大部分复杂性转移到日志层，因为服务层是特定于系统的，并且日志层可以是通用的。

　　基于日志系统，可以提供一套完整的API供开发和使用，可以作为其他系统的ETL数据源，供其他系统订阅。

　　全栈 ！ ：

　　显然，以日志为核心的分布式系统立即成为可以为其他系统提供数据加载支持和数据流处理的角色。同样，流处理系统可以同时使用多个数据流，并通过索引这些数据流然后输出它们来向外部世界提供服务。系统基于

　　日志层和服务层构建，使查询相关因素与系统的可用性和一致性脱钩。

　　也许很多人认为在日志中维护数据的单独备份，尤其是制作数据的完整副本，太浪费和奢侈，但事实并非如此：

　　1）LinkedIn的Kafka生产集群每个数据中心维护75TB的数据，应用集群比Kafka集群需要更高的存储空间和存储条件（SSD+更多内存）。

　　2）全文搜索索引最好全部加载到内存中，日志可以便宜使用，大容量磁盘因为它们是线性读写的。

　　3） 由于 Kafka 集群实际上以多订阅者模型运行，多个系统使用数据，因此日志集群的开销被摊销。

　　4）由于所有这些原因，外部日志系统（kafka或类似系统）的开销变得非常小。

　　2.13 结论

　　最后，周杰伦哥不仅大方地留下了大量有价值的学术和工程论文和参考链接，还虚心留下了这样一句话：

　　如果你做到了这一步，你就知道我对日志的大部分了解。

　　认为这篇文章对您有帮助吗？请与更多人分享

　　关注“*敏*感*词*新品”查看技术干货

　　解决方案:网站优化排名软件有哪些，seo优化必备的5种工具

　　2019年哪些工具可以辅助SEO网站优化？

　　很多公司在做优化的时候都想知道有哪些工具可以辅助优化？这是每个seo都会遇到的问题。哪些工具可以辅助优化？网站 可以排名更好吗？哪些工具可以经常使用 什么？下面小编就为大家详细讲解一下。

　　推荐几款专业的SEO网站优化工具？

　　SEO工具是搜索引擎优化的各种工具，如查询工具、排名工具、流量分析软件、站群软件等，善用各种工具可以节省大量时间，让SEO服务更轻松.

　　1.站长平台

　　

　　1：百度站长平台：百度站长工具提供Sitemap提交、死链接提交、网站安全检测、URL优化建议、百度索引查询等功能。

　　2：搜狗站长平台：搜狗站长工具提供Sitemap提交、匹配网站logo、域名更改、爬虫压力反馈、死链接提交、URL提交、收录索引量和关键词排名查询等功能。

　　3：360站长平台：360站长平台提供与上述两个站长平台几乎相同的功能，主要包括：数据提交、网站数据分析、网站保护和网站安全检测和其他功能。

　　2.SEO综合查询工具

　　1：爱站：一个非常好用的SEO网站优化综合查询工具，可用于查询百度权重、亲情链接、百度索引量、备案信息、关键词挖掘等信息。

　　2：站长工具：站长工具的功能和爱站差不多。这里值得一提的是，使用站长工具和爱站工具查询数据的结果有些不同。这是因为两个工具的数据计算不同是正常现象。

　　3：5118：5118是SEO网站优化师的必备工具，也是挖掘长尾词的最佳工具。通过此，您可以了解SEO数据的实时变化和关键词排名的具体趋势变化，指导关键词的建设。

　　拼多多的运营工具有哪些（揭秘拼多多营销工具攻略）

　　

　　免费推广工具有哪些（推广工具内部情况综合分析）

　　有哪些网络推广软件（好用工具分享）

　　微信推广软件有哪些（微信推广3款工具解析）

　　常用的ui设计工具有哪些（最好用的7款ui设计工具）

　　公众号文章排版工具有哪些（最实用的3款排版工具）

　　【本文标题及网址，转载请注明出处】网站优化排名软件有哪些，SEO优化必备的5个工具

　　内容更新时间（UpDate）：2022年11月18日星期五