集群 on Liangweidong's blog

Kubernetes 1.x 部署实战：Debian/Ubuntu Kubeadm 初始化与集群规划

Sun, 15 Jun 2025 00:00:00 +0800

背景

Kubernetes（K8s）2014-06 由 Google 开源，2015-07 推出 1.0 版本，如今已是容器编排领域的事实标准。

K8s 解决了什么：

跨机器调度容器（哪台机器跑哪个 Pod）
自愈（容器挂了自动重启）
滚动升级（无停机发布）
服务发现 + 负载均衡
配置管理（ConfigMap / Secret）
存储编排（PV / PVC）

部署 K8s 集群的几种方式：

方式	难度	适用
kubeadm	中	官方推荐、学习首选
kubespray	中	裸金属/混合云，Ansible 自动化
Kops	中	AWS 专用
minikube / kind	低	本地学习
RKE / K3s	低	轻量级、边缘
云厂商托管（EKS/AKS/ACK）	最低	生产首选，免运维

本篇：用 kubeadm 在 Debian/Ubuntu 上手把手部署 1.x 集群，并讲清楚集群规模怎么选。

一、集群规模规划

1.1 最小集群

2 节点：1 master + 1 worker

不推荐生产——master 单点
适合个人学习、临时测试

1.2 推荐最小生产

3 节点：1 master + 2 worker

master 单点（生产勉强）
worker 至少 2 台做 HA 业务

1.3 标准生产

5 节点：3 master + 2 worker

3 master 跑 etcd 集群（容忍 1 台挂）
2 worker 跑业务（容忍 1 台挂）

1.4 规模生产

7 节点：3 master + 4 worker

3 master + 4 worker（worker 可以再多）
7 节点是 K8s 官方文档举例的标准规模

1.5 大规模集群

20+ 节点：

master 必须 3 台或 5 台
worker 数量按业务量扩展
配合 Ingress Controller、Pod 网络 CNI、存储 CSI 等组件

1.6 选型原则

业务规模	推荐节点数	说明
个人/学习	1-2	跑 minikube 就够
小团队（< 50 服务）	3-5	单 master 也能用
中型企业（50-200 服务）	7-10	3 master + 5+ worker
大型企业（200+ 服务）	20+	拆多集群

集群不是越大越好：

节点越多，网络/etcd 同步成本越高
100 节点以上的集群，K8s 控制面性能开始下降
一般 30-50 节点一个集群 较优

二、环境准备

2.1 硬件要求

角色	CPU	内存	磁盘
master	≥ 2 核	≥ 2 GB	≥ 20 GB
worker	≥ 1 核	≥ 1 GB	≥ 20 GB
etcd 专用	≥ 4 核	≥ 8 GB	SSD ≥ 50 GB

生产 master 建议：

4 核 8 GB 起
SSD（etcd 写延迟敏感）

2.2 系统要求

OS：Ubuntu 20.04+ / Debian 11+
内核：≥ 4.19（Ubuntu 20.04 / Debian 11 默认）
网络：所有节点互通
关闭 swap：swapoff -a
关闭防火墙 或放行 K8s 端口（6443、10250、8472/UDP）

2.3 必备设置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 关闭 swap
swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# 2. 加载内核模块
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

# 3. 设置 hostname（每台不同）
hostnamectl set-hostname master1
# 或 worker1

三、安装 kubeadm / kubelet / kubectl

3.1 更新 apt 索引

1
2


sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

3.2 添加 Kubernetes apt 仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 下载 Google Cloud 公开签名密钥
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg \
 https://packages.cloud.google.com/apt/doc/apt-key.gpg

# 添加 apt 源
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] \
https://apt.kubernetes.io/ kubernetes-xenial main" | \
 sudo tee /etc/apt/sources.list.d/kubernetes.list

# 更新索引
sudo apt-get update

3.3 安装组件并锁定版本

1
2


sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

apt-mark hold 至关重要：

K8s 组件必须保持版本一致（kubelet 1.28.2 配 kubeadm 1.28.2）
apt 自动升级会破坏集群
升级必须手动用 kubeadm upgrade 流程

3.4 三个组件的关系

组件	作用	装在
kubeadm	初始化集群的指令	所有节点
kubelet	在每个节点上启动 Pod 和容器的代理	所有节点
kubectl	与集群通信的命令行工具	通常只在 master / 运维机器

为什么不只装一个？kubeadm 是"一次性启动器"，kubelet 是"持续运行代理"，kubectl 是"客户端工具"，三者各司其职。

3.5 kubelet 的"死循环"问题

安装完 kubelet 后，每隔几秒就会重启——

kubelet 现在每隔几秒就会重启，因为它陷入了一个等待 kubeadm 指令的死循环。

正常现象！kubelet 启动后等 kubeadm init 或 kubeadm join 指令，没有指令就一直重启。kubeadm init 完成后就不再重启。

3.6 启用 bash 自动补全

1
2
3
4
5
6
7
8


apt-get install bash-completion

# 临时生效
source <(kubectl completion bash)

# 永久生效
echo "source <(kubectl completion bash)" >> ~/.bashrc
source ~/.bashrc

按 Tab 就能补全 kubectl 子命令。

3.7 拉取 K8s 所需镜像

1
2
3
4
5
6
7
8
9


kubeadm config images list
# 列出 kubeadm init 时要拉的所有镜像
# k8s.gcr.io/kube-apiserver:v1.28.x
# k8s.gcr.io/kube-controller-manager:v1.28.x
# k8s.gcr.io/kube-scheduler:v1.28.x
# k8s.gcr.io/kube-proxy:v1.28.x
# k8s.gcr.io/pause:3.9
# k8s.gcr.io/etcd:3.5.x
# k8s.gcr.io/coredns/coredns:v1.10.x

⚠️ 2024-05 之后的版本：k8s.gcr.io 改为 registry.k8s.io（Google 自有域名）。老教程里的 k8s.gcr.io 可能要改。

国内用户（gcr.io 被墙）：

1
2


# 用国内镜像
kubeadm init --image-repository registry.aliyuncs.com/google_containers

四、初始化 master 节点

4.1 一行命令

1
2
3
4
5
6


sudo kubeadm init \
 --apiserver-advertise-address=<master-ip> \
 --image-repository registry.aliyuncs.com/google_containers \
 --kubernetes-version v1.28.0 \
 --service-cidr=10.96.0.0/12 \
 --pod-network-cidr=10.244.0.0/16

参数说明：

参数	作用
`--apiserver-advertise-address`	master 节点 IP（worker 连这个）
`--image-repository`	镜像仓库（国内用阿里云）
`--kubernetes-version`	K8s 版本（必须与 apt 装的 kubeadm 一致）
`--service-cidr`	Service IP 段
`--pod-network-cidr`	Pod IP 段（必须与 CNI 插件一致）

4.2 安装 CNI 网络插件

K8s 不自带网络，必须装一个 CNI：

Flannel（最简单）：

1

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Calico（功能强、推荐生产）：

1

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Cilium（eBPF、性能最强）：

1

kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.14/install/kubernetes/quick-install.yaml

4.3 配置 kubectl

1
2
3


mkdir -p $HOME/.kube
sudo cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

4.4 验证 master 节点

1
2
3
4
5
6


kubectl get nodes
# NAME STATUS ROLES AGE VERSION
# master1 Ready control-plane 5m v1.28.0

kubectl get pods -A
# 所有系统 Pod 应该是 Running

五、worker 节点加入

5.1 在 master 上获取 join 命令

1
2
3
4


kubeadm token create --print-join-command
# 输出类似：
# kubeadm join 10.0.0.10:6443 --token abcdef.0123456789abcdef \
# --discovery-token-ca-cert-hash sha256:xxxxx

5.2 在每个 worker 上执行

1
2
3


sudo kubeadm join 10.0.0.10:6443 \
 --token abcdef.0123456789abcdef \
 --discovery-token-ca-cert-hash sha256:xxxxx

5.3 验证集群

1
2
3
4
5


kubectl get nodes
# NAME STATUS ROLES AGE VERSION
# master1 Ready control-plane 10m v1.28.0
# worker1 Ready <none> 2m v1.28.0
# worker2 Ready <none> 2m v1.28.0

六、常见问题

6.1 kubeadm init 失败：端口占用

1

[ERROR Port-6443]: Port 6443 is in use

对策：

1
2
3


# 找到占用进程
lsof -i :6443
# 杀掉

6.2 kubeadm init 失败：镜像拉不到

国内：

1

sudo kubeadm init --image-repository registry.aliyuncs.com/google_containers ...

国外：

1
2
3
4


# 看具体哪个镜像失败
kubeadm config images list
docker pull <image>
# 重试

6.3 kubectl get nodes 显示 NotReady

1
2
3
4
5


# 看 kubelet 日志
journalctl -u kubelet -f

# 常见：CNI 没装
# 装 flannel/calico

6.4 节点加入后 5 分钟还是 NotReady

1
2
3
4


# 在 worker 上看 kubelet 日志
journalctl -u kubelet -f

# 常见：网络不通（6443 端口）、token 过期（默认 24h）、ca hash 不对

6.5 重置集群（重新 init）

1
2
3


# 在每个节点上
sudo kubeadm reset
sudo rm -rf /etc/kubernetes /var/lib/etcd

