首选Redis Cluster（Docker容器化6节点）：3主3从、端口7001–7006、专用网络redis-cluster-net、启用cluster-enabled与appendonly；MySQL高并发则用MySQL 8.0.33 arm64多实例GTID主从，避坑hyperkit驱动、配国内镜像源、禁用中文路径。
在 macOS 上配置支持高并发的本地测试数据库集群，核心是选型合理、资源隔离明确、网络与端口规划清晰，并避开 Apple Silicon 和系统安全策略带来的常见陷阱。不推荐单节点伪集群应付高并发压测——它无法模拟真实分片、主从切换、连接池竞争等关键行为。
首选方案：Redis Cluster（Docker 容器化多节点）
Redis Cluster 天然支持数据分片、自动故障转移和水平扩展，本地启动快、资源占用低，特别适合高并发读写压测场景。Mac 上推荐用 Docker + 自定义网络 + 启动脚本 方式部署：
- 先确保 Docker Desktop 正在运行（或使用 colima：执行
colima start），并启用 “Start when you log in” - 创建专用桥接网络：
docker network create redis-cluster-net（避免与 host 网络冲突，也便于服务发现） - 用统一镜像（如
redis:7.2-alpine）启动 6 个容器（3 主 3 从），每个绑定独立端口（7001–7006），挂载各自配置文件 - 配置文件中必须开启：
cluster-enabled yes、cluster-config-file nodes.conf、cluster-node-timeout 5000、appendonly yes - 全部容器启动后，用
redis-cli --cluster create命令初始化集群，加参数--cluster-replicas 1
MySQL 高并发测试：主从 + 连接池协同验证
若需验证事务一致性、慢查询、主从延迟等 MySQL 特有行为，建议用 MySQL 8.0+ 官方二进制包 + 多实例 + GTID 主从，而非 Docker 单容器——后者难以稳定复现锁竞争与 binlog 传输瓶颈：
- 下载 macOS 兼容的
mysql-8.0.33-macos14-arm64.tar.gz（M1/M2 芯片务必选 arm64 版） - 解压后复制三份，分别命名为
mysql-master、mysql-slave1、mysql-slave2 - 每份中配置独立
my.cnf：设置不同server_id、port（如 3307/3308/3309）、log-bin（仅 master）、gtid_mode=ON - 初始化后依次启动，再用
CHANGE REPLICATION SOURCE TO搭建 GTID 主从；确认SHOW REPLICA STATUS\G中Seconds_Behind_Source为 0 - 压测时用
sysbench或mysqlslap，显式指定多个连接地址（如轮询发往三个端口），才能真正触发连接池竞争与读写分离逻辑
避坑要点：M系列芯片与 macOS 14+ 的特殊处理
Apple Silicon 和新系统版本会放大配置失误的影响，以下三点必须提前检查：
-
不要用 hyperkit 驱动的 minikube 或旧版 VirtualBox 跑数据库集群：macOS 14+ 默认禁用内核扩展，容易报
Failed to start host；改用minikube --driver=docker或直接容器化 -
国内网络下必须配镜像源：Docker 拉取 Redis/MySQL 镜像卡住？在 Docker Desktop → Preferences → Docker Engine 中添加：
"registry-mirrors": ["https://registry.cn-hangzhou.aliyuncs.com"] -
避免中文路径和空格：Nacos、ZooKeeper、MySQL 解压目录含中文或空格会导致集群启动失败（尤其 Java 进程解析路径出错），一律用
/opt/mysql8、/opt/redis-cluster这类纯英文路径
验证是否真支持高并发
配置完不能只看“能连上”，要实测关键指标：
- 用
redis-benchmark -c 200 -n 10000 -t set,get,mset -h 127.0.0.1 -p 7001测试单节点吞吐；再换-c 500观察错误率是否突增 - 对 MySQL 主从集群，用
sysbench --threads=128 --time=60 oltp_read_write并监控SHOW PROCESSLIST中的State分布（大量Waiting for table metadata lock就说明设计有瓶颈） - 用
htop或 Activity Monitor 查看 CPU 核心占用是否均衡；若某节点持续 100%，说明分片不均或客户端未启用集群模式（如 JedisCluster 未正确初始化）
