面试篇！！！！！

一.nginx

1 介绍nginx

nginx是一款轻量级、高性能、稳定性高、并发性好的一个web服务器，一个http和反向代理服务器，一个邮件代理服务器，一个通用的 TCP/UDP 代理服务器，同时也是一款负载均衡软件，可以做七层，四层负载均衡，可以做动静分离，解析静态页面效率非常高，功能非常强大，常用的比如地址重写，防盗链，会话保持，访问控制流量控制等

下面是对 Nginx 功能特性的详细解释：
轻量级与高性能
轻量级：Nginx 的架构设计非常简洁，占用资源少，这使得它在低配置的硬件上也能高效运行。
高性能：通过使用事件驱动、异步非阻塞 I/O 模型，Nginx 可以处理大量的并发连接，具有很高的吞吐量和响应速度。

事件驱动的设计让Nginx成为了一个轻量级且高性能的Web服务器/反向代理服务器
稳定性高
稳定性：Nginx 的稳定性和可靠性经过了广泛的测试和实际应用验证。它能够在长时间运行中保持稳定，适合生产环境中的关键任务。
并发性好
并发处理：Nginx 使用少量的工作进程（通常是每个 CPU 核心一个工作进程）来处理请求，这些进程共享一组监听套接字，并且能够高效地处理大量并发连接。
Web 服务器
静态内容服务：Nginx 在提供静态内容（如 HTML 文件、图片等）方面表现出色，因为它可以直接读取文件系统并快速响应客户端请求。
动态内容支持：通过 FastCGI 或者其他协议（如 uWSGI），Nginx 可以将动态内容请求转发给后端的应用服务器（如 PHP-FPM, Node.js, Python 应用等）。
HTTP 和反向代理服务器
HTTP 服务器：Nginx 可以作为一个标准的 HTTP 服务器，直接处理客户端的 HTTP 请求。
反向代理：Nginx 可以作为反向代理，将客户端的请求转发到后端的一组服务器，并将响应返回给客户端。这种方式可以隐藏真实的后端服务器，增加安全性，并实现负载均衡。
邮件代理服务器
邮件代理：虽然这个功能不如 Web 服务那样常用，但 Nginx 也支持作为 IMAP/POP3 代理服务器，用于邮件服务。
通用 TCP/UDP 代理服务器
TCP/UDP 代理：从 Nginx 1.9.0 开始，引入了 stream 模块，允许 Nginx 作为任意 TCP 或 UDP 流量的代理服务器，适用于各种网络服务，如数据库连接、SMTP 服务等。
负载均衡
七层负载均衡：Nginx 支持基于 HTTP 协议（第七层）的负载均衡，可以根据 URL、Cookie 等信息进行智能路由。
四层负载均衡：通过 stream 模块，Nginx 还可以实现基于传输层（第四层）的负载均衡，如 TCP 和 UDP 流量。
动静分离
动静分离：Nginx 可以配置为只处理静态内容请求，而将动态内容请求转发给后端的应用服务器，这样可以提高效率并减轻应用服务器的压力。
其他高级功能
地址重写：Nginx 提供了强大的 URL 重写功能，可以用来优化 SEO 或者改进网站结构。
防盗链：通过检查 HTTP Referer 头部，Nginx 可以阻止非法站点链接到你的资源，从而节省带宽并保护内容
会话保持：对于需要保持会话一致性的应用，Nginx 可以通过 IP 哈希或其他机制确保来自同一客户端的请求总是被发送到相同的后端服务器。

访问控制：Nginx 提供了多种方法来控制对资源的访问，包括基于 IP 的白名单/黑名单、基本认证等
流量控制：Nginx 可以设置带宽限制，防止恶意用户或爬虫过度消耗服务器资源。
总之，Nginx 是一个高度可配置、灵活且功能丰富的服务器软件，广泛应用于现代 Web 架构中，无论是小型网站还是大型互联网平台，都能找到 Nginx 的应用场景。