七、升级（必须按 kubeadm 流程）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 1. 升级 kubeadm
sudo apt-get update
sudo apt-get install -y kubeadm=1.29.x-00
sudo apt-mark hold kubeadm

# 2. drain 节点
kubectl drain <node-name> --ignore-daemonsets

# 3. 升级
sudo kubeadm upgrade apply v1.29.x

# 4. 升级 kubelet/kubectl
sudo apt-get install -y kubelet=1.29.x-00 kubectl=1.29.x-00
sudo apt-mark hold kubelet kubectl
sudo systemctl restart kubelet

# 5. uncordon
kubectl uncordon <node-name>

升级顺序：

先 master（一台一台滚）
再 worker（kubectl drain → upgrade → uncordon）
不要跨大版本（1.28 → 1.30 风险大，逐版本 1.28 → 1.29 → 1.30）

八、生产级建议

8.1 高可用 master

3 master 模式（堆叠 etcd）：

1
2
3
4
5
6


# 第一台 master
sudo kubeadm init --control-plane-endpoint "lb-vip:6443" --upload-certs

# 其他 master 用同一命令的 join 输出
sudo kubeadm join lb-vip:6443 --token xxx --discovery-token-ca-cert-hash xxx \
 --control-plane --certificate-key xxx

前置条件：

3 台 master 节点
一个负载均衡 VIP（HAProxy / 云 LB）
VIP 后端 3 台 master 的 6443 端口

8.2 关闭 master 上的业务 Pod

1
2
3


kubectl taint nodes --all node-role.kubernetes.io/control-plane-
# 或反操作：加 taint 让 master 不跑业务
kubectl taint nodes master1 node-role.kubernetes.io/control-plane:NoSchedule

8.3 备份 etcd

1
2
3
4
5
6
7
8
9


# 找 etcd pod
kubectl get pods -n kube-system | grep etcd

# 备份
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%F).db \
 --endpoints=https://127.0.0.1:2379 \
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
 --cert=/etc/kubernetes/pki/etcd/server.crt \
 --key=/etc/kubernetes/pki/etcd/server.key

8.4 监控与日志

metrics-server：kubectl top node/pod
Prometheus + Grafana：监控指标
Loki + Promtail：日志聚合
Jaeger / Tempo：链路追踪

九、卸载

1
2
3
4
5


# 在每个节点
sudo kubeadm reset
sudo apt remove kubeadm kubelet kubectl -y
sudo apt-mark unhold kubeadm kubelet kubectl
sudo rm -rf /etc/kubernetes /var/lib/etcd ~/.kube

小结

K8s 1.x 部署的核心三件套：

kubeadm（init/join 工具）
kubelet（节点代理，每台都装）
kubectl（客户端工具）

集群规模：

学习：1-2 节点（minikube / kind）
生产：3 master + N worker（推荐起点 5 节点）
超大规模：拆多集群，单集群 ≤ 50 节点

生产部署三原则：

HA master（3 台）+ 负载均衡 VIP
apt-mark hold 锁定版本
按官方 kubeadm 流程升级（不要 apt 升级破坏集群）

下一步：

装 Helm（K8s 包管理）
部署 Ingress Controller（Nginx / Traefik）
用 ArgoCD / Flux 做 GitOps
上 Istio / Linkerd 服务网格

源文档：

os/linux/第三方tools/dev/kubernetes/debian安装kubernetes.md（apt 源、版本锁定、bash-completion）
os/linux/第三方tools/dev/kubernetes/k8s集群.md（2/3/5 节点规模选型）

消息队列镜像实战：RabbitMQ / EMQX / ActiveMQ 部署、集群、鉴权与坑点

Fri, 15 Dec 2023 00:00:00 +0800

消息队列（Message Queue）是分布式系统的"解耦器"——把同步调用改成异步消息，把"必须双方都在"改成"消息进来，订阅者啥时候消费都行"。RabbitMQ / ActiveMQ 是 AMQP 协议的"老牌双雄"；EMQX 严格说是 MQTT Broker（IoT 场景为主），但在国内实际项目里经常被混用——所以本文把它一起整理。

这篇文章把三款组件的 docker 部署、集群、鉴权、坑点整理成实战清单。和 0.4 批次的"CI 工具对比"不同，本文只聚焦"镜像实战"——拉哪个镜像、怎么配集群、客户端怎么连、鉴权怎么做。

阅读对象：需要从零搭一套消息队列、或正在做 IoT（MQTT）基础设施的开发者、运维
覆盖范围：三款组件的核心特性对比、RabbitMQ 3.x 部署 + 镜像集群、EMQX 5.x 部署 + 集群 + MySQL 鉴权、ActiveMQ 5.15 部署 + 控制台改密、常见排错

一、三款消息队列对比

维度	RabbitMQ	EMQX	ActiveMQ
协议	AMQP 0-9-1、STOMP、MQTT	MQTT 5.0/3.1.1、WebSocket、CoAP	OpenWire、STOMP、AMQP、MQTT
语言	Erlang	Erlang	Java
镜像大小	200 MB	80 MB	350 MB
内存占用	500 MB~	200 MB~	1 GB~
启动时间	30 秒	5 秒	60 秒
集群模式	内置（多节点镜像）	内置（静态种子 / DNS / etcd）	Master-Slave（已废弃）/ 第三方 ZK 选主
一致性	弱（最终一致）	强（Raft，企业版）	弱
客户端语言	多语言	多语言（IoT 设备为主）	多语言
核心场景	企业应用异步	IoT 设备接入	传统企业应用（JMS）

When to use：

企业应用异步解耦 → RabbitMQ（社区活跃、Erlang 高并发、AMQP 生态成熟）

IoT 设备 / 移动端长连接 → EMQX（百万级连接、MQTT 原生）

遗留 JMS 应用 → ActiveMQ（仅在 Java 老项目里使用）

二、RabbitMQ 部署

2.1 镜像

1

docker pull rabbitmq:3.12-management

3.12-management 自带 rabbitmq_management 插件（WebUI + API），生产推荐用这个。

2.2 最小启动

1
2
3
4
5
6


docker run -d \
 --name rabbitmq \
 --restart=always \
 -p 5672:5672 \  # AMQP
 -p 15672:15672 \  # WebUI
 rabbitmq:3.12-management

访问 http://<HOST>:15672/，默认账号 guest/guest（仅限 localhost 访问）。

坑 1：guest 用户默认只能从 localhost 登录——如果从远程访问 WebUI 报 “User can only log in via localhost”，需要在容器内改：

1
2
3
4
5
6


docker exec -it rabbitmq bash
rabbitmqctl set_permissions -p / guest ".*" ".*" ".*"
# 创建远程用户
rabbitmqctl add_user admin <REDACTED>
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

2.3 持久化 + 主机名

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d \
 --name rabbitmq \
 --restart=always \
 -p 5672:5672 \
 -p 15672:15672 \
 -e RABBITMQ_DEFAULT_USER=admin \
 -e RABBITMQ_DEFAULT_PASS=<REDACTED> \
 -v /data/rabbitmq:/var/lib/rabbitmq \
 --hostname rabbitmq-1 \
 rabbitmq:3.12-management

坑 2：--hostname 必须设——RabbitMQ 集群节点靠 hostname 通信，默认容器 hostname 是随机字符串，每次重启会变。用 --hostname 固定 hostname。

2.4 启用插件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker exec -it rabbitmq bash

# 启用管理插件（已默认启用）
rabbitmq-plugins enable rabbitmq_management

# 启用延迟消息插件（社区）
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

# 启用日志追踪（用于排查生产问题）
rabbitmq-plugins enable rabbitmq_tracing

坑 3：rabbitmq_tracing 插件会显著影响性能（写文件 IO）——只用于排错时临时开启，用完及时关。

2.5 集群部署

RabbitMQ 集群有 3 种模式：

模式	特点	适用
普通集群	队列只在创建它的节点上，其他节点转发请求	几乎不用
镜像队列（HA）	队列在多个节点复制，主从同步	生产推荐
联邦（Federation）	跨地域同步	多数据中心

2.5.1 启动 3 节点

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 节点 1
docker run -d \
 --name rabbitmq-1 \
 --restart=always \
 -p 5672:5672 \
 -p 15672:15672 \
 -e RABBITMQ_DEFAULT_USER=admin \
 -e RABBITMQ_DEFAULT_PASS=<REDACTED> \
 -v /data/rabbitmq-1:/var/lib/rabbitmq \
 --hostname rabbitmq-1 \
 --link rabbitmq-2 \
 --link rabbitmq-3 \
 rabbitmq:3.12-management

# 节点 2 / 节点 3: 同上, hostname 改 rabbitmq-2 / rabbitmq-3

2.5.2 加入集群

1
2
3
4
5
6
7


# 节点 2
docker exec -it rabbitmq-2 bash
rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit@rabbitmq-1
rabbitmqctl start_app

# 节点 3: 同样

2.5.3 配置镜像队列策略

1
2


# 在任一节点执行
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

坑 4：ha-mode=all 表示所有队列在所有节点都有副本——最安全但磁盘 IO 最大。生产建议：ha-mode: exactly, ha-params: 2（每个队列在 2 个节点上同步）。

2.6 客户端使用

Java（Spring Boot）：

1
2
3
4


<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


