《后端技术面试 38 讲》学习笔记 Day 08
23 | 异步架构：如何避免互相依赖的系统间耦合？
原文摘抄
主要手段就是使用消息队列的异步架构，有时候也被称为事件驱动架构。
消息队列异步架构的主要角色包括消息生产者、消息队列和消息消费者。
根据消息消费方式又分为点对点模式和发布订阅模式两种。
在点对点模式中，多个消息生产者向消息队列发送消息，多个消息消费者消费消息，每个消息只会被一个消息消费者消费。
在发布订阅模式中，开发者可以在消息队列中设置主题，消息生产者的消息按照主题进行发送，多个消息消费者可以订阅同一个主题，每个消费者都可以收到这个主题的消息拷贝，然后按照自己的业务逻辑分别进行处理计算。
好处：改善写操作请求的响应时间、更容易进行伸缩、削峰填谷、隔离失败、降低耦合
心得体会
- 异步发送后，生产者直接返回了，提高效率。
- 对于失败重试的情况，似乎是消费者更需要关心的一件事，对于生产者默认就是发送成功，一定能被成功消费，只是时间问题，当然遇到极端情况，多次重试还是失败的。不知道这样的理解对吗？
工作体验
- 工作中早年接触过IBM MQ、RocketMQ、ActiveMQ，作为一个初级开发者来看的确没有什么大差别，唯一就是IBM MQ部署，创建队列都很麻烦，甚至不能代码创建。
- MQ是有多种协议的，也会影响性能。kafka这样的，作为日志发送的场景似乎都是很好的选型，至少多家都是这样的。
24 | 负载均衡架构：如何用10行代码实现一个负载均衡服务？
原文摘抄
HTTP 重定向负载均衡在实践中很少使用。
大型网互联网应用需要两次负载均衡，一次通过 DNS 负载均衡，用户请求访问数据中心负载均衡服务器集群的某台机器，然后这台负载均衡服务器再进行一次负载均衡，将用户请求分发到应用服务器集群的某台服务器上。
反向代理服务器是工作在 HTTP 协议层之上的，所以它代理的也是 HTTP 的请求和响应。作为互联网应用层的一个协议，HTTP 协议相对说来比较重，效率比较低，所以反向代理负载均衡通常用在小规模的互联网系统上，只有几台或者十几台服务器的规模。
IP 负载均衡不需要在 HTTP 协议层工作，可以在操作系统内核直接修改 IP 数据包的地址，因此，效率比应用层的反向代理负载均衡高得多。但是它依然有一个缺陷，不管是请求还是响应的数据包，都要通过负载均衡服务器进行 IP 地址转换，才能够正确地把请求数据分发到应用服务器，或者正确地将响应数据包发送到用户端程序。请求的数据通常比较小,因此负载均衡服务器会成为响应数据的流量瓶颈。
数据链路层负载均衡可以解决响应数据量大而导致的负载均衡服务器输出带宽不足的问题。也就是说，负载均衡服务器并不修改数据包的 IP 地址，而是修改数据链路层里的网卡 mac 地址，在数据链路层实现负载均衡。因为 IP 地址没有修改过，所以这个响应会直接到达用户的浏览器，而不会再经过负载均衡服务器。
Linux 上实现 IP 负载均衡和链路层负载均衡的技术是 LVS，目前 LVS 的功能已经集成到 Linux 中了，通过 Linux 可以直接配置实现这两种负载均衡。
评论区摘抄：
专栏好像没有提到硬件负载均衡 F5 或者 A10，虽然贵，但是性能强大，支持百万以上并发，并且还具备防火墙、防 DDoS 攻击等安全功能。 实现了 IP 负载均衡和链路层负载均衡的 LVS 是 4 层负载均衡，与协议无关，性能是十万级，传说可达 80 万/秒； 应用层负载均衡，Nginx 是 7 层负载均衡，可以支持 HTTP、E-mail 协议，性能大概是 5 万/秒。 大概一般的互联网平台，如果用户的地理分布比较广泛，那么先上 DNS 的地理级别负载均衡（域名商提供，一般免费）； 如果流量正的很大，或者土豪，那么就在当地机房上集群级别的硬件负载均衡 F5，在我的印象里面，似乎维基百科也没有使用硬件负载均衡； 进入当地机房以后，可以再使用机器级别的负载均衡 Nginx 将用户请求发送给及群众的某台机器。 也可以采用级联的方式，一级用 F5，二级用 LVS，三级用 Nginx。我觉的一般人用不到这个方案。 参考《从零开始学架构》中有关高性能负载均衡的章节。
硬件负载均衡：支持百万以上
软件负载均衡：
2.1 HTTP重定向：访问HTTP重定向负载均衡服务器获得新的地址后访问
2.2 DNS负载均衡：访问DNS或者地址后访问
2.3 反向代理：反向代理有资源则返回，无资源则请求下游服务器。nginx，通过将请求分发来实现。性能是5 万级别
2.4 LVS：性能是十万级
2.2.1 IP层：请求到达负载均衡后，负载均衡服务器在操作系统内核修改IP地址
2.2.2 数据链路层负载均衡：解决响应数据量大而导致的负载均衡服务器输出带宽不足的问题。负载均衡服务器修改mac地址，而服务器和下游应用服务器共享相同的虚拟IP，所以应用服务器处理完之后不用再把response返回负载均衡服务器去修改IP以返回给客户端，而是直接返回给客户端。
心得体会
- 越底层的（七层协议）协议进行负载均衡，性能更高，更不容易瓶颈。
工作体验
- 首先都是很多层网关进来了，这些网关有负载均衡功能的，软硬件的实现都有。最后配置F5负载均衡，Ngnix负载均衡的都有。可能还是公司并发量并不高吧。