第五周总结

用户头像
Geek_ac4080
关注
发布于: 2020 年 10 月 25 日

分布式缓存架构

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

缓存应用场景

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



用户头像

Geek_ac4080

关注

还未添加个人签名 2019.05.09 加入

还未添加个人简介

评论

发布
暂无评论
第五周总结