架构师训练营 -week05- 总结

本周重点学习了一个缓存、消息队列和负载均衡三个知识面。

• 缓存主要学习方向：分布式缓存的原理、常见的实现方式、还有一致性Hash的使用场景。

• 消息队列：消息队列主要解决的问题（解耦和削峰填谷），以及消息队列的选型建议。

• 负载均衡：为了实现高可用，需要以冗余为代价。负载均衡一方面可以分摊流量，减轻访问压力，一方面实现高可用。讲述了大中型网站所采用的不同的负载均衡策略，以及各种策略的优缺点。

1. 缓存：

缓存无处不在，从CPU到中间件的设计，再到我们的业务应用代码，都需要依靠缓存来进行优化。

而且缓存从前端到后端，越早进行缓存，能优化的效率就越高，如下图所示：



本地对象缓存：

• 对象直接缓存在应用服务器中，缓存服务器和应用服务器部署在一起。 

• 缺点：需要更新同步到其他应用服务器，资源浪费，性能消耗大；

• 本地对象缓存对象之间缓存在应用程序内存中。（HashMap）对象存储在共享内存中，同一个机器的多个进程可以访问它。缓存服务器作为独立应用和应用程序部署在同一机器上（localhost socket通信）。

远程分布式对象缓存：

• Memcached 使用一致性hash算法，缓存服务器并不知道有其他缓存服务器存在；

• Redis 支持复杂数据结构，缓存服务器知道在一个集群中，连接集群中任何一个可用节点都可以获取，节点互联。

• 在对于分布式的支持上，memcached没有redis做的好，生产上也是推荐使用redis，集群或者哨兵模式。

• redis目前的架构：单机, 分片, 集群, 集群分片组合

• 集群是分布式概念中的子集，特指提供相同功能或相同角色的机器所构建的子系统。

一致性hash

• 构建一致性hash环，范围0到2^32-1，把机器经过hash算法后等到的hash值放到hash环上，

• 根据一个key查找对应的机器时，就是把key经过hash算法后得到的hash值顺时针查找到对应的机器上，那台机器就是key要访问的机器。

• 增加或减少机器，只影响附近一小段的数据。

• 但是以上的方案存在负载不均衡的问题比如：node2和node3挨得比较近，那么node3的负载就明显比较低；再比如，加机器的时候，只影响了附近的结点，其他机器的负载不受影响，可能违背了加机器分担负载的目标以及机器节点hash值冲突导致节点覆盖的问题。

• 于是就引入了虚拟节点的概念。虚拟节点的个数经验值是150~200之间。

2. 消息队列

消息队列的优势在于：实现异步处理，提升处理性能；更好的伸缩性；削峰填谷；失败隔离和自我修复；解耦；

主流产品有：RabbitMQ、RocketMQ、Kafka；

还有比较老的ActiveMQ，IBM的MQ等。



下面是老师给出的一个选型策略：

主要 MQ 产品比较：

RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟悉 Erlang 的同学而言不便于二次开发和维护。

• ActiveMQ 影响比较广泛，可以跨平台，使用Java开发，对Java比较友好。

• RocketMQ 是阿里推出的一个开源产品，也是使用Java开发，性能比较好，可靠性也

比较高。

• Kafka ，LinkedIn 出品的，Scala 开发，专门针对分布式场景进行了优化，因此分布

式的伸缩性会比较好。



另外，极客时间上另外一门课程的老师也给出了自己的选型建议，可以一起参考：

如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。

如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。

3. 负载均衡：

主要分为HTTP重定向负载均衡、DNS负载均衡、反向代理负载均衡、IP负载均衡、数据链路层负载均衡。

由于系统体量还不够大，这部分的知识用于实战的不多，工作最常用的就是F5和Nginx了。

为什么说硬件的F5性能要比Nginx高很多，因为nginx是基于网络协议的7层负载，F5是属于4层负载。

网络七层协议：7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层