高可用架构（第1卷） - (EPUB全文下载)

文件大小：0.96 mb。
文件格式：epub 格式。
书籍内容：

高可用架构（第1卷）
第1章 高可用架构案例精选
第2章 高可用架构原理与分布式实践
第3章 电商架构热点专题
第4章 容器与云计算
第5章 运维保障
第6章 大数据与数据库
第7章 安全与网络
第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）、高吞吐的流式分析和高通量的批量离线分析。同时能够很好地扩展，以支持构建在分布式日志之上的系统的扩展性。
在深入之前，先强调一点：我所提到的“Low Latency”和“High Throughput”在分布式日志系统中指什么？下面我会给出答案。
日志系统的核心负载可以归为3类：write、tailing read和catch-up read。write就是将数据追加到一个日志中，tailing read就是从日志的尾部读最新的东西，而catch-up read则是从比较早的位置开始读日志（比如数据库中重建副本）。write和tailing read在意的是延时（latency），因为它关系到一个消息从被写入到被读到的时间。因此前文中说的 High Throughput指的是catch-up read，而Low Latency指的是tailing read和write。而catch-up r ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。