`mysql-9400c172-proxy` 的流量分发原理

mysql-9400c172-proxy 的流量分发原理重新优化整理成更清晰、更完整的架构说明文档：

---

mysql-9400c172-proxy 中间件流量分发原理

一、架构概述

mysql-9400c172-proxy 是基于 MaxScale v21.06.16 的数据库代理中间件，部署在 Kubernetes 集群 中。它作为应用与 MySQL 后端数据库之间的中间层，主要实现以下能力：

• 读写分离
• 负载均衡
• 健康检查与自动故障转移
• 连接池与会话管理

---

二、核心组件

1. 后端数据库集群

• server-0: mysql-9400c17200-headless:3306 → 主库 (Master)
• server-1: mysql-9400c17201-headless:3306 → 从库 (Slave)
• server-2: mysql-9400c17202-headless:3306 → 从库 (当前不可用)

2. 监控模块 —— MariaDB-Monitor

• 使用 mysqlmon 模块 持续监控所有数据库节点健康状态

• 监控间隔：1000ms

• 功能：自动主从切换、故障检测

• 当前状态：

  • server-0 处于 Master 角色
  • server-1 处于 Slave 角色
  • server-2 已被剔除，不参与流量路由

3. 服务路由模块

(1) Read-Write-Service（读写分离服务）

• 路由器类型：readwritesplit

• 监听端口：4006

• 策略：

  • 写操作（INSERT/UPDATE/DELETE） → 仅路由至 Master (server-0)
  • 读操作（SELECT） → 负载均衡到 Master 和所有可用 Slave
  • master_accept_reads = true → Master 节点也可承担读请求
  • max_slave_replication_lag = 30 → 当从库延迟超过 30 秒时，不参与读流量

(2) Read-Only-Service（只读服务）

• 路由器类型：readconnroute

• 监听端口：4008

• 策略：

  • 所有请求路由至可用的从库节点（若无可用从库，则请求失败）

---

三、流量分发机制

1. 客户端访问路径

• 外部应用通过 Service mysql-9400c172-proxy:8066 访问
• 实际映射到代理 Pod 的 4006 端口（即 Read-Write-Service）

2. 读写分离逻辑

• 请求流程：

  客户端请求 → MaxScale代理(4006端口) → SQL解析 → 路由决策
  

• 路由决策：

  • 写操作 → 固定转发到 Master (server-0)
  • 读操作 → 负载均衡分发到 Master + 可用 Slaves

3. 健康检查与故障切换

• MariaDB-Monitor 持续探测各节点可用性

• 当 Master 故障时：

  • 自动将健康的 Slave 提升为新 Master
  • 路由配置动态更新

• 当节点不可用（如 server-2）：

  • 自动从路由池中剔除，不影响整体流量

4. 连接池管理

• MaxScale 维护到后端数据库的 持久连接池
• 支持 会话级连接复用，减少连接建立开销
• SQL 变量统一在 Master 节点处理（use_sql_variables_in=master），保证语义一致性

---

四、高可用与一致性特性

• 自动故障检测与主从切换 → 保证服务连续性
• 从库延迟检测 → 确保读请求不会命中过时数据
• 透明的拓扑感知 → 应用无需感知后端角色变更
• 读写分离 + 负载均衡 → 充分利用集群资源，提升吞吐量

---

五、整体架构流程图（逻辑）

           ┌───────────────────────────────────────┐
           │           mysql-9400c172-proxy         │
           │               (MaxScale)               │
           │───────────────────────────────────────│
           │    4006(Read-Write)   |   4008(Read-Only) 
           └───────────┬──────────┘
                       │
           ┌───────────┴─────────────────────────┐
           │   SQL解析 & 路由决策 (readwritesplit) │
           └───────────┬─────────────────────────┘
                       │
        ┌──────────────┼────────────────────────────┐
        │              │                            │
   写请求→ Master(server-0)                  读请求→ Master + Slave(server-1)
                                                   (延迟≤30s)

---

👉 这样整理后，整体结构更分层清晰，逻辑从 组件 → 服务 → 流量分发 → 高可用机制 一步步展开。

要不要我帮你再画一个 K8s 视角的流量示意图（从外部 Service → Proxy Pod → 数据库集群）？