TCP（传输控制协议）和 UDP（用户数据报协议）是互联网协议套件中的两个核心传输层协议。它们负责在应用程序之间传输数据，并且各自具有不同的特性和用途。
TCP 适用于需要可靠传输的应用，如 Web 浏览、电子邮件和文件传输。
UDP 适用于对速度和实时性要求高但可以接受一定数据丢失的应用，如实时音视频、在线游戏和 DNS 查询

动静分离是一种架构模式，通过将静态和动态内容分开处理来提高整体性能和可扩展性。

解析静态页面效率非常高是指 Nginx 在处理静态文件请求时表现出色，能够高效地提供静态内容

2 负载均衡组件工作流程

服务注册：
三台 Web 服务器 A, B, C 启动时，将自己的 IP 地址和端口告诉服务注册中心

服务发现：
Nginx 从服务注册中心获取这三台服务器的信息。

负载均衡策略选择：
Nginx 使用轮询策略，依次选择 A, B, C 来处理请求。

请求转发：
客户端请求到达 Nginx，Nginx 根据轮询策略选择一台服务器（比如 A）并将请求转发给 A。

处理请求：
服务器 A 处理请求并生成响应。

返回响应：
服务器 A 将响应返回给 Nginx，Nginx 再将响应返回给客户端。

健康检查：
Nginx 定期检查 A, B, C 的健康状态。如果 A 出现故障，Nginx 会将其从可用列表中移除，并继续使用 B 和 C 处理请求。

3.什么是负载均衡

为了保证服务的高可用，服务单元往往都是集群化(相同服务部署多份)部署的，

当服务消费者消费服务时，负载均衡组件(F5（硬负载）,nginx,ribbon,dubbo（软负
载）)获取服务提供者所有实例的注册信息，并通过一定的负载均衡策略（可以自己配
置）选择一个服务提供者实例，向该实例进行服务消费，这样就实现了负载均衡

负载均衡是一种技术，用于在多个服务器或网络资源之间分配工作负载，以优化资源使用、最大化吞吐量、减少响应时间，并确保没有单一服务器过载。负载均衡器可以是硬件设备（如 F5 BIG-IP）或软件解决方案（如 Nginx、HAProxy、Ribbon 和 Dubbo 等）。

二.redis

1 .去中心化集群模式（Redis Cluster）的工作原理

1. 节点角色

主节点（Master）：负责处理客户端的读写请求，并将数据存储在内存中。

从节点（Slave）：作为主节点的备份，定期从主节点同步数据。如果主节点发生故障，从节点可以被提升为新的主节点。

2. 哈希槽（Hash Slots）

总数：Redis Cluster 使用 16384 个哈希槽（编号从 0 到 16383）。

分配：每个键（key）会被映射到其中一个哈希槽中。映射规则是 slot = CRC16(key) % 16384。

分布：这些哈希槽被均匀地分配给各个主节点。每个主节点负责一部分哈希槽。

3. 数据分片

分片机制：每个主节点负责一部分哈希槽，从而实现了数据的分片存储。

示例：
- 主节点 A 负责哈希槽 0-5460
- 主节点 B 负责哈希槽 5461-10921
- 主节点 C 负责哈希槽 10922-16383

4. 客户端请求处理

连接：客户端可以连接到任意一个节点。

重定向：如果客户端发送的请求对应的键不在当前节点负责的哈希槽范围内，该节点会返回一个重定向响应，告诉客户端应该连接到哪个节点。

直接访问：客户端可以根据重定向信息直接连接到正确的节点，进行读写操作。

5. 故障检测与恢复

心跳检测：节点之间定期交换心跳信息，检测其他节点的状态。

故障检测：如果某个主节点在一定时间内没有响应心跳，其他节点会认为该主节点已经失败。

故障转移：
- 集群会选择该主节点的一个从节点并将其提升为新的主节点。
- 更新集群配置，通知所有客户端新的主节点位置。
- 其他从节点会重新配置，指向新的主节点。

