技术选型之缓存、队列、负载均衡

发布于: 2020 年 07 月 07 日

缓存

缓存是介于数据访问者和数据源之间的一种高速存储,当数据需要多次读取的时候,用于加快读取的速度。缓存一般采用哈希表来存储,哈希表本质是一个数组,根据首地址和偏移量(也即key的hashcode对数组长度取模)即可快速读取。而我们在使用缓存的时候,命中率是我们衡量缓存效果好与坏的关键指标,影响命中率的因素有如下几个:

  • 缓存键集合大小:键数量越小,命中率越高

  • 缓存可使用内存空间:物理上能缓存的对象越多,命中率越高

  • 缓存对象的生存时间:缓存对象时间越长,命中率越高

缓存可以分两类:一类是通读缓存,即给客户端返回缓存资源,并在请求未命中缓存时获取实际数据,客户端连接的是通读缓存而不是生成响应的原始服务器,如代理缓存、反向代理缓存、CDN都属于通读缓存。另一类是旁路缓存,旁路缓存通常是一个独立的键值对存储,如浏览器缓存、本地对象缓存、分布式对象缓存。

我们在使用分布式缓存的时候,常常需要考虑伸缩性的问题,比如增加一个节点或者下掉一个节点,怎么来保证较高的命中率。如果我们采用hash取模的方式路由到缓存节点,当增加一个节点的时候(如从3台增加到4台),会有75%的键都会失效,这是不能忍受的。所以提出了一致性hash的解决方案,将节点hash值放到一个一致性hash环中,然后key也算出hash值在同一个一致性hash环中顺时针寻找最近的一个节点,如下图所示

这样的话,当节点从3台扩到4台,只会有25%的键失效,如下图所示

但是一致性hash也会存在一个问题,就是数据倾斜,比如节点1承载了太多数据,而节点2承载的数据比较少,这个时候又提出了虚拟节点的解决方案,就是每一个实际的节点都会映射100甚至200个虚拟节点,虚拟节点也会放在同一个hash环中,这样就能保持数据均衡,解决数据倾斜的问题。如下图所示:

缓存是我们提升系统性能的银弹,但是使用缓存也会带来很多问题:

  • 无热点访问:缓存大量无效key,浪费存储。

  • 数据不一致:因为缓存会有失效时间,会因为缓存更新不及时,所以必然会带来数据的不一致。

  • 缓存雪崩:当缓存服务崩溃的时候,会导致数据库崩溃,进而导致所有服务不可用。

  • 缓存穿透:当某个key不存在时,而客户端又频繁的访问这个key,就会导致所有请求都会回源。

  • 缓存击穿:当某个key失效后,大量请求会访问这个key,会导致数据库压力过大。

消息队列

消息队列是一种进程间通信或同一进程的不同线程间的通信方式。消息队列主要采用先进先出的队列这种数据结构,生产者生产消息往队列里放,消费者从队列里消费消息。

消息队列的两种模式,一种是点对点模型,生产者生产消息放到队列中,只有一个消费者能够消费这条消息。另一种是发布/订阅模型,生产者将消息发布到topic中,订阅了这个topic的消费者都可以消费这条消息。而目前的消息中间件基本上都采用了发布/订阅模型。

消息队列带来的好处:

  • 异步,提升性能。比如写多的应用,可以将请求先写入队列,然后消费者消费后写入存储系统,典型的比如开源产品中Skywalking在接收到打点数据后写入ES之前就采用消息队列来做一层处理。

  • 解耦,比如注册用户后,需要给用户发送激活邮件。当用户数据写入库后,直接发一个消息出去。由邮件系统消费消息后发送邮件给用户。这样即使邮件系统有问题,也不会导致用户注册失败,只不过邮件会晚点发出来,所以系统之间不会强依赖。

  • 限流削峰,比如秒杀抢购的场景,避免流量过大导致系统挂掉

  • 消息驱动架构

常见MQ产品比较

  • RabbitMQ:性能好,社区活跃,但使用Erlang开发,不利于维护。

  • ActiveMQ:遵从JMS协议,跨平台,Java开发。但社区活跃度不高,会丢消息。

  • RocketMQ:阿里开源,性能好,可靠性高,Java开发。

  • Kafka:LinkedIn出品,分布式伸缩性好,Scala开发。不利于过多的队列。

负载均衡

负载均衡是用来在在多个计算机、网络或者其他资源中分配负载,以达到最优资源使用,最大化吞吐量,最小化响应时间,同时避免过载。在互联网架构中主要是用来提高性能和可用性,通过负载均衡将流量分发到多个服务器,同时多服务器能够消除这部分的单点故障。负载均衡有软件(如LVS)和硬件(F5)。

负载均衡的实现方案可以分成两个部分,一个是根据负载均衡算法算出要转发的服务器地址;另一个

如何将请求发送到服务器上。

负载均衡的实现方案:

  • HTTP重定向负载均衡,有一台单独的服务器来计算真实服务器地址,缺点是需要请求两次。

  • DNS负载均衡,在域名服务中配置多个服务器,域名解析的同时进行负载均衡的处理,缺点是真实服务器如果下线,域名服务器不能及时更新,导致访问失败

  • 反向代理负载均衡,直接在反向代理服务器中(如nginx)完成负载均衡的处理,缺点是反向代理服务器容易成为性能瓶颈

  • IP负载均衡,在网络层通过修改请求目标地址进行负载均衡,优点是性能好,缺点是因为响应包都需要经过该负载均衡服务,所以网络带宽会成为性能瓶颈

  • 数据链路层负载均衡,在数据链路层修改mac地址进行负载均衡,响应数据可以直接回到客户端,不需要再经过负载均衡服务,所以性能最好

负载均衡算法

  • 轮询:所有请求被依次分发到每台应用服务器上

  • 加权轮询:按照权重将请求分发到每台应用服务器

  • 随机:随机将请求分发到各个应用服务器

  • 最少连接:将请求分发到连接数最少的应用服务器

  • 原地址散列:根据IP或者URL进行Hash取模后的应用服务器

发布于: 2020 年 07 月 07 日 阅读数: 15
用户头像

olderwei

关注

还未添加个人签名 2018.04.26 加入

还未添加个人简介

评论

发布
暂无评论
技术选型之缓存、队列、负载均衡