分布式架构技术选型总结(一)
1、分布式缓存架构
1.1、缓存的作用
缓存数据通常是存在内存中的,访问速度比磁盘上的快很多
缓存数据一般是结果的最终形态,不需要中间计算,减少CPU资源的消耗
缓存可降低数据库、磁盘、网络、服务器的压力
1.2、常用的缓存方案
CDN缓存
由运营商提供
代理缓存
部署在用户端,不属于系统的部分
反向代理缓存
代理应用服务器,属于系统的一部分,一般使用在缓存静态资源的场景
前端缓存
浏览器对象缓存
应用程序缓存
本地缓存
分布式对象缓存
redis、memcached
2、消息队列与异步架构
2.1、消息队列的好处
实现异步处理,提升处理性能
将耗时的处理逻辑通过消息驱动的方式进行异步处理,降低用户请求的响应时间。
伸缩性
异步处理将用户的请求拆分成了多个步骤,针对不同的步骤需要的资源情况进行针对性的扩容,提升处理能力。
削峰填谷
由于请求都发送到了消息队列中,在高峰期,消息缓冲在消息队列中,应用服务器根据自己的能力处理消息,将消息均分到一段时间内处理。
失败隔离和自我修复
生产者不直接依赖消费者,任何一方异常都不会相互影响。
解耦
生产者和消费者没有直接调用,达到了解耦的目的。
2.2、两种模型
点对点模型
多个消费者消费同一个消息队列,一个消息只会被一个消费者处理一次。
发布评阅模型
每个消息都会被所有消费者处理。
2.2、常用的MQ产品
RabbitMQ 的主要特点是性能好,社区活跃,但是 RabbitMQ 用 Erlang 开发,对不熟悉 Erlang 的同学而言不便于二次开发和维护。(49M)
ActiveMQ 影响比较广泛,可以跨平台,使用Java开发,对Java比较友好。(27M)
RocketMQ 是阿里推出的一个开源产品,也是使用Java开发,性能比较好,可靠性也比较高。(35M)
Kafka ,LinkedIn 出品的,Scala 开发,专门针对分布式场景进行了优化,因此分布式的伸缩性会比较好。(63M)
3、负载均衡架构
3.1、常用的负载均衡方案
HTTP重定向负载均衡
两次HTTP请求影响性能;暴露了应用服务器的IP,安全性差。实际项目中基本不会用到。
DNS负载均衡
系统不需要实现负载均衡,由域名服务商提供,实现简单。
实际使用中一般使用两层负载均衡,DNS负载均衡转发到系统内的负载均衡服务器。一般互联网系统都会使用这种负载均衡架构。
反向代理负载均衡
反向代理服务器需要处理应用层HTTP协议,效率低、性能差,所以只在小规模的应用服务器集群中使用。
IP负载均衡
通过修改数据包的IP地址实现,不需要解析HTTP协议,处理TCP/IP数据包,性能高。但响应数据包非常大时,网络可能成为性能的瓶颈。
数据链路层负载均衡
与IP层的数据不同的是负载均衡服务器只修改MAC地址,不用处理响应请求。负载均衡服务器和应用服务器需要使用同一个虚拟IP。是实际大型系统中使用最多的一种方案。
3.2、负载均衡算法
轮询:所有请求被依次分发到每个应用服务器上,适合于所有服务器硬件都相同的场景。
加权轮询:根据应用服务器硬件性能的情况,在轮询的基础上,按照配置的权重将请求分发到每个服务器,高性能的服务器分配更多请求。
随机:请求被随机分配到各个应用服务器,在许多场合下,这种方案都很简单实用,因为好的随机数本身就很均衡。如果应用服务器硬件配置不同,也可以很容易的使用 加权随机算法。
最少连接:记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到 最少连接的服务器上。应该说,这是最符合负载均衡定义的算法,但实现难度高,价值不高,实践中很少用。
源地址散列:根据请求来源的IP地址进行Hash计算,得到应用服务器,该算法可以保证同一个来源的请求总在同一个服务器上处理,实现会话粘滞。
评论