6. 数据同步

主从同步：主节点定期将数据同步到从节点，确保数据的一致性和冗余。

增量同步：使用 RDB 文件和 AOF 日志来实现全量和增量的数据同步。

工作流程示例

初始化集群：
- 启动多个 Redis 实例（节点），并配置它们为集群模式。
- 使用 redis-cli 工具初始化集群，并分配哈希槽。
```
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 ... 127.0.0.1:7011 127.0.0.1:7012 --cluster-replicas 1
```
客户端连接：
- 客户端连接到任意一个节点。
- 节点返回集群配置信息，包括所有节点及其负责的哈希槽。
请求处理：
- 客户端根据键计算哈希槽，并确定负责该槽的主节点。
- 如果请求的键不在当前节点负责的哈希槽范围内，节点会返回重定向响应。
- 客户端根据重定向信息连接到正确的节点，进行读写操作。
故障检测与恢复：
- 节点之间定期交换心跳信息，检测其他节点的状态。
- 如果发现某个主节点不可用，集群会选择一个从节点提升为主节点。
- 更新集群配置，通知所有客户端新的主节点位置。
数据同步：
- 主节点定期将数据同步到从节点。
- 从节点保持与主节点的数据一致，提供数据冗余。

总结

Redis Cluster 通过以下关键特性实现了一个去中心化的分布式存储系统：

数据分片：使用哈希槽将数据均匀分配到多个节点上。
高可用性：通过主从复制和自动故障转移确保系统的连续运行。
负载均衡：客户端可以直接与任何节点通信，节点之间会自动转发请求到正确的节点。
无中心结构：没有单一的控制节点，每个节点都是对等的。

这种架构使得 Redis Cluster 具有高可用性、可扩展性和容错能力，适用于大规模分布式应用。

深度搜索

三. rabbitmq

1消息队列

消息队列（Message Queue, MQ）是一种跨进程的通信机制，用于存储和转发消息。它在分布式系统中扮演着重要的角色，提供了许多关键的功能和优势。以下是消息队列的基本概念、工作原理和主要用途：

基本概念

消息：消息是系统间传递的信息单元，通常包含数据和元数据（如时间戳、消息类型等）。
生产者：生成并发送消息的应用程序或服务。
消费者：接收并处理消息的应用程序或服务。
队列：存储消息的中间件，可以暂时保存消息，直到被消费者处理。
消息代理（Message Broker）：管理和协调消息传递的中间件服务器，负责将消息从生产者路由到消费者。

工作原理

生产者发送消息：
- 生产者应用程序生成一条消息，并将其发送到消息队列。
- 消息可以包含各种类型的数据，例如文本、JSON、二进制数据等。
消息存储：
- 消息队列接收到消息后，将其存储在队列中。
- 队列可以持久化存储消息，以确保即使在系统故障后消息也不会丢失。
消费者接收消息：
- 消费者应用程序从队列中获取消息进行处理。
- 消费者可以配置为自动确认消息已处理，或者手动确认，以确保消息不会被重复处理。
消息删除：
- 一旦消息被成功处理并确认，消息队列会将其从队列中删除。
- 如果消费者没有确认消息，消息可能会重新排队，等待其他消费者处理。

主要用途