spring:
 rabbitmq:
 host: <INTERNAL_HOST>
 port: 5672
 username: admin
 password: <REDACTED>
 virtual-host: /
 listener:
 simple:
 prefetch: 1 # 一次只处理一条（公平分发）
 acknowledge-mode: manual
 retry:
 enabled: true
 max-attempts: 3

Go：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import "github.com/rabbitmq/amqp091-go"

conn, _ := amqp.Dial("amqp://admin:<REDACTED>@<INTERNAL_HOST>:5672/")
defer conn.Close()

ch, _ := conn.Channel()
ch.QueueDeclare("my-queue", true, false, false, false, nil)

ch.Publish("", "my-queue", false, false, amqp.Publishing{
 ContentType: "application/json",
 Body: []byte(`{"hello":"world"}`),
})

三、EMQX 部署

EMQX 5.x 是国内最主流的 MQTT Broker——百万级连接、规则引擎、Kafka/数据库桥接都内置。IoT 项目首选。

3.1 镜像

1
2


docker pull emqx/emqx:5.0.24
# 升级到 5.5.x 或 5.7.x 也是同样方法

3.2 单机部署

1
2
3
4


docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:5.0.24

# 设置自动启动
docker update --restart=always emqx

端口说明：

端口	用途
1883	TCP（MQTT 主流）
8883	TCP + SSL
8083	WebSocket
8084	WebSocket + SSL
18083	后台管理 Web

访问 http://<HOST>:18083/，默认账号 admin/public（首次登录强制改密）。

3.3 关闭 api-docs（生产建议）

EMQX 默认开了 api-docs/index.html 暴露所有 API 文档——生产环境应该关。

1
2
3


# 复制配置
docker cp emqx:/opt/emqx/etc/emqx.conf .
vim emqx.conf

1
2
3
4
5
6


dashboard {
 listeners.http {
 bind = 18083
 }
 swagger_support = false # 关闭 api-docs
}

1
2


docker cp emqx.conf emqx:/opt/emqx/etc/emqx.conf
docker restart emqx

3.4 鉴权：MySQL 后端

真实场景：EMQX 用户成千上万，写在配置里不现实。MySQL 鉴权让所有设备凭据从数据库读取。

3.4.1 创建表

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


