架构师训练营第五周学习总结
这周的内容主要有缓存、异步、负载均衡和一部分数据库。
第一部分是缓存。缓存的两种主要思想是代理缓存和反向代理缓存。

分布式缓存Memcached

一致性哈希

各种介质数据访问延时

看似普通的一组数据,大致给出了不同硬件和不同网络条件下的访问延迟。不过有趣的是非SSD硬盘的读取速度竟然已经慢于同数据中心的往来。同样有趣但很容易被忽略的是跨大西洋访问的基础延迟为150ms,这证明跨太平洋的访问只会更慢。
简单查询了一下(未确认数据来源及准确性):
Distance is a key determinant of latency, the round-trip time required to send a packet of data from one device to another. Transmitting data from the U.S. East Coast to the West Coast, for example, might have a latency between 40 and 50 milliseconds. The round-trip time for the same message going from North America to Europe might range from 80 to 90 milliseconds -- almost twice as long. Sending data across the Pacific Ocean can take even longer, with latency times of more than 100 milliseconds.[1]
这似乎说明了这种远距离使用一些特定网络服务的困难程度,几乎唯一的方法就是在当地假设服务器。
之后介绍了一些合理使用缓存的注意事项,如频繁修改、无热点访问、数据不一致、缓存雪崩(无法简单重启崩溃的缓存服务器)、缓存预热、缓存穿透(为不存在的数据建立缓存)。
还有 Redis 原理

在课件中有这个一个引用,Phil Karlton说:“计算机科学中只有三件事最困难:缓存失效,命名事物,计数错误。”本着好奇的心态试着找了以下原文,发现是:
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Kalton[2]
有趣的是,这里给出的引用来源并没有给出这句话的出处,而是由他的儿子David Karlton认同这句话出自他父亲之口,但不知确切来源。另一个有趣的事实是,课件中引用的是这句话的变体,增加了计数错误这一点。不过我发现,下面这个变体显然更有韵味:
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one error.
接下来内容是异步与消息队列,介绍了点对点模型和发布订阅模型。使用消息队列的好处包括:异步处理、伸缩性好、削峰填谷、失败隔离、自我修复、生产者与消费者解耦。
异步的思想在平时应用的比较多,在我现在的工作中接触的一款传统软件中,虽然不涉及互联网,但是由于也需要处理一些并发的请求,使用了消息队列。这里是将该思想应用到了分布式系统中,消息队列是一个典型的异步实现方式。课程中也介绍了事件驱动架构(EDA),在我看来,一般提到消息队列指的是点对点模型的实现,而事件驱动指的是发布订阅模型的实现。
这里老师在提到如何选择消息队列技术的时候提出了一个“根据搜索结果数量进行技术选型”的观点,通俗易懂。
接下来一个模块是负载均衡,利用之前提到的代理与反向代理缓存思想,并采用异步使客户端无需关心后台具体响应时间。我认为负载均衡是综合这部分内容的具体实现方案。
负载均衡架构

HTTP重定向负载均衡

DNS负载均衡

反向代理负载均衡

IP负载均衡

数据链路层负载均衡

随后介绍了一些 Session 管理的内容,几个常见的 Session 管理方法包括:Session 复制,Session 绑定,Cookie,Session 服务器,不过前三种已经基本淘汰了。
最后还包括了一些关于数据库的内容,考虑到内容的完整性,下次再对数据库进行总结。
版权声明: 本文为 InfoQ 作者【whiter】的原创文章。
原文链接:【http://xie.infoq.cn/article/fa7910a1983eafd218a449079】。未经作者许可,禁止转载。
评论