解耦系统组件：
- 消息队列允许不同的系统组件异步通信，从而降低耦合度。
- 生产者和消费者不需要直接交互，只需通过消息队列进行通信。
提高系统的可扩展性和灵活性：
- 可以通过增加更多的消费者实例来水平扩展系统的处理能力。
- 动态调整消费者数量以应对不同的负载需求。
缓冲和流量控制：
- 消息队列可以作为缓冲区，吸收突发的高流量，防止下游服务过载。
- 通过设置队列的最大长度或其他策略，可以限制进入系统的请求数量。
可靠的消息传递：
- 消息队列支持消息的持久化存储，确保消息在系统故障后不会丢失。
- 消费者可以确认消息已被成功处理，避免消息丢失或重复处理。
异步任务处理：
- 对于耗时较长的任务，可以将其放入消息队列，由后台任务处理器异步处理。
- 这样可以避免阻塞前端响应，提高用户体验。
日志和监控：
- 系统中的各个组件可以将日志信息发送到消息队列，然后由专门的日志处理系统进行收集和分析。
- 消息队列可以用于收集系统状态信息，通过监控工具进行实时监控和报警。
数据集成和同步：
- 消息队列可以作为数据管道，将不同系统之间的数据进行集成和同步。
- 通过消息队列实现事件驱动架构，当某个事件发生时，触发相应的处理流程。
事务支持：
- 某些消息队列支持事务处理，确保一组操作要么全部成功，要么全部失败。
- 这对于需要保证数据一致性的场景非常有用。

常见的消息队列系统

RabbitMQ：基于 AMQP 协议，支持多种消息模式和灵活的路由机制。
Apache Kafka：高性能的分布式消息队列，适用于大规模数据流处理。
ActiveMQ：基于 JMS 规范，支持多种协议和消息模式。
Amazon SQS (Simple Queue Service)：AWS 提供的托管消息队列服务，易于使用和扩展。
Azure Service Bus：Microsoft Azure 提供的托管消息队列服务，支持多种消息模式。
NATS：轻量级、高性能的消息队列系统，适合微服务架构。
ZeroMQ：一个轻量级的消息库，适用于构建自定义消息队列系统。

总结

消息队列是一种强大的工具，用于在分布式系统中实现异步通信、解耦系统组件、提高系统的可扩展性和可靠性。通过使用消息队列，开发者可以构建更加健壮、灵活和高效的系统。

2.RabbitMQ普通模式和镜像模式的区别

RabbitMQ 的普通模式（也称为非镜像模式）和镜像模式（Mirrored Queues）是两种不同的队列配置方式，它们在高可用性和数据冗余方面有显著的区别。下面我将详细解释这两种模式的区别：

普通模式（Non-Mirrored Queues）

特点

单节点存储：在普通模式下，队列中的消息只存储在一个节点上。这意味着如果该节点发生故障，队列中的所有消息可能会丢失。
性能较高：由于消息只存储在一个节点上，写入和读取操作的性能通常较高。
简单配置：配置相对简单，不需要额外的集群设置。

适用场景

对高可用性要求不高：如果系统可以容忍一定程度的数据丢失，并且对性能有较高要求，可以选择普通模式。
开发和测试环境：在开发和测试环境中，普通模式可以简化配置和管理。

镜像模式（Mirrored Queues）

特点

多节点复制：在镜像模式下，队列中的消息会在多个节点上进行复制。主节点负责处理客户端的读写请求，从节点则定期从主节点同步数据。
高可用性：即使某个节点发生故障，其他节点仍然可以继续提供服务，从而提高了系统的高可用性。
数据冗余：通过在多个节点上复制消息，提供了数据冗余，减少了数据丢失的风险。
性能略低：由于需要在多个节点之间进行数据同步，写入和读取操作的性能可能会略低于普通模式。
复杂配置：配置相对复杂，需要设置集群和镜像策略。

适用场景

对高可用性要求高：如果系统不能容忍数据丢失，并且需要高可用性，可以选择镜像模式。
生产环境：在生产环境中，为了确保系统的稳定性和数据的安全性，通常会选择镜像模式

四。RabbitMQ和kafka的区别

1. 设计目标和用途

Kafka:
- 设计目标: Kafka 是一个分布式流处理平台，最初由 LinkedIn 开发，后来成为 Apache 的顶级项目。
- 用途: 主要用于高吞吐量的日志收集、消息传递和流处理。它适用于需要处理大量数据的场景，如日志聚合、实时分析、事件驱动架构等。
- 特点: 高吞吐量、低延迟、持久化存储、水平扩展性。
RabbitMQ:
- 设计目标: RabbitMQ 是一个实现 AMQP（Advanced Message Queuing Protocol）标准的消息代理。
- 用途: 适用于需要可靠消息传递、复杂路由和多种消息模式的企业级应用。它支持点对点通信、发布/订阅模式等多种消息传递模式。
- 特点: 可靠性、灵活性、丰富的消息路由功能、支持事务和消息确认机制。

