常用中间件合集

简介

在游戏或者web服务器开发过程中 难免会使用一些中间件 正所谓有现成的 就没必要重复造轮子了

以下大概介绍下常用的中间件nginx etcd nats docker k8s

nginx

简介

Nginx是一个 轻量级/高性能的反向代理Web服务器，他实现非常高效的反向代理、负载平衡，他可以处理2-3万并发连接数，官方监测能支持5万并发

事件处理机制：异步非阻塞事件处理机制：运用了epoll模型，提供了一个队列，排队解决

Nginx 的核心特性

1. ​高并发处理

   • 支持高达 ​50,000 个并发连接，通过 ​Master-Worker 进程模型 实现：
     • ​Master 进程：负责管理 Worker 进程，接收信号并监控状态
     • ​Worker 进程：单线程异步非阻塞处理请求，采用 ​epoll（Linux）​ 或 ​kqueue（BSD）​ 多路复用技术，显著提升并发能力
   • 单台物理服务器可支持 ​30,000～50,000 个并发请求，内存占用仅约 2.5MB（10,000 个空闲连接）

2. ​功能扩展性

   • 支持 ​模块化设计，可扩展反向代理、负载均衡、静态资源托管、SSL 加密等功能
   • 提供 ​动静分离、Gzip 压缩、URL 重写等优化策略

3. ​稳定性与易用性

   • 支持 7×24 小时运行，支持热部署和在线升级
   • 配置文件简洁，支持 Perl 语法

---

​Nginx 的并发处理机制

1. ​异步非阻塞模型

   • Worker 进程通过事件驱动（如 epoll）处理请求，避免线程/进程切换开销
   • 示例流程：
     • 客户端请求 → Worker 进程接收 → 异步处理（如反向代理）→ 回调通知结果 → 响应客户端

2. ​负载均衡策略

   • 内置 ​轮询（Round Robin）​、加权轮询、IP 哈希 等算法，支持扩展自定义策略
   • 结合 ​反向代理 隐藏后端服务器 IP，提升安全性

3. ​静态资源优化

   • 直接托管 HTML、CSS、JS 等静态文件，减少后端服务压力
   • 支持缓存控制、Gzip 压缩，提升传输效率

架构

Nginx 的架构通过 ​多进程模型 分离控制与处理逻辑，结合 ​事件驱动和非阻塞 I/O 实现高并发，同时依赖模块化设计提供灵活的功能扩展。这种设计使其能够支持数万并发连接，成为 Web 服务、反向代理和负载均衡的首选

​核心架构：Master-Worker 进程模型

1. ​Master 进程

   • ​职责：
     • 管理 Worker 进程的生命周期（启动、监控、重启）
     • 解析配置文件并验证语法
     • 接收外部信号（如 reload、stop）并分发给 Worker 进程
   • ​特点：单进程，稳定性高，不直接处理请求

2. ​Worker 进程

   • ​职责：
     • 实际处理客户端请求（如 HTTP 请求、反向代理）
     • 通过 ​事件驱动模型 非阻塞地处理多个并发连接
   • ​特点：
     • 数量通常与 CPU 核心数一致，以充分利用多核性能
     • 单线程设计，避免多线程上下文切换开销

可以多个workder监听同个端口

同个worder也可以监听多个端口

配置

upstream backend {
    server server1 weight=3;
    server server2 weight=2;
    server server3;
}

server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://backend;
    }
}

location匹配

正则表达式

最全的常用正则表达式_正则表达式[^0-9]-优快云博客

负载均衡

etcd

简介

TCD是SoreOs公司发布的一个分布式的、高可用的、key-value存储的数据库。基于Go语言实现，k8s中也使用了ETCD作为数据库。主要用于共享配置和服务发现。相对于zookeeper采用的Paxos，ETCD采用的是Raft算法，该算法具备的性能更佳、数据一致性强等优点。

raft

超过半数同意就算成功

选举

每 100msleader会向follower发起心跳包     然后follower就会刷新等待时间

如果follower收不到心跳包就会升级会候选者    自身的版本号就会+1 然后向其他节点发起投票申请 

其他节点收到投票申请后 判断版本号大于等于自己 且index也比自身大 就可以去投票

当一个节点得到一半以上的票数就升级为leader

读操作

读操作默认是线性读 会去请求raft模块的index跟当前节点比 如果index比当前节点大就等待直到同步了数据才返回   如果index和当前节点相同则直接读数据

写操作

写操作只能给leader节点 然后通过raft 得到半数以上的节点回应就可以持久化 并更新index

Nats

简介

NATS 作为一款专注于高性能和轻量级的消息队列系统，其核心设计围绕 ​实时通信 和 ​云原生架构 展开

• ​无持久化存储

  • 默认情况下，NATS 是内存消息队列，消息仅存储在内存中。若服务器崩溃或重启，未消费的消息会丢失
  • ​适用场景：对实时性要求极高、允许短暂消息丢失的场景（如高频交易信号传递）。

• ​消息确认机制

  • NATS 支持订阅者显式确认（ACK）消息，若未收到 ACK，消息会自动重传​（默认 3 次）
  • ​局限性：若订阅者未正确发送 ACK（如程序崩溃），可能导致消息重复消费

发布-订阅（Pub/Sub）​

• ​广播式分发：发布者（Publisher）向指定主题（Subject）发送消息，所有订阅该主题的订阅者（Subscriber）均会收到消息。
• ​通配符支持：支持 *（单级通配符，如 events.*）和 >（多级通配符，如 events.>），实现灵活的主题订阅。
• ​适用场景：实时事件广播（如日志分发、配置更新）

队列组（Queue Groups）​

• ​负载均衡：多个订阅者加入同一队列组，消息仅被组内一个订阅者接收，实现任务分摊。
• ​容错机制：若组内某个订阅者宕机，消息自动重定向至其他成员，确保处理不中断。
• ​典型应用：订单处理、批量任务分发

 ​请求-回复（Request/Reply）​

• ​同步通信模拟：客户端发送请求消息并等待响应，NATS 自动路由至订阅者，回复通过临时主题完成。
• ​超时控制：支持设置请求超时时间，避免因订阅者无响应导致的阻塞。
• ​适用场景：微服务间的 RPC 调用、实时查询