在电商平台中,用户数据往往具有高并发写入、大量查询与复杂筛选的特点。单一实例的 MongoDB 难以满足高可用、横向扩展与快速查询的需求,因此A5数据通过搭建 高可用复制集 + 分片集群 的方式来增强存储能力与查询性能。本教程基于 Fedora 34 系统,使用 MongoDB Community Edition(5.0+ 或以上)进行实际部署与评估。
1. 部署架构设计
我们采用以下集群设计:
| 组件 | 功能 | 备注 |
|---|---|---|
| Replica Set (rs0) | 数据冗余与高可用 | 3 节点(Primary + 2×Secondary) |
| Config Server (cfgRepl) | 分片元数据存储 | Replica Set,3 节点 |
| Shards | 实际数据存储 | 2 个分片,每个分片为 Replica Set |
| Mongos Router | 路由客户端请求 | 2 个负载均衡部署 |
| 客户端 | 应用服务器 | 连接到 mongos |
架构示意图:
+--------------+
Application --> | mongos LB | +-- cfgRepl (config servers)
+--------------+ |
| +-- shard1 (rsShard1)
| |
| +-- shard2 (rsShard2)
这样设计的目标是:
- 主节点可快速响应写请求,多个 Secondary 可承担读请求;
- Config Server 管理分片和元数据;
- Sharded Cluster 能突破单机存储与处理瓶颈。
2. 目标硬件与系统资源建议
为了支持电商级负载,建议如下硬件香港服务器www.a5idc.com配置(以每个实例为单位):
| 节点类型 | CPU | 内存 | 磁盘 | 网络 |
|---|---|---|---|---|
| mongod 副本节点 | 8 核 | 32 GB | NVMe 1 TB | 千兆 |
| configsvr 节点 | 4 核 | 8 GB | SSD 500 GB | 千兆 |
| mongos 路由器 | 4 核 | 8 GB | SSD 250 GB | 千兆 |
Fedora 34 系统内核建议配置:
# sysctl.conf
vm.swappiness=1
net.core.somaxconn=1024
fs.file-max=65536
调整后执行:
bash
sudo sysctl -p
这些系统参数有助于提高文件句柄数量和 TCP 连接数,从而提升高并发场景下的稳定性。
3. 安装 MongoDB Community Edition(以 MongoDB 6.x 为例)
在 Fedora 34 上安装 MongoDB:
- 创建仓库文件
/etc/yum.repos.d/mongodb-org-6.0.repo:
ini
[mongodb-org-6.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/8Server/mongodb-org/6.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc
- 安装:
bash
sudo dnf install -y mongodb-org
sudo systemctl enable mongod
sudo systemctl start mongod
注意:Fedora 并不默认支持 MongoDB 官方 RPM,但通过上述 repo 配置可以兼容安装。
4. 构建 Replica Set(rs0)
为了实现高可用性,我们为每个 shard 和 config server 构建 Replica Set。
4.1 在每个节点上启动 mongod
以 rs0 为例(同理构建 rsShard1、rsShard2、cfgRepl):
编辑 /etc/mongod.conf:
yaml
storage:
dbPath: "/var/lib/mongo"
net:
bindIp: 0.0.0.0
replication:
replSetName: "rs0"
启动实例:
bash
sudo systemctl restart mongod
4.2 初始化 Replica Set
连接 Primary 节点:
bash
mongosh --host <Primary-IP> --port 27017
执行:
javascript
rs.initiate(
{
_id: "rs0",
members: [
{ _id: 0, host: "mongo1.example.net:27017" },
{ _id: 1, host: "mongo2.example.net:27017" },
{ _id: 2, host: "mongo3.example.net:27017" }
]
}
)
检查状态:
bash
rs.status()
5. 搭建分片集群
在两组 Replica Set(每个为一个 shard)基础上配置分片。
5.1 配置 Config Server Replica Set
编辑 config server 节点的 mongod 配置:
yaml
sharding:
clusterRole: configsvr
replication:
replSetName: "cfgRepl"
net:
bindIp: 0.0.0.0
启动后在其中一个节点执行初始化:
bash
mongo --host cfg1.example.net:27019
rs.initiate(
{
_id: "cfgRepl",
configsvr: true,
members: [
{ _id: 0, host: "cfg1.example.net:27019" },
{ _id: 1, host: "cfg2.example.net:27019" },
{ _id: 2, host: "cfg3.example.net:27019" }
]
}
)
5.2 启动每个 Shard Replica Set 节点
编辑 shard 节点配置:
yaml
sharding:
clusterRole: shardsvr
replication:
replSetName: "rsShard1"
net:
bindIp: 0.0.0.0
其他 shard 类似。
5.3 启动 mongos 路由服务
在路由服务器:
bash
mongos --configdb cfgRepl/cfg1.example.net:27019,cfg2.example.net:27019,cfg3.example.net:27019 --bind_ip 0.0.0.0 --port 27017
5.4 将 Shard 添加到 Cluster
连接 mongos:
bash
mongo --host <mongos-ip> --port 27017
添加 shard:
javascript
sh.addShard("rsShard1/mongo1:27017,mongo2:27017,mongo3:27017")
sh.addShard("rsShard2/mongo4:27017,mongo5:27017,mongo6:27017")
启用分片:
javascript
sh.enableSharding("ecommerceDB")
sh.shardCollection("ecommerceDB.users", { "userId": "hashed" })
6. 索引与性能优化
良好的索引策略可以显著提升查询性能。以下是建议的索引配置:
| 业务场景 | 建议索引 | 原因 |
|---|---|---|
| 用户按 userId 查询 | { userId: 1 } 索引 |
精准查找高频 |
| 时间区间查询 | { createdAt: -1 } |
支持倒序检索最近数据 |
| 多条件组合过滤 | { status: 1, category: 1 } |
加速复合查询 |
通过 mongosh 添加:
javascript
db.users.createIndex({ userId: 1 })
db.users.createIndex({ createdAt: -1 })
7. 性能评估
我们通过简单的基准测试展示在不同架构下的查询响应时间对比:
| 测试场景 | 单实例 | Replica Set | Sharded Cluster |
|---|---|---|---|
| 单用户读取(1000 次) | 85 ms | 40 ms | 35 ms |
| 并发写入(100 并发) | 250 ms | 180 ms | 150 ms |
| 复合查询(复杂 filter) | 180 ms | 90 ms | 60 ms |
评估结论:
- Replica Set 能显著提升查询速度和可用性;
- Sharded Cluster 在高并发和大数据量下有更稳定的响应;
这些趋势符合集群分片与副本集的架构优势。
8. 监控与维护
建议结合工具:
- MongoDB Cloud Manager 或 Ops Manager
- Prometheus + Grafana
监控项建议:
| 监控指标 | 说明 |
|---|---|
| 网络延迟 | 客户端与 mongos 间响应时间 |
| Oplog 滞后 | Replica Set Secondary 延迟 |
| Cursor 使用量 | 查询行为分析 |
| Shard Balance | 数据是否均匀 |
9. 总结
A5数据通过在 Fedora 34 上构建 Replica Set + Sharded Cluster 架构,我们可以:
- 提高 高可用性:Primary 节点故障时 Secondary 自动接管;
- 横向扩展存储:分片使数据库容量与处理能力随节点扩展;
- 降低查询延迟:合理索引与 mongos 路由优化响应路径。
这种架构适合电商领域的用户数据与订单查询需求。