2. 消息传递模型

Kafka:
- 基于 Pull 模式: 消费者主动从 Kafka 中拉取消息，而不是 Kafka 推送消息给消费者。这种方式可以更好地控制消费速率和提高吞吐量。
- 分区（Partition）: 每个主题（Topic）可以被分成多个分区，每个分区是一个有序且不可变的消息序列。消费者可以并行消费不同分区的消息。
- 偏移量（Offset）: 每条消息在分区中的位置由偏移量表示。消费者可以记录自己的消费进度，从而实现断点续传。
RabbitMQ:
- 基于 Push 模式: 生产者将消息发送到队列，消费者通过订阅队列来接收消息。RabbitMQ 会将消息推送给消费者。
- 队列（Queue）: 消息存储在队列中，消费者从队列中获取消息。队列可以配置为持久化或非持久化。
- 交换机（Exchange）: 通过交换机进行消息的路由，支持多种路由模式（Direct, Fanout, Topic, Headers）。

3. 性能和吞吐量

Kafka:
- 高吞吐量: Kafka 设计为能够处理大规模数据流，每秒可以处理数百万条消息。
- 低延迟: 由于其高效的存储和传输机制，Kafka 能够提供非常低的端到端延迟。
- 持久化存储: 消息默认会被持久化到磁盘，并且可以通过配置保留策略来管理数据生命周期。
RabbitMQ:
- 可靠性优先: RabbitMQ 更注重消息的可靠性和一致性，支持消息确认机制和事务。
- 吞吐量适中: 相比 Kafka，RabbitMQ 的吞吐量较低，但在大多数企业应用场景中已经足够。
- 灵活的配置: 支持多种持久化选项，可以根据需求调整消息的存储方式。

4. 消息顺序和重复

Kafka:
- 严格顺序: 在同一个分区内的消息是严格有序的，但跨分区的消息顺序不能保证。
- 不支持事务: Kafka 不支持事务，可能会出现少量的消息丢失或重复。但对于许多大数据处理场景，这通常是可以接受的。
RabbitMQ:
- 消息顺序: 通过合理的配置和使用，RabbitMQ 可以保证消息的顺序。
- 支持事务: RabbitMQ 支持事务，确保消息的一致性和可靠性。可以通过事务和消息确认机制来防止消息丢失和重复。

5. 扩展性和集群

Kafka:
- 水平扩展性: Kafka 通过增加更多的节点和分区来实现水平扩展。每个分区可以分布在不同的节点上，从而实现负载均衡。
- 集群管理: Kafka 提供了强大的集群管理和监控工具，易于管理和扩展。
RabbitMQ:
- 水平扩展性: RabbitMQ 也可以通过增加更多的节点来实现水平扩展，但其扩展性相对 Kafka 较弱。
- 集群管理: RabbitMQ 提供了集群模式，支持主从复制和镜像队列，但配置和管理相对复杂。

6. 适用场景

Kafka:
- 日志收集和传输: 适用于大规模的日志收集和传输，如 ELK 堆栈中的 Logstash。
- 实时数据分析: 适用于实时数据分析和流处理，如 Apache Storm、Apache Flink。
- 事件驱动架构: 适用于事件驱动架构，如用户行为跟踪、实时监控。
RabbitMQ:
- 企业级应用: 适用于需要高度可靠性和复杂消息路由的企业级应用，如订单处理、支付系统。
- 微服务架构: 适用于微服务架构中的服务间通信，提供可靠的异步通信机制。
- 任务队列: 适用于需要处理大量后台任务的场景，如图像处理、视频转码。