CREATE TABLE `mqtt_user` (
 `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
 `username` varchar(100) DEFAULT NULL,
 `password_hash` varchar(100) DEFAULT NULL,
 `salt` varchar(35) DEFAULT NULL,
 `is_superuser` tinyint(1) DEFAULT 0,
 `created` datetime DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `mqtt_username` (`username`)
);

3.4.2 EMQX 配置 MySQL 鉴权链

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# emqx.conf
authentication = [
 {
 mechanism = password_based
 backend = built_in_database
 user_id_type = username
 },
 {
 mechanism = password_based
 backend = mysql
 user_id_type = username
 password_hash_algorithm {
 name = sha256
 salt_position = prefix
 }
 server = "<INTERNAL_HOST>:3306"
 database = "emqx"
 username = "emqx"
 password = "<REDACTED>"
 query = "SELECT password_hash, salt FROM mqtt_user WHERE username = ${username} LIMIT 1"
 }
]

3.4.3 插入用户

1
2


INSERT INTO mqtt_user(username, password_hash, salt, is_superuser)
VALUES ('device-001', SHA2(CONCAT('slat_foo123', 'device-secret-001'), 256), 'slat_foo123', 1);

坑 5：EMQX 鉴权链的顺序很重要——built_in_database 排第一意味着先用内置数据库查，查不到再走 MySQL。如果只想用 MySQL，只保留 MySQL 那个 backend。

3.5 集群部署

3.5.1 静态种子集群（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 节点 1 (10.8.33.6)
cat << "EOF" > /home/docker-compose-emqx.yml
version: '3'
services:
 emqx1:
 image: emqx:5.5.1
 container_name: emqx1
 restart: always
 environment:
 - EMQX_NAME=emqx
 - EMQX_HOST=10.8.33.6
 - EMQX_NODE_NAME=emqx@10.8.33.6
 - EMQX_CLUSTER__DISCOVERY_STRATEGY=static
 - EMQX_CLUSTER__STATIC__SEEDS=[emqx@10.8.33.6,emqx@10.8.33.7,emqx@10.8.33.8]
 network_mode: "host"
 healthcheck:
 test: ["CMD", "/opt/emqx/bin/emqx_ctl", "status"]
 interval: 5s
 timeout: 25s
 retries: 5
EOF

# 节点 2/3: 改 EMQX_HOST / EMQX_NODE_NAME 对应 IP

1
2
3
4
5


# 启动
docker-compose -f /home/docker-compose-emqx.yml up -d

# 查看集群状态
docker exec -it emqx1 emqx ctl cluster status

坑 6：EMQX 5.9.0 之后默认仅支持单节点集群——集群能力需要申请商业 License。生产用 5.5.x 或 5.7.x 即可。

3.5.2 Nginx 代理 MQTT

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


stream {
 upstream emqx-tcp {
 server 10.8.33.6:1883;
 server 10.8.33.7:1883;
 server 10.8.33.8:1883;
 }
 server {
 listen 1883;
 proxy_pass emqx_tcp;
 proxy_buffer_size 8k;
 tcp_nodelay on;
 }
}

坑 7：Nginx TCP 代理要 stream 块（不是 http 块）——加错地方 MQTT 设备就连不上。

3.6 客户端测试：MQTTX

MQTTX（https://mqttx.app/）是 EMQX 团队做的 MQTT 客户端工具，桌面版 + CLI 都好用。

1
2
3
4


Broker: mqtt://<YOUR_DOMAIN>:1883
Client ID: mqttx_<random>
Username: device-001
Password: <REDACTED>

订阅主题、发布消息、断线重连——MQTTX 全能搞定。

四、ActiveMQ 部署

ActiveMQ 是 JMS 的"老牌实现"——Java 时代遗留项目还在用。新项目不推荐（RabbitMQ / Kafka 几乎全面取代）。

4.1 镜像

1
2


docker search activemq
docker pull rmohr/activemq

坑 8：ActiveMQ 官方没提供 Docker 镜像——rmohr/activemq 是社区镜像，镜像里 OpenJDK 版本老。生产建议自己 build：

1
2
3
4
5
6
7


FROM openjdk:8-jdk
RUN wget https://archive.apache.org/dist/activemq/5.15.6/apache-activemq-5.15.6-bin.tar.gz && \
 tar -xzf apache-activemq-5.15.6-bin.tar.gz -C /opt && \
 rm apache-activemq-5.15.6-bin.tar.gz
EXPOSE 1883 61616 8161 61614
WORKDIR /opt/apache-activemq-5.15.6
CMD ["bin/activemq", "console"]

4.2 启动

1
2
3
4
5
6
7
8


docker run -d \
 -p 1883:1883 \  # MQTT
 -p 61616:61616 \  # OpenWire
 -p 8161:8161 \  # WebUI
 -p 61614:61614 \  # STOMP
 --restart=always \
 --name myactivemq \
 rmohr/activemq:latest

访问 http://<HOST>:8161/，默认账号 admin/admin。

4.3 改密码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 复制默认配置
docker cp myactivemq:/opt/apache-activemq-5.15.6/conf/jetty-realm.properties ~

# 编辑
vim jetty-realm.properties
# 改:
admin: <NEW_PASSWORD_HASH>,admin
user: <NEW_PASSWORD_HASH>,user

# 复制回去
docker cp jetty-realm.properties myactivemq:/opt/apache-activemq-5.15.6/conf/jetty-realm.properties
docker restart myactivemq

坑 9：ActiveMQ 5.15 之前的版本默认密码是 admin:admin——改密码必须重启容器才能生效（ActiveMQ 把配置加载到内存里）。

4.4 客户端使用

Java（JMS）：

1
2
3
4
5
6
7
8
9


import javax.jms.*;

ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://<INTERNAL_HOST>:61616");
Connection connection = connectionFactory.createConnection("admin", "<REDACTED>");
connection.start();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Destination dest = session.createQueue("my-queue");
MessageProducer producer = session.createProducer(dest);
producer.send(session.createTextMessage("hello world"));

坑 10：ActiveMQ 默认匿名访问——必须显式传用户名密码；否则在生产环境被攻击者直接用。

五、客户端选型建议

5.1 Java

队列	客户端
RabbitMQ	`spring-boot-starter-amqp` / `rabbitmq-client`
EMQX	`org.eclipse.paho.client.mqttv3.MqttClient`（Paho）
ActiveMQ	`org.apache.activemq:activemq-client`

5.2 Go

队列	客户端
RabbitMQ	`github.com/rabbitmq/amqp091-go`
EMQX	`github.com/eclipse/paho.mqtt.golang`
ActiveMQ	`github.com/go-stomp/stomp`（STOMP）/ `github.com/Azure/go-amqp`

5.3 Python

队列	客户端
RabbitMQ	`pika` / `aio-pika`
EMQX	`paho-mqtt` / `asyncio-mqtt`
ActiveMQ	`stomp.py`

六、常见排错

6.1 RabbitMQ 启动报 “nodedown”

症状：rabbitmqctl join_cluster 报 nodedown

排查：

节点间网络可达（ping / telnet 5672 25672）
Erlang Cookie 一致（/var/lib/rabbitmq/.erlang.cookie）
hostname 解析正常（/etc/hosts 里加 hostname → IP）

6.2 EMQX 集群节点不同步

症状：emqx ctl cluster status 显示有节点没加入

排查：

EMQX_CLUSTER__STATIC__SEEDS 里的 hostname / IP 是否能互通
防火墙 5370/5371 端口是否开放（cluster 通信）
节点 EMQX_NAME 是否一致

6.3 ActiveMQ WebUI 502

症状：http://<HOST>:8161/ 报 502

解决：

1
2


docker logs myactivemq | tail -50
# 看启动是否完整, 等 "ActiveMQ WebConsole available at" 才算启动完

坑 11：ActiveMQ 启动慢（60 秒+）——K8s 部署时 readinessProbe 要设 initialDelaySeconds: 60。

6.4 RabbitMQ 队列消息堆积

症状：队列里几万条消息消费不动

排查：

消费者代码 bug？查 /api/queues 里的 messages_ready / messages_unacknowledged
消费者数量不够？加 prefetch 调小 + 多消费者
慢消费者？加监控告警

七、生产环境最佳实践

7.1 RabbitMQ

队列全部设为镜像队列（ha-mode: exactly, ha-params: 2）
禁用 guest 远程登录
WebUI 用 nginx 限制 IP
监控告警：Prometheus + rabbitmq-prometheus 插件

7.2 EMQX

3 节点集群起步（5 节点更稳）
生产用 5.5.x / 5.7.x（5.9+ 集群需商业 License）
关闭 api-docs
Dashboard 限 IP
SSL 双向认证（设备带证书）

7.3 ActiveMQ

尽量不用于新项目
老项目用 LevelDB 存储（比 KahaDB 快）
WebUI 限 IP
监控 JMX（com.sun.management.jmxremote）

八、写在最后

消息队列选型的核心问题不是"用哪个"，而是"用对地方"：

企业内部异步 → RabbitMQ
IoT 设备 / 移动端 → EMQX
遗留 JMS 系统 → ActiveMQ（暂时别动）

下一步建议：

RabbitMQ + 死信队列（DLX） 处理失败消息
EMQX 规则引擎 桥接 Kafka（设备消息转大数据）
ActiveMQ → RabbitMQ 迁移（用 rabbitmq-mqtt 插件兼容 MQTT 客户端）

参考资料

RabbitMQ 官方文档：https://www.rabbitmq.com/documentation.html
EMQX 官方文档：https://www.emqx.io/docs/zh/v5.0/
ActiveMQ 官方文档：https://activemq.apache.org/components/classic/documentation
MQTTX 客户端：https://mqttx.app/
EMQX 5.9 License 变化：https://www.emqx.com/zh/content/license-faq
EMQX MySQL 鉴权：https://www.emqx.io/docs/zh/v5/access-control/authn/mysql.html

MinIO 对象存储实战：单节点 / 集群 / 桶复制 / Spring Boot 集成

Thu, 15 Sep 2022 00:00:00 +0800

MinIO 是 S3 兼容的开源对象存储——国内用得最多的"自建 S3"。本篇把单节点部署、4 节点集群搭建、桶复制双向同步、漏洞修复、Spring Boot 集成一次性整理清楚。

阅读对象：需要自建对象存储的后端 / 运维工程师 覆盖范围：MinIO 单节点 / 4 节点集群 / mc 客户端 / 桶复制 / 主主双向同步 / CVE 漏洞修复 / Nginx 反代安全加固 / Spring Boot 集成 / 分片上传 / 断点续传

一、MinIO 简介

MinIO 的核心特点：

S3 兼容：所有 S3 SDK / 工具都能直接对接
高性能：单机读写可达 100+ GB/s
纠删码：默认 EC:4（4 份数据分片可容忍 4 块盘坏）
多语言 SDK：Java / Go / Python / Node.js / .NET
部署简单：单二进制 + 一个目录就能跑

对比：

维度	MinIO	Ceph	SeaweedFS
部署难度	极简	复杂	中等
性能	极高	高	高
集群最少节点	1（4 节点为生产推荐）	3	3
S3 兼容	100%	✅	✅
适用规模	TB ~ 100PB	PB+	TB ~ PB

When to use：

替代 AWS S3、阿里云 OSS 做自托管

存图片 / 视频 / 备份文件 / 日志

大数据 / AI 训练数据湖

二、单节点部署

2.1 拉取镜像

1

docker pull minio/minio:RELEASE.2023-06-09T07-32-12Z.fips

2.2 启动

1
2
3
4
5
6
7
8
9


docker run -d --name minio --restart=always \
 -p 9091:9091 \
 -p 9090:9090 \
 -v /home/docker/data:/data \
 -e "MINIO_ROOT_USER=root" \
 -e "MINIO_ROOT_PASSWORD={{REDACTED}}" \
 -e "MINIO_SERVER_URL=http://internal.example.com:9091" \
 minio/minio:RELEASE.2023-06-09T07-32-12Z.fips \
 server /data --console-address ":9090" --address ":9091"

端口分配：

9091：S3 API（程序用这个）
9090：Web Console（管理用这个）

环境变量：

MINIO_ROOT_USER / MINIO_ROOT_PASSWORD：管理员账号（旧版本是 MINIO_ACCESS_KEY / MINIO_SECRET_KEY）
MINIO_SERVER_URL：S3 API 外部地址——代码里要用这个

2.3 启动后状态

1
2
3


Status: 1 Online, 0 Offline.
S3-API: http://172.17.0.12:9000 http://127.0.0.1:9000
Console: http://172.17.0.12:9090 http://127.0.0.1:9090

进入容器：

1
2


docker exec -it minio bash
# 配置文件：/usr/local/minio/config

三、4 节点集群部署

3.1 集群规划

节点	IP	角色
node1-1	10.0.1.1	机房 1
node1-2	10.0.1.2	机房 1
node2-1	10.0.2.1	机房 2
node2-2	10.0.2.2	机房 2

3.2 /etc/hosts 配置

1
2
3
4
5
6
7


# 4 个节点都执行
cat >> /etc/hosts <<'EOF'
10.0.1.1 node1-1
10.0.1.2 node1-2
10.0.2.1 node2-1
10.0.2.2 node2-2
EOF

3.3 启动集群

1
2
3
4
5
6
7
8
9


docker run -d --restart=always --name minio \
 --net=host \
 -e MINIO_ROOT_USER=root \
 -e MINIO_ROOT_PASSWORD={{REDACTED}} \
 -v /data/minio/data1:/data1 \
 -v /data/minio/data2:/data2 \
 minio/minio:RELEASE.2023-06-09T07-32-12Z.fips \
 server http://node1-{1...2}:9000/data{1...2} http://node2-{1...2}:9000/data{1...2} \
 --console-address ":9090" --address ":9091"

关键参数：

--net=host：集群通信必须 host 网络
4 节点 8 盘：默认 EC:4 编码，可容忍 4 块盘同时损坏
/data1 /data2：每个节点挂 2 块盘
node1-{1...2}：Docker 展开为 node1-1 node1-2

3.4 集群运维

1
2
3
4
5


# 查看集群状态
mc admin info minio-cluster

# 看每个节点磁盘
mc admin info minio-cluster --json | jq '.info.servers[].state'

四、mc 客户端

4.1 安装

1
2
3
4
5
6


# Linux
curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/bin/mc
chmod +x /usr/local/bin/mc

# Windows
# 下载 https://dl.min.io/client/mc/release/windows-amd64/mc.exe

4.2 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 配置 server alias
mc config host add <ALIAS> <S3-ENDPOINT> <ACCESS-KEY> <SECRET-KEY>

# 列出文件
mc ls <ALIAS>/<bucket>

# 创建 bucket
mc mb <ALIAS>/<bucket-name>

# 上传
mc cp <local-path> <ALIAS>/<bucket>/<key>

# 同步
mc mirror <src> <dst>

# 删除
mc rm <ALIAS>/<bucket>/<key> --recursive --force

4.3 完整示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 1. 加 alias
mc alias set prod http://minio.internal.example.com:9091 root {{REDACTED}}
mc alias set staging http://minio-staging.internal.example.com:9091 root {{REDACTED}}

# 2. 列出所有 bucket
mc ls prod

# 3. 上传整个目录
mc cp ./uploads/ prod/file/ --recursive

# 4. 同步两个 bucket（增量）
mc mirror prod/file staging/file

# 5. 带版本号恢复
mc cp --rewind "2025-12-12T08:00:00Z" --recursive prod/file/dev/ prod/file/dev/

五、桶复制：跨集群数据同步

5.1 单向复制

1
2
3
4
5
6
7
8
9


# 源集群：minio-prod
# 目标集群：minio-staging

# 在目标集群创建 bucket
mc mb minio-staging/file

# 在源集群加复制规则
mc replicate add minio-prod/file \
 --remote-bucket http://{{REPL_USER}}:{{REPL_PASS}}@minio-staging.internal.example.com:9091/file

注意：

源和目标 MinIO 版本必须一致
桶复制只同步新文件，存量数据用 mc mirror 全量同步

5.2 双向主主复制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 在两个集群都执行

# prod 集群
mc replicate add minio-prod/file \
 --remote-bucket http://{{REPL_USER}}:{{REPL_PASS}}@minio-staging.internal.example.com:9091/file \
 --replicate "delete,delete-marker,existing-objects" \
 --sync

# staging 集群
mc replicate add minio-staging/file \
 --remote-bucket http://{{REPL_USER}}:{{REPL_PASS}}@minio-prod.internal.example.com:9091/file \
 --replicate "delete,delete-marker,existing-objects" \
 --sync

# 启用版本控制
mc version enable minio-prod/file
mc version enable minio-staging/file

效果：

上传到 prod 自动同步到 staging
上传到 staging 自动同步到 prod
删除同步

停机测试：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 停 staging
docker stop minio-staging

# 2. 上传到 prod
mc cp test.txt minio-prod/file/

# 3. 启动 staging
docker start minio-staging

# 4. 等待 sync 自动同步（一般 30 秒内）
mc ls minio-staging/file/

六、漏洞修复：桶路径遍历

6.1 漏洞描述

CVE 严重等级：高。当 MinIO 暴露在公网 + 配置 Access Policy 为 public 时，任何人通过桶路径就能列出所有文件：

1

http://minio.example.com:9091/file/

返回的 XML 包含整个桶的所有文件元信息（文件名 + 大小 + 修改时间）。敏感数据直接泄露。

6.2 漏洞根源

listObjects 默认返回 1000 条
公开 bucket + 公开 URL = 可遍历所有资源

6.3 修复方案

方案 A：Nginx 反代 + 路径屏蔽（最推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


server {
 listen 80;
 server_name minio.example.com;

 # 屏蔽桶路径直接访问
 location ^~ /images {
 rewrite ^/images/(.+)$ /images/$1 break;
 proxy_pass http://minio_local_url/;
 }
 # 其他路径禁止
 location / {
 return 403;
 }
}

效果：

http://minio.example.com/images/bucket/file.txt → ✅ 正常下载
http://minio.example.com/images/bucket/ → ❌ 403 禁止列出

方案 B：Bucket 权限收紧

进入 MinIO Console → Bucket → Access Policy → Custom：

1
2


Prefix: *
Access: Read Only (no List)

这样单个文件还能下载，但桶路径列出被禁止。

方案 C（最佳实践）：

MinIO 不暴露公网：只在内网
Nginx 反代 + 路径重写：唯一对外的入口
Bucket 全部 private：永远不开 public
预签名 URL 访问：临时分享用 mc share 或 SDK 生成

七、Spring Boot 集成

7.1 添加依赖

1
2
3
4
5


<dependency>
 <groupId>io.minio</groupId>
 <artifactId>minio</artifactId>
 <version>8.5.10</version>
</dependency>

7.2 配置文件

1
2
3
4
5


minio:
 endpoint: http://minio.internal.example.com:9091
 access-key: root
 secret-key: {{REDACTED}}
 bucket: file

7.3 Spring Boot 配置类

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


@Configuration
public class MinioConfig {
 @Value("${minio.endpoint}")
 private String endpoint;
 @Value("${minio.access-key}")
 private String accessKey;
 @Value("${minio.secret-key}")
 private String secretKey;

 @Bean
 public MinioClient minioClient() {
 return MinioClient.builder()
 .endpoint(endpoint)
 .credentials(accessKey, secretKey)
 .build();
 }
}

7.4 上传服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


@Service
public class MinioService {
 @Autowired
 private MinioClient minioClient;

 public String uploadFile(MultipartFile file, String bucket) throws Exception {
 String objectName = UUID.randomUUID().toString() + "-" + file.getOriginalFilename();

 // 1. 确保 bucket 存在
 boolean found = minioClient.bucketExists(BucketExistsArgs.builder().bucket(bucket).build());
 if (!found) {
 minioClient.makeBucket(MakeBucketArgs.builder().bucket(bucket).build());
 }

 // 2. 上传
 minioClient.putObject(
 PutObjectArgs.builder()
 .bucket(bucket)
 .object(objectName)
 .stream(file.getInputStream(), file.getSize(), -1)
 .contentType(file.getContentType())
 .build()
 );

 return minioClient.getPresignedObjectUrl(
 GetPresignedObjectUrlArgs.builder()
 .bucket(bucket)
 .object(objectName)
 .method(Method.GET)
 .build()
 );
 }
}

八、Spring Boot 高级特性

8.1 分片上传

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


public String initiateMultipartUpload(String bucket, String fileName) throws Exception {
 return minioClient.initiateMultipartUploadAsync(
 InitiateMultipartUploadArgs.builder()
 .bucket(bucket)
 .object(fileName)
 .build()
 ).get().uploadId();
}

public void uploadPart(String bucket, String fileName, String uploadId,
 int partNumber, InputStream data, long size) throws Exception {
 minioClient.uploadPartAsync(
 UploadPartArgs.builder()
 .bucket(bucket)
 .object(fileName)
 .uploadId(uploadId)
 .partNumber(partNumber)
 .stream(data, size, -1)
 .build()
 ).get();
}

8.2 断点续传

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 1. 客户端检查已上传的分片
ListPartsResponse parts = minioClient.listParts(listPartsArgs);

// 2. 跳过已上传的分片
for (int i = 0; i < parts.result().partList().size(); i++) {
 Part part = parts.result().partList().get(i);
 log.info("已上传分片: {} ({} bytes)", part.partNumber(), part.size());
}

// 3. 接着上传未完成部分

8.3 秒传

1
2
3
4
5
6


public boolean isFileExist(String bucket, String md5) throws Exception {
 Iterable<Result<Item>> results = minioClient.listObjects(
 ListObjectsArgs.builder().bucket(bucket).prefix(md5).build()
 );
 return results.iterator().hasNext();
}

前端流程：

1
2
3
4


1. 计算文件 MD5
2. 调后端接口 "isFileExist(md5)"
3. 如果存在 → 秒传成功（直接返回 URL）
4. 如果不存在 → 走后端生成上传凭证 → 前端直传 MinIO

8.4 文件合并

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 前端传完所有分片后调
public void composeFile(String bucket, String targetName, List<String> parts) throws Exception {
 List<ComposeSource> sources = new ArrayList<>();
 for (int i = 0; i < parts.size(); i++) {
 sources.add(ComposeSource.builder()
 .bucket(bucket)
 .object(parts.get(i))
 .build());
 }
 minioClient.composeObject(
 ComposeObjectArgs.builder()
 .bucket(bucket)
 .object(targetName)
 .sources(sources)
 .build()
 );
}

8.5 Nginx 上传调优

1
2
3


# 加大请求体（默认 1m 太小）
client_max_body_size 1024m;
keepalive_timeout 75s;

8.6 Spring Boot 上传调优

1
2
3
4
5


spring:
 servlet:
 multipart:
 max-file-size: 1024MB
 max-request-size: 1024MB

九、监控与运维

9.1 Prometheus metrics

MinIO 默认暴露 /minio/v2/metrics/cluster 端点：

1
2
3
4
5
6


# prometheus.yml
scrape_configs:
 - job_name: 'minio'
 metrics_path: '/minio/v2/metrics/cluster'
 static_configs:
 - targets: ['minio.internal.example.com:9091']

9.2 关键指标

minio_cluster_disk_used_total：磁盘使用
minio_cluster_disk_free_total：剩余空间
minio_s3_requests_total：S3 请求数
minio_s3_requests_errors_total：错误数

9.3 告警规则

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


groups:
- name: minio
 rules:
 - alert: MinIODiskFull
 expr: minio_cluster_disk_free_total / minio_cluster_disk_total < 0.1
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "MinIO 磁盘使用率超过 90%"

十、典型坑位

10.1 启动报 “no credentials”

修复：

1
2


# 环境变量要用 MINIO_ROOT_USER / MINIO_ROOT_PASSWORD（v4 之后）
# 不是 MINIO_ACCESS_KEY / MINIO_SECRET_KEY

10.2 集群节点无法通信

症状：集群启动后某个节点状态 Offline。

修复：

4 个节点 /etc/hosts 都加完整映射
检查 9000 端口互通：nc -zv node1-2 9000
防火墙放过 9000

10.3 上传文件 0 字节

症状：Java 上传后文件 0 字节。

修复：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 错误写法
minioClient.putObject(bucket, objectName, inputStream);

// 正确写法：必须传 size
minioClient.putObject(
 PutObjectArgs.builder()
 .bucket(bucket)
 .object(objectName)
 .stream(inputStream, inputStream.available(), -1)
 .build()
);

inputStream.available() 在某些流上返回 0，必须手动传 size。

十一、最佳实践清单

MinIO 永远不暴露公网：内网 + Nginx 反代
Bucket 全部 private：用预签名 URL 临时分享
Nginx 路径重写：屏蔽桶路径直接访问
集群至少 4 节点：生产强烈推荐
EC 编码：默认 EC:4，可容忍 4 块盘坏
版本控制必开：防止误删除
桶复制必配：跨机房 / 跨地域容灾
Prometheus 监控：磁盘 / 请求 / 错误率
定期备份：用 mc mirror 备份到 OSS

2024+ 视角补充

本文写于 2022-09，2024-2026 期间 MinIO 关键演进：

MinIO RELEASE.2024-08+：AI 推理优化（GPU 直通 / 大模型权重加载）；Iceberg / Delta Lake 表格式支持（数据湖场景）
MinIO 2024+ 性能：单节点 100+ GB/s（NVMe + 网络优化）；EC 编码 8+2（vs 之前 4+2）—— 更大集群容错
MinIO 2025+：Kubernetes Operator GA——minio/operator 已是生产级（强烈推荐 K8s 部署）
MinIO 许可证变更（2024-01）：AGPL 3.0——之前是 Apache 2.0。这对SaaS 厂商影响大（必须开源），企业内部自用无影响
竞品（2024+ 视角）：
- Ceph Quincy / Reef（2024-2025）：Ceph 18 Reef 性能优化（vs MinIO 优势在多协议——RBD / CephFS / RGW）
- Garage 1.0+（2024-2025）：Rust 写的小型 S3 兼容存储——轻量替代
- SeaweedFS 3.x（2024）：FUSE 挂载 / 极简部署
- Cloudflare R2 / Backblaze B2 / 阿里云 OSS（公有云 S3 兼容）——按量计费无需运维

实战建议（2025-2026 视角）：

企业内部 S3 兼容存储 → MinIO 仍是首选（AGPL 不影响自用）
K8s 部署 → MinIO Operator（K8s Operator 模式）2025+ 是生产级
数据湖 / 大数据 → MinIO + Iceberg / Delta Lake（2024-2025 主流）
公有云 → 直接用 R2 / OSS / S3，避免运维
轻量自托管 → Garage 1.0+（10MB 级别二进制）

下一步

想看 NextCloud 网盘自托管（家用云盘）→ NextCloud 网盘自托管
想看 Seafile 私有云盘（高性能文件同步）→ Seafile 私有云盘
想看 FTP 服务自托管（vsftpd / pure-ftpd）→ FTP 服务自托管
想看 Cloudreve 网盘（多存储后端）→ Cloudreve 网盘
想看 Nginx 自建镜像实战（含反代安全加固）→ Nginx 自建镜像实战

K8s Kubeadm 一键部署：从节点规划到应用上线

Wed, 15 Jun 2022 00:00:00 +0800

写于 2022-06，背景：K8s 1.24 正式移除 dockershim，1.25 GA。本文以 kubeadm 1.25 + containerd 1.7 + Ubuntu 22.04 为模板，覆盖从单机到多节点 kubeadm 部署完整流程。

一、Kubeadm vs 二进制部署

维度	kubeadm	二进制
学习成本	低（1 行 init）	高（30+ 步骤）
灵活度	中（kubeadm 配置项可调）	极高（所有 systemd 单元自己写）
升级	官方 `kubeadm upgrade` 一条命令	手动替换二进制 + 改配置
适合场景	生产首选	学习 / 深度定制
证书管理	kubeadm 自动签发 + 90 天续期	自己签 + 自己续
集群自举	kubeadm 自动完成所有控制平面组件部署	自己启动 6+ 个 systemd 单元

结论：生产用 kubeadm，学习用二进制。两者结合最理想。

二、集群规划

3 master + N worker HA 集群（生产推荐）：

主机名	IP	角色	OS
master1	192.168.139.133	master	Ubuntu 22.04
master2	192.168.139.134	master	Ubuntu 22.04
master3	192.168.139.135	master	Ubuntu 22.04
worker1	192.168.139.136	worker	Ubuntu 22.04
worker2	192.168.139.137	worker	Ubuntu 22.04
VIP	192.168.139.150	浮动	（Keepalived）

单 master 集群（测试）：

主机名	IP
master1	192.168.139.133
worker1	192.168.139.136

网络规划：

Node 网络：192.168.139.0/24
Service 网络：10.96.0.0/12
Pod 网络：172.218.0.0/16（Calico）

三、所有节点系统配置

3.1 主机名 + hosts

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 每个节点
hostnamectl set-hostname master1 # 各节点不同

# 所有节点
cat >> /etc/hosts <<EOF
192.168.139.133 master1
192.168.139.134 master2
192.168.139.135 master3
192.168.139.136 worker1
192.168.139.137 worker2
EOF

3.2 关闭 swap / 防火墙 / SELinux

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# swap（K8s 强制关）
swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

# 防火墙（K8s 自己用 iptables）
systemctl stop ufw && systemctl disable ufw
# CentOS: systemctl stop firewalld && systemctl disable firewalld

# SELinux（CentOS 才有）
setenforce 0
sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config

3.3 时间同步

1
2
3


timedatectl set-timezone Asia/Shanghai
apt install -y ntpdate
echo "0 */1 * * * ntpdate time1.aliyun.com" >> /var/spool/cron/crontabs/root

3.4 内核模块与参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 加载模块
cat <<EOF > /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
modprobe overlay
modprobe br_netfilter

# 内核参数
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sysctl --system

3.5 ulimit / IPVS（master 节点）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


ulimit -SHn 65535
cat >> /etc/security/limits.conf <<EOF
* soft nofile 655360
* hard nofile 131072
* soft nproc 655350
* hard nproc 655350
EOF

apt install -y ipset ipvsadm
cat <<EOF | tee /etc/modules-load.d/ipvs.conf
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
EOF
systemctl restart systemd-modules-load.service
lsmod | grep ip_vs

四、安装 containerd（K8s 1.24+）

K8s 1.24 移除 dockershim，必须装 containerd / CRI-O。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 下载
wget https://github.com/containerd/containerd/releases/download/v1.7.11/cri-containerd-1.7.11-linux-amd64.tar.gz

# 解压到根目录
tar Cxzvf / cri-containerd-1.7.11-linux-amd64.tar.gz

# 生成配置
mkdir /etc/containerd
containerd config default > /etc/containerd/config.toml

# 改 sandbox_image 为阿里云镜像
sed -i 's#k8s.gcr.io/pause:3.8#registry.aliyuncs.com/google_containers/pause:3.9#g' /etc/containerd/config.toml

# 改 SystemdCgroup
sed -i 's#SystemdCgroup = false#SystemdCgroup = true#g' /etc/containerd/config.toml

# 启动
systemctl daemon-reload
systemctl enable --now containerd
systemctl status containerd

五、安装 kubeadm / kubelet / kubectl

5.1 阿里云镜像源（推荐 cn region）

1
2
3
4
5


curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | \
 gpg --dearmor > /usr/share/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/kubernetes-apt-keyring.gpg] https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main' | \
 sudo tee /etc/apt/sources.list.d/kubernetes.list
apt update

5.2 安装

1
2
3
4
5
6
7
8


# 查看可用版本
apt-cache madison kubeadm

# 安装指定版本（1.28.2 阿里云镜像版本）
apt install -y kubelet=1.28.2-0 kubeadm=1.28.2-0 kubectl=1.28.2-0

# 锁定版本（防止 apt upgrade 误升）
apt-mark hold kubelet kubeadm kubectl

5.3 命令补全（所有节点）

1
2
3


echo 'source <(kubectl completion bash)' >> ~/.bashrc
alias k=kubectl
complete -F __start_kubectl k

六、初始化 master 节点

6.1 单 master 集群

1
2
3
4
5
6
7
8
9


# 预下载镜像（可选，但生产推荐）
kubeadm config images pull --image-repository=registry.aliyuncs.com/google_containers

# 初始化（默认 /etc/kubernetes/admin.conf）
kubeadm init \
 --image-repository=registry.aliyuncs.com/google_containers \
 --kubernetes-version=v1.28.2 \
 --pod-network-cidr=172.218.0.0/16 \
 --service-cidr=10.96.0.0/12

6.2 高可用集群（3 master）

先用 kubeadm-config.yaml 配置 VIP：

1

kubeadm config print init-defaults > kubeadm-config.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# 编辑 kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
 advertiseAddress: 192.168.139.133 # master1 IP
 bindPort: 6443
nodeRegistration:
 criSocket: unix:///var/run/containerd/containerd.sock
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.2
controlPlaneEndpoint: "192.168.139.150:6443" # VIP（Keepalived 漂移）
imageRepository: registry.aliyuncs.com/google_containers
networking:
 podSubnet: 172.218.0.0/16
 serviceSubnet: 10.96.0.0/12
etcd:
 local:
 extraArgs:
 listen-client-urls: "https://127.0.0.1:2379,https://192.168.139.133:2379"
 advertise-client-urls: "https://192.168.139.133:2379"

1
2
3
4
5


# 初始化
kubeadm init --config kubeadm-config.yaml --upload-certs

# 注意：--upload-certs 自动把证书上传到 etcd
# 其他 master 用 kubeadm join 时加 --certificate-key

保存 join 命令：

1
2
3
4
5
6


# 输出末尾会有 join 命令，复制保存
# 其他 master：
kubeadm join 192.168.139.150:6443 --token xxx --discovery-token-ca-cert-hash sha256:xxx --control-plane --certificate-key xxx

# worker：
kubeadm join 192.168.139.150:6443 --token xxx --discovery-token-ca-cert-hash sha256:xxx

6.3 配置 kubectl

1
2
3
4
5
6
7


mkdir -p $HOME/.kube
cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

# 验证
kubectl get nodes
# master1 NotReady control-plane 1m v1.28.2 ← NotReady 因为还没装 CNI

七、安装 CNI（Calico）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# Tigera Operator
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml

# Custom Resources
cat <<EOF | kubectl apply -f -
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
 name: default
spec:
 calicoNetwork:
 ipPools:
 - blockSize: 26
 cidr: 172.218.0.0/16
 encapsulation: VXLANCrossSubnet
 natOutgoing: Enabled
 nodeSelector: all()
---
apiVersion: operator.tigera.io/v1
kind: APIServer
metadata:
 name: default
spec: {}
EOF

# 等待所有 calico pod running
kubectl get pods -n calico-system -w

八、加入其他节点

8.1 加入 master 节点

1
2
3
4
5
6


# 在 master2 执行
kubeadm join 192.168.139.150:6443 \
 --token abcdef.0123456789abcdef \
 --discovery-token-ca-cert-hash sha256:xxx \
 --control-plane \
 --certificate-key xxx

8.2 加入 worker 节点

1
2
3
4


# 在 worker1 执行
kubeadm join 192.168.139.150:6443 \
 --token abcdef.0123456789abcdef \
 --discovery-token-ca-cert-hash sha256:xxx

8.3 token 过期

master 节点重新生成：

1
2


kubeadm token create --print-join-command
# 输出直接可用的 join 命令

8.4 验证集群

1
2
3
4
5
6
7


kubectl get nodes
# NAME STATUS ROLES AGE VERSION
# master1 Ready control-plane 10m v1.28.2
# master2 Ready control-plane 5m v1.28.2
# master3 Ready control-plane 3m v1.28.2
# worker1 Ready <none> 1m v1.28.2
# worker2 Ready <none> 1m v1.28.2

九、部署测试应用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


# 1. 部署 Deployment + Service（Nginx）
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
spec:
 replicas: 2
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx
 imagePullPolicy: IfNotPresent
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: nginx
spec:
 type: NodePort
 selector:
 app: nginx
 ports:
 - protocol: TCP
 port: 80
 targetPort: 80
 nodePort: 30080
EOF

# 2. 查看
kubectl get pods
kubectl get svc nginx
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# nginx NodePort 10.108.108.103 <none> 80:30080/TCP 30s

# 3. 测试访问
curl http://<任意节点 IP>:30080/

十、清理集群

10.1 优雅重置 master

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 先 drain 节点
kubectl drain master1 --delete-emptydir-data --force --ignore-daemonsets

# 删除所有节点
kubectl delete node --all

# 重置
kubeadm reset
rm -rf /etc/cni/net.d/*
rm -rf /var/lib/cni/calico
rm -rf $HOME/.kube
systemctl daemon-reload && systemctl restart kubelet

10.2 清理 worker 节点

1
2
3


kubeadm reset
# 清理 ipvs 规则
ipvsadm --clear

10.3 手动清理（kubeadm reset 失败时）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 停服务
systemctl stop kubelet kube-proxy containerd
systemctl disable kubelet kube-proxy containerd

# 删文件
rm -rf /var/lib/kubelet
rm -rf /var/lib/containerd
rm -rf /etc/kubernetes
rm -rf /etc/cni/net.d
rm -rf /opt/cni/bin
rm -rf /var/log/pods
rm -rf /var/log/containers

# 清 iptables
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
ipvsadm --clear

十一、升级集群

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 1. 查看升级目标
kubeadm upgrade plan

# 2. 升级 kubeadm（先升第一个 master）
apt-mark unhold kubeadm kubelet kubectl
apt install -y kubeadm=1.28.5-00
apt-mark hold kubeadm kubelet kubectl

# 3. drain 节点
kubectl drain master1 --ignore-daemonsets

# 4. 升级 control-plane
kubeadm upgrade apply v1.28.5

# 5. 升级 kubelet + kubectl
apt install -y kubelet=1.28.5-00 kubectl=1.28.5-00
systemctl daemon-reload
systemctl restart kubelet

# 6. uncordon
kubectl uncordon master1

# 7. 其他 master / worker 重复

十二、常见坑

token 过期：默认 24h，过期后 worker 无法 join，重新生成
single master 改 HA：kubeadm 不支持，必须 reset 重装
CNI 没装先 join worker：worker 卡 NotReady，先装 Calico
controlPlaneEndpoint 用了 master1 IP：master1 挂了就完蛋，必须用 VIP 或 DNS
image-repository 没设：国内环境拉镜像超时
kubeadm reset 失败：手动清理（见 10.3）
Calico / CalicoTypha 内存不足：节点 < 2GB 会卡，加 –memory 限制

十三、前置知识 / 下一步

前置：

K8s 架构基础（参考 2017-06-15《Kubernetes 入门》）
Containerd 容器运行时（参考 2019-12-15《Containerd 实战》）
二进制部署（理解原理，参考 2020-03-15《K8s 二进制部署》）

下一步：

K8s 集群插件（2021-09-15）—— CNI/CoreDNS/Metrics/Dashboard
K8s 资源限制与探针（2022-03-15）—— Pod 调优
K8s 集群管理（2021-12-15）—— 升级 / 节点隔离

参考资料

微服务中间件集群实战：Nacos / Gateway / MySQL / Redis / MQ

Wed, 15 Sep 2021 00:00:00 +0800

本文写于 2021 年 9 月——微服务架构全面铺开，Nacos 2.0+ 已发布一年（2020 年初）、Spring Cloud Gateway 已成事实标准（替代 Zuul）、Redis Cluster 在生产大规模使用，5 大微服务中间件的"集群"方案成为面试必考点。

〇、2021 视角开篇

本文主体内容是 5 大微服务中间件（Gateway / Nacos / MySQL / Redis / MQ）的集群部署实战。2021-09 这个时点选得很巧：

Nacos 2.0（2020-01 发布）刚满 1.5 年，集群方案已稳定（Distro + Raft 双协议）
Spring Cloud Gateway（2018 年发布）替代 Zuul 已成定局，2021.x 是生产主流
Redis Cluster（3.0 起）经过 4 年迭代，3 主 3 从 6 节点模式是生产标配
RocketMQ 4.x（2017 年起）多主多从模式是阿里系标配，Kafka 同期竞争

下文涉及 2016 年时实际并不存在的工具（Nacos / Spring Cloud Gateway），是以 2021 视角讲解"这些工具是何时出现、何时成熟、2021 时点怎么用"。

一、Spring Cloud Gateway 集群

1.1 概述

Spring Cloud Gateway 是 Spring Cloud 的全新项目，基于 Spring 5.0 + Spring Boot 2.0 实现，旨在提供一种简单有效的方式对 API 进行路由，并提供强大的过滤功能：熔断、限流、监控、校验、鉴权。

为什么取代 Zuul？

Zuul 1.x 基于 Servlet 阻塞模型，性能有限
Zuul 2.0 跳票多年（被 Netflix 弃坑），Spring 社区转向基于 WebFlux + Netty 的响应式网关
Gateway 基于 WebFlux 框架，底层用 Netty 通信框架，性能远超 Zuul

1.2 集群部署

Gateway 是无状态服务，集群化非常简单：多实例 + 统一入口。

第一步：pom.xml 依赖

1
2
3
4
5
6
7
8


<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

第二步：application.yml 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


server:
 port: 9527

spring:
 application:
 name: cloud-gateway
 cloud:
 nacos:
 discovery:
 server-addr: nacos-cluster.internal:8848  # Nacos 集群地址
 gateway:
 discovery:
 locator:
 enabled: true # 开启从注册中心自动创建路由
 routes:
 - id: payment_route
 uri: lb://cloud-payment-service  # lb = load balance
 predicates:
 - Path=/payment/**

第三步：Nginx 入口负载均衡

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


upstream gateways {
 server 192.168.6.29:9527 weight=1;
 server 192.168.6.29:9528 weight=1; # 同一台机器两个端口模拟集群
 # server 192.168.6.30:9527 weight=1; # 多机部署
}

server {
 listen 80;
 server_name api.example.com;
 location / {
 proxy_pass http://gateways;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
}

关键点：

Gateway 实例之间不需要通信，各自从 Nacos 拉服务列表
网关自身的负载均衡交给 Nginx / F5 / SLB
网关是无状态服务，可以水平扩展

二、Nacos 集群

2.1 三种部署模式

单机模式：用于测试和单机使用
集群模式：用于生产环境，确保高可用
多集群模式：用于多数据中心场景

2.2 集群部署（Nacos ≥ 2.0）

前置：nacos 集群至少需要 3 个节点，因此准备 3 台服务器。

第一步：安装依赖

1
2
3


# 1. 安装 MySQL（nacos 配置持久化）
# 2. 安装 JDK 8+
# 3. 安装 Maven（仅首次构建时需要）

第二步：初始化数据库

执行 nacos 自带 SQL：conf/nacos-mysql.sql，创建 nacos_config 数据库和表。

第三步：配置 cluster.conf

将 conf/cluster.conf.example 改名为 cluster.conf：

1
2
3
4


# cluster.conf
192.168.6.21:8848
192.168.6.22:8848
192.168.6.23:8848

第四步：配置 application.properties

1
2
3
4
5


spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://192.168.6.10:3306/nacos_config?useUnicode=true&characterEncoding=utf-8
db.user=nacos
db.password={{REDACTED}}

第五步：启动

1

sh startup.sh

单台服务器启动成功后，对集群其他服务器重复同样操作即可。

2.3 集群原理

Distro 协议（AP 模式，默认）：nacos 自研的最终一致协议，每个节点负责一部分服务，多节点互写互读
Raft 协议（CP 模式，配置中心）：持久化配置走 Raft，保证强一致
节点间通过 gRPC 长连接 同步数据

三、MySQL 主从集群

3.1 集群目的

采用 MySQL 集群需要部署主从关系：

主节点：写数据（INSERT / UPDATE / DELETE）
从节点：读数据（SELECT）
关系：一主多从，用户从多个从节点读数据，大大缓解读取压力
额外收益：主节点写入自动同步到从节点，降低数据丢失风险

3.2 主从复制原理

MySQL 主从复制基于主服务器二进制日志（binlog） 跟踪所有对数据库的更改。

工作过程：

1
2
3
4
5
6
7
8
9


┌─────────┐ ┌─────────┐
│ Master │ │ Slave │
│ │ │ │
│ binlog │ <── (1) 读 binlog ─── I/O 线程 ──│ relay │
│ dump │ │ log │
│ 线程 │ ── (2) 传 binlog ───────────> │ │
│ │ │ SQL 线程│
│ │ <── (3) 同步完成通知 ───────────│ │
└─────────┘ └─────────┘

从库生成两个线程：一个 I/O 线程，一个 SQL 线程
I/O 线程请求主库的 binlog，并将 binlog 写到 relay log（中继日志）
主库生成 log dump 线程，用来给从库 I/O 线程传 binlog
SQL 线程读取 relay log，解析成具体操作，实现主从一致

3.3 核心配置

主库 my.cnf：

1
2
3
4
5


[mysqld]
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
binlog-format = ROW
sync_binlog = 1

从库 my.cnf：

1
2
3
4


[mysqld]
server-id = 2
relay-log = /var/lib/mysql/relay-log
read-only = 1

主库授权：

1
2


grant replication slave on *.* to 'repl_user'@'%' identified by '{{REDACTED}}';
flush privileges;

从库配置同步：

1
2
3
4
5
6
7
8
9


CHANGE MASTER TO
 MASTER_HOST='192.168.6.21',
 MASTER_USER='repl_user',
 MASTER_PASSWORD='{{REDACTED}}',
 MASTER_LOG_FILE='mysql-bin.000001',
 MASTER_LOG_POS=0;

START SLAVE;
SHOW SLAVE STATUS\G # 看 Slave_IO_Running: Yes, Slave_SQL_Running: Yes

3.4 读写分离

两种实现方式：

数据库中间件（Mycat / Sharding-Proxy）：单独部署服务，配置实现读写分离，不侵入业务代码
客户端 SDK（dynamic-datasource / shardingsphere-jdbc）：业务代码引入 jar 包，通过注解切换

dynamic-datasource 示例（Spring Boot）：

1
2
3
4
5


<dependency>
 <groupId>com.baomidou</groupId>
 <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
 <version>3.3.2</version>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


spring:
 datasource:
 dynamic:
 primary: master
 datasource:
 master:
 url: jdbc:mysql://192.168.6.21:3306/test
 username: root
 password: {{REDACTED}}
 driver-class-name: com.mysql.cj.jdbc.Driver
 slave1:
 url: jdbc:mysql://192.168.6.22:3306/test
 username: root
 password: {{REDACTED}}
 driver-class-name: com.mysql.cj.jdbc.Driver

1
2
3
4
5
6
7
8


@Service
public class OrderService {
 @DS("master") // 写主库
 public void createOrder(Order order) { ... }
 
 @DS("slave1") // 读从库
 public List<Order> listOrders() { ... }
}

3.5 分库分表

两种方案：

Sharding Sphere（推荐）：JDBC 代理 / Proxy 模式
Mycat 2：数据库中间件，需要独立部署

四、Redis 集群

4.1 三种集群方案

主从复制模式：1 主 N 从，主写从读，但主挂了不会自动切换（需要手动）
Sentinel（哨兵）模式：在主从基础上加哨兵进程监控，主挂了自动选举新主（推荐中小规模）
Cluster 模式：Redis 3.0+ 官方方案，数据分片 + 主从 + 自动故障转移（推荐大规模）

4.2 集群部署（Cluster 模式）

官方推荐：集群至少 3 个 master 节点，最好用 3 主 3 从 6 节点模式。

1
2
3
4
5
6


# 启用集群模式
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
# 至少 3 个 master
cluster-migration-barrier 1

创建集群：

1
2
3
4


redis-cli --cluster create \
 192.168.6.31:6379 192.168.6.32:6379 192.168.6.33:6379 \
 192.168.6.34:6379 192.168.6.35:6379 192.168.6.36:6379 \
 --cluster-replicas 1

4.3 Cluster 原理

数据分片：16384 个 slot（哈希槽），每个 master 负责一段
请求路由：客户端通过 CRC16(key) % 16384 计算 slot
重定向：如果请求路由到错误节点，会返回 MOVED 或 ASK 让客户端重试
故障转移：master 挂了，从节点通过 Raft-like 协议选举新主

五、消息队列集群

5.1 RabbitMQ 集群

普通集群：多节点共享元数据，队列只在单节点，性能提升有限
镜像集群：队列数据多节点同步，HA 能力强但性能低
推荐方案：普通集群 + HAProxy + 镜像队列（关键业务队列）

5.2 RocketMQ 集群

NameServer 集群：无状态，多节点即可
Broker 集群：分 Master / Slave
- 多 Master：高性能但无 HA
- 多 Master 多 Slave（异步复制）：性能 + HA 平衡
- 多 Master 多 Slave（同步双写）：强 HA，性能低
推荐方案：2 主 2 异步从 + 异步刷盘

六、5 大集群对比

集群	核心协议	关键配置	HA 能力	数据一致性
Gateway	无（无状态）	Nginx upstream	自动（多实例）	无（无状态）
Nacos	Distro + Raft	cluster.conf + MySQL	自动（≥3 节点）	AP+CP 混合
MySQL	binlog + relay log	server-id + log-bin	半自动（需切换）	最终一致
Redis Cluster	哈希槽（16384）	cluster-enabled	自动（≥3 master）	最终一致
RabbitMQ	镜像队列	cluster_partition_handling	自动（镜像）	最终一致
RocketMQ	主从同步	brokerRole	自动（多主多从）	异步/同步

七、面试常问

Q：为什么 Nacos 集群至少 3 个节点？ A：Raft 协议要求过半节点存活才能选举 Leader，3 节点允许 1 节点宕机，5 节点允许 2 节点宕机。奇数节点是性价比最高的选择。

Q：MySQL 主从延迟怎么解决？ A：① 业务容忍延迟（异步复制天然有 ms 级延迟）；② 强制读主（重要业务读写都走主）；③ 半同步复制（MySQL 5.7+ rpl_semi_sync_master_wait_slave_count）；④ 用 Canal 订阅 binlog 同步到 ES / Redis。

Q：Redis Cluster 为什么是 16384 个 slot？ A：因为 16384 足够均匀分布，节点间心跳包大小可控（每个 slot 1 bit，16384 / 8 = 2KB，远小于 1MB 网络包上限）。如果用 65536，心跳包会膨胀到 8KB，且实际场景下节点数不会超过 1000，16384 足够。

Q：Spring Cloud Gateway 怎么限流？ A：内置 RequestRateLimiter GatewayFilter，基于 Redis + Lua 脚本实现令牌桶。Key 可以基于 IP / User / API Path。

八、小结

Gateway 无状态：集群 = 多实例 + 入口 LB
Nacos 集群：3 节点起步 + MySQL 持久化
MySQL 主从：binlog 同步 + 读写分离中间件
Redis Cluster：16384 哈希槽 + 3 主 3 从
MQ 集群：RabbitMQ 镜像队列 / RocketMQ 多主多从

九、2021 视角回望（微服务面试考点演化）

站在 2021-09 收尾，回看"5 大集群对比"那一节，再补充几点2021 时点的面试新趋势：

Nacos 2.0 的 gRPC 长连接：2020 年 Nacos 2.0 把数据同步从 HTTP 短连接改成长连接，性能提升 10 倍，是高频面试追问点
Spring Cloud Gateway 限流细节：内置 RequestRateLimiter + Redis Lua 是高频八股文，几乎所有 Java 面试都会问
MySQL 5.7 → 8.0 升级：2021 年 5.7 EOL 时间已定（2023-10），8.0 的 MGR（MySQL Group Replication）开始被生产采用
Redis 6.x 的多线程 IO：2020 年 Redis 6.0 发布，IO 多线程化但执行命令仍单线程，集群方案未变
Kafka vs RocketMQ 二选一：阿里系项目用 RocketMQ（事务消息），其他用 Kafka（生态 + 吞吐），2021 年仍是常见面试题

2021 时点的"5 大集群面试"标准答案：

Gateway 无状态 → 集群 = Nginx upstream + 多实例
Nacos 集群 → 至少 3 节点（过半选举） + MySQL 持久化 + gRPC 2.0 同步
MySQL 主从 → binlog + relay log + 读写分离（ShardingSphere / dynamic-datasource）
Redis Cluster → 16384 哈希槽 + 3 主 3 从 + 客户端路由
MQ 集群 → RabbitMQ 镜像队列 / RocketMQ 多主多从（同步双写保 HA）