AL123 人文社科会员免费专区文学 2024-05-26

高可用架构（第1卷）_高可用架构社区_AZW3_MOBI_EPUB_PDF_电子书（无页码）

内容节选

第1章高可用架构案例精选 1.1 Twitter高性能分布式日志系统架构解析郭斯杰，Twitter高级工程师，是Twitter分布式日志系统DistributedLog/BookKeeper的主要技术负责人，同时也是Apache BookKeeper项目的PMC Chair。毕业于中科院计算所，加入Twitter之前，就职于Yahoo。专注于分布式消息中间件和分布式存储系统。 1.1.1 为什么需要分布式日志日志应该是程序员最熟悉的一种数据结构，因其存在于每天的工作中。它是一组只追加、严格有序的记录序列，如下图所示。日志已被证明是一种很有效的数据结构，可用来解决很多分布式系统的问题。在Twitter中，我们就用日志来解决很多有挑战的分布式系统问题。这里主要举一个例子，来展示我们如何使用日志在Manhattan（Twitter的最终一致性分布式key/value数据库）中实现Compare-And-Set（CAS）这样的强一致性操作。下面是一张Manhattan架构的简单抽象图。Manhattan主要由3个组件构成，Client、co-ordinator和replica。Client将请求发送给co-ordinator，co-ordinator找出修改键值（key）所对应的replica，然后修改replica。co-ordinator在发送请求的时候会附上相应的时间戳，replica根据时间戳来决定最后哪个修改会成功，实现最终一致性。如果我们需要在这个最终一致性的系统上实现CAS这样的强一致性操作，会碰到什么样的问题呢？答案是“冲突”！ “冲突”是什么意思呢？举个例子，如下图所示，假设有2个Client，它们同时想修改key x，但是要将它修改成不同的结果。左边的Client想将x从3改为4，而右边的Client想将x从3改为5。如下图所示，假设左边的Client成功地将第1个副本从3改为4；而右边的Client成功地将第3个副本从3改为5。那么左边的Client修改第3个副本将会失败，因为第3个副本的值已经变成了5。同样，右边的Client修改第1个副本也会失败。这就是之前提到的“冲突”，如下面的左图所示。因为你不知道这个系统中，x的最终值应该是4还是5，或者是其他值。更严重的是，系统无法从这个“冲突”状态中恢复，也就没有最终一致性可言。解决办法是什么呢？日志！我们使用日志来序列化所有的请求。使用日志后，请求流程如下面的右图所示，co-ordinator将请求写到日志中。所有的replica从日志中按顺序读取请求，并修改本地的状态。在这个例子中，将3修改为4的操作在将3修改为5的操作之前写入日志。因此，所有的副本会首先被修改成4。那么将3修改为5的操作将会失败。到此为止，你可以看出日志的好处——它将一个原本复杂的问题变得简单。这种解决问题的思路叫作Pub/Sub。而日志就是Pub/Sub模式的基础。因为Pub/Sub这个模式是那么简单而且强有力，这让我们思考，是不是可以构建一个高可用的分布式日志服务，所有在Twitter的分布式系统都可以复用这个日志服务？而构建一个分布式日志系统，首要的事情就是了解我们需要解决什么问题，满足什么样的需求。首先，作为一个基本设施，存储在日志中的数据需要持久化，这样才可以容忍宕机，避免数据丢失。因为还需要作为分布式系统的基础设施，那么在单机上持久化是远远不够的。我们需要将数据复制到多台机器上，提高数据和系统的可用性。当数据被复制到多台机器上，就要保证数据的强一致性。否则，如果出现丢数据、数据不一致，那么势必将影响到构建在分布式日志上的所有系统。如果连日志都不能相信了，你的生活还能相信谁呢？ 1.1.2 Twitter如何考虑这个问题为什么持久化（Durability）、多副本（Replication）和强一致性（Consistency）对我们来说这么重要呢？请带着这个问题读下去。我所在Twitter的组是messaging组。主要负责Twitter的消息中间件（在Twitter内部服务之间搬运数据），比如Kestrel（用于在线系统）、Kafka（用于离线分析）。这些系统都不支持严格的持久化，或者在支持持久化的情况下性能极差。它们采用定期回刷（periodic flush）磁盘或者依赖于文件系统（pdflush）来持久化数据。因为它们不支持持久化，所以当事故发生时，数据会丢失。一旦数据丢失，运维系统的人员就会非常痛苦。我们经常被责问，如何才能定量丢失的数据。这就让我们不禁在想，能否构建一个基于持久化和强一致的基础服务，如下图所示。在持久化和强一致性的基础上，它又是高性能的：可以支持低延时的在线系统（OLTP），比如数据库，支持实时的（real-time）、高吞吐的......