第五周总结

分布式缓存架构

缓存：缓存是介于数据访问者和数据源之间的一种高速存储，当数据需要多次读取的时候，用于加快读取的速度

缓存应用场景

CPU缓存

操作系统缓存

数据库缓存

JVM编译缓存

CDN缓存

代理与反向代理缓存

前端缓存

应用程序缓存

分布式对象缓存

缓存原理Hash表

1. 根据key值计算hashCode

2. 通过hash函数计算整个key-value对象在hash表中的地址

3. 根据地址取到key-value对象

缓存的关键指标

缓存命中率：缓存是否有效依赖于能多少次重用同一个缓存响应业务请求，这个度量指标被称作缓存命中 率

影响缓存命中率的主要指标：缓存键集合大小，缓存可使用内存空间，缓存对象生存时间

分布式缓存对象的一致性hash算法

为什么需要一致性hash算法：

通过取余等普通的hash算法进行集群服务器的选择不容易扩展，新增服务器或删除服务器会导致大部分hash结果发生变化，最终无法命中缓存，可能会压垮应用服务器

一致性hash步骤

1. 按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中，即0~(2^32)-1的数字空间中。现在我们可以将这些数字头尾相连，想象成一个闭合的环形

2. 将机器通过hash算法映射到环上

3. 把数据通过一定的hash算法处理后映射到环上

机器的删除与添加

如果NODE2出现故障被删除了，那么按照顺时针迁移的方法，key2和key5将会被迁移到NODE1中，这样仅仅是key2和key5的映射位置发生了变化，其它的对象没有任何的改动

如果往集群中添加一个新的节点NODE3，key0和key3会被映射到NODE3，其它的对象没有任何的改动

合理使用缓存

使用缓存对提高系统性能有很多好处，但是不合理的使用缓存可能非但不能提高系统的性能，还会成为系统的累赘，甚至风险。缓存使用需注意一下几点：

• 频繁修改的数据：这种数据如果缓存起来，由于频繁修改，应用还来不及读取就已失效 或更新，徒增系统负担。一般说来，数据的读写比在2:1以上，缓存才有意义。

• 没有热点的访问：缓存使用内存作为存储，内存资源宝贵而有限，不能将所有数据都缓 存起来，如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问不是集 中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被 挤出缓存了

• 数据不一致与脏读：一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数 据库中重新加载。因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性， 但是需要过一段时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的， 但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存，不过也会带来 更多系统开销和事务一致性的问题。因此数据更新时通知缓存失效，删除该缓存数据， 是一种更加稳妥的做法。

• 缓存雪崩：缓存是为了提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到 应用程序的处——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大 部分的数据访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃的时候， 数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况， 被称作缓存雪崩，发生这种故障，甚至不能简单的重启缓存服务器和数据库服务器来恢 复网站访问

• 缓存预热：缓存中存放的是热点数据，热点数据又是缓存系统利用LRU（近久未用） 算法对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间，在这段时间， 系统的性能和数据库负载都不太好，那么好在缓存系统启动的时候就把热点数据加载 好，这个缓存预加载手段叫做缓存预热（warm up）。对于一些元数据如城市地名列表、 类目信息，可以启动时加载数据库中全部数据到缓存进行预热

• 缓存穿透：如果不恰当的业务、或者恶意攻击持续高并发的请求某个不存在的数据，因 为缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大的压力， 甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其value值为null），并设 定一个较短的失效时间

消息队列与异步架构

同步调用VS异步调用

同步调用：客户端阻塞等待返回，耗时久

异步调用：异步调用不阻塞应用线程

消息队列

点对点模型

发布订阅模型

消息队列的优点

• 实现异步处理，提升处理性能

• 更好的伸缩性

• 削峰填谷

• 失败隔离和自我修复

• 应用解耦

事件驱动架构

注册服务发布一个事件，不用业务应用都订阅次事件，实现业务解耦

负载均衡架构

负载均衡服务器对用户的请求进行分发，均衡的分到给集群中的每一个服务



http重定向负载均衡

缺点：

• 客户端需请求两次

• 存在安全隐患

DNS负载均衡

大型互联网第一层负责均衡，DNS返回的ip地址一般是第二层负载均衡服务器的地址



反向代理负载均衡

缺点：需要组装好整个请求报文才能转发，性能不高，服务器集群不大时可以考虑

IP负载均衡

直接替换每一个数据包的地址，并不关心是否组装好整个请求在转发

缺点：返回数据仍然要进过负载均衡服务器进行转发

数据链路层负载均衡

修改请求的目标mac地址，并不修改ip地址，返回数据直接根据ip地址返回，不用进过负载均衡服务器

常用负载均衡算法

• 轮询：所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场 景。

• 加权轮询：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请 求分发到每个服务器，高性能的服务器分配更多请求。

• 随机：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用， 因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用 加权随机算法。

• 少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到 少连接的服务器上，应该说，这是符合负载均衡定义的算法。

• 源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，该算法可以保 证同一个来源的请求总在同一个服务器上处理，实现会话粘滞

应用服务器session管理

session复制

缺点：每个应用服务器都要保存一份完整的session，浪费资源，复制耗时

session绑定

缺点：某一台应用服务器挂掉session则会丢失

利用cookies记录session

缺点：cookies有大小限制，并且增加传输成本

session服务器

交由session服务器集群统一管理session