架构师训练营第五周 - 总结

发布于: 2020 年 07 月 08 日
架构师训练营第五周-总结

本周主要讲了缓存、异步架构与负载均衡

缓存

缓存是存储在计算机上的一个原始数据复制集,以便于访问。

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

缓存关键指标是缓存命中率,十次请求中,命中九次,命中率为90%。

缓存的实现都是通过哈希表的方式。存储key-value对。读取时,通过key获取value。

命中率受三个因素的影响:

  • key集合的大小

key集合的大小是指key的不同值个数。若key为IP地址,则所有的key大约为40多亿个,key是有一个取值范围的。若key的值是URL这种,则其取值范围是无限的。

  • 可使用内存空间大小

缓存为了追求速度,数据都是放在内存中。内存越大,可存储的缓存值越多,命中率会越高。

  • 缓存对象生存期

对象的生存期,是指对象的存活时间。对象能存活越久,则命中率越高。但一般动态数据不会存储太长时间。且设置缓存对象时,一定要设置过期时间,防止缓存数据越积越多。

缓存的类型有通读缓存旁路缓存

通读缓存就是客户端只访问缓存,缓存没有数据,缓存会去数据源获取数据。例如CDN,反向代理。

旁路缓存,客户端先访问旁路缓存,没有命中,客户端会去数据源获取数据,并把数据存一份到缓存中。例如redis缓存。

分布式缓存的情况下,需要确定访问的路由。

路由算法常用有:

  • 余数hash

  • 一致性hash

  • 虚拟节点一致性hash

常用的redis集群缓存使用的就是余数hash。

缓存是系统性能优化的大杀器:

  • 技术简单

  • 性能提升显著

  • 应用场景多

缓存有很多好处,但使用不当,会成为系统的累赘。

需要合理使用缓存:

  1. 频繁修改的数据,一般读写比要在2:1以上。

  2. 没有热点的数据。数据不是热点,还没有等到下次访问,就被挤出缓存空间。

  3. 数据不一致与脏读。缓存数据TTL之后才回去数据源重新获取数据,需要忍受一定的数据延迟。

  4. 缓存雪崩。缓存崩溃,数据访问压力打到数据库,会导致数据库宕机。

  5. 缓存预热。在缓存启动的时候,把热点数据缓存起来。

  6. 缓存穿透。不恰当的业务或者恶意攻击访问不存在的数据,每次都会穿过缓存,去访问数据源,最好把不存在的数据也缓存起来,给定一个较短的过期时间。

消息队列-异步架构

异步调用不阻塞线程,客户端获得较快的响应。多个请求之间可以使用回调连接起来。

异步架构就是在原来同步架构的调用链路上新加了一层,消息队列可以很好的实现这一层的功能。

消息队列构建异步架构三要素:

  1. 消息生产者

  2. 消息队列

  3. 消息消费者

消息生产-消费模型:

  • 点对点

多个生产者生产相同类型的消息,多个消费者消费相同类型的消息,每个消息只会被消费一次。

  • 发布-订阅

生产者发布消息到主题,消费者可以有多个,每个消费者都消费全量的消息,互不影响。

消息队列的好处:

  1. 实现异步处理,提升处理性能

  2. 更好的伸缩性

  3. 削峰填谷

  4. 失败隔离和自我修复

  5. 解耦

使用消息队列实现支付、下单等业务,业务上加一个支付中、下单中等状态,用于异步操作失败情况下,通知用户。

常用的消息队列产品:

  1. RabbitMQ,性能好,社区活跃,Erlang开发

  2. ActiveMQ,影响比较广泛,跨平台,java开发

  3. RocketMQ,阿里出品,java开发,性能比较好,可靠性也比较高

  4. Kafka,领英出品,scale开发,针对分布式场景做了专门优化,分布式的伸缩性较好。

负载均衡

负载均衡架构是为了处理集群情况下,请求路由以及请求响应实现方式的一种架构。

负载均衡架构实现方式有:

  • HTTP重定向负载均衡

这种负载均衡实现简单,性能较差,基本不再使用。

  • DNS负载均衡

使用DNS在原有的域名解析环节,返回不同的IP,实现访问不同的应用服务,实现简单,性能无损耗。缺点是灵活性不足。

  • 反向代理负载均衡

HTTP应用层负载均衡,适用于小型集群,几十台服务器以内。

  • IP负载均衡

四层传输层负载均衡,适用中型集群,瓶颈点是负载均衡器网卡带宽。

  • 数据链路层负载均衡

性能最好的负载均衡,适用于中大型集群,超大型集群,上万台这种,也会配合DNS进行两层负载均衡。

负载均衡算法:

  1. 轮询

一次访问每个应用服务器,适用于服务器硬件都相同的场景。

  1. 加权轮询

根据服务器硬件性能,在轮询的基础上,加上权重分发请求。

  1. 随机

请求被随机分配到应用服务器,在许多场合下,方案简单实用,因为好的随机数本身就很实用。

  1. 加权随机

在随机的基础上,根据服务器硬件性能添加权重

  1. 最少连接

将服务器连接数记录下来,下次请求分发到连接数最小的服务器上,最符合负载均衡定义,但是实现起来相对复杂,需要记录应用服务器连接数据

  1. 源地址散列

根据IP地址散列,能保证同一个IP的请求,分发到同一台服务器,实现回话粘滞。

应用服务器集群的Session管理手段:

  1. Session复制

多个服务器之间同步Session信息。这种方法每台机器上全量会话,占用内存空间大,Session频繁同步消耗网络资源

  1. Session绑定

Session根据请求IP绑定到应用服务器,但是对于发布频繁的系统来说,不适用。应用已发布,之前的会话会被清除。

  1. 利用Cookie记录Session

Cookie中记录信息,请求响应中会带上Cookie信息,会导致请求响应数据量大。但是实际应用中,使用的比较多,简单易用实用。

  1. Session服务器

使用单独的服务器存储Session信息,当前使用的也比较多。如用redis存储会话信息。

以上,就是本周的内容讲解情况。

总得来说,缓存实现读的高性能;消息队列实现写的高可用;集群提升系统功能处理的能力,包括计算能力和存储能力。

项目架构中,缓存、异步、集群已经是常用的架构模式,本周课让我们了解了这些架构的来龙去脉,理解了这些架构模式背后的原理。在之后的工作中,可以更灵活的融入项目架构中。

用户头像

草原上的奔跑

关注

还未添加个人签名 2018.05.04 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第五周-总结