ES分片（Shard）和副本（Replica）的作用？如何合理分配？

ES分片和副本

一、分片（Shard）的作用

1. 数据水平扩展
   将索引拆分为多个分片（默认 5 个），实现海量数据分布式存储和并行计算

2. 读写负载均衡
   每个分片作为独立的 Lucene 索引，支持并发读写操作，提升吞吐量

3. 故障隔离能力
   单个分片故障不会导致整个索引不可用，其他分片仍可继续提供服务

二、副本（Replica）的作用

1. 数据高可用
   每个分片的副本（默认 1 个）存储在不同节点，主分片故障时副本自动升级为主分片

2. 读取性能提升
   副本分片可同时处理搜索请求，支持读写分离（写入只发生在主分片，读取可来自副本）

3. 数据冗余保护
   通过副本复制机制防止数据丢失，建议至少设置 1 个副本

三、分配策略建议

// 创建索引时指定分片配置示例
PUT /my_index
{
  "settings": {
    "number_of_shards": 3,   // 主分片数
    "number_of_replicas": 2  // 每个主分片的副本数
  }
}

1. 分片数量规划原则

• 数据总量预估
  单个分片建议 10GB-50GB，过大会影响性能，过小导致资源浪费
• 节点数量匹配
  主分片数 ≤ 数据节点数（建议 1:1 或 1:1.5）
• 索引不可变性
  分片数创建后不可修改，需通过 reindex 调整

2. 副本数量优化方案

• 生产环境
  至少 1 个副本（满足基本高可用）
• 关键业务
  2-3 个副本（金融/医疗等对可用性要求高的场景）
• 写入密集型场景
  临时调为 0 副本（数据初始化阶段），完成后再恢复副本

四、最佳实践案例

日志处理场景（每天 500GB 日志）：

1. 分片计算：500GB/30GB ≈ 17 分片 → 设置为 15/18 分片
2. 副本设置：1 个副本（日志类数据允许短暂不可用）
3. 节点规划：至少 15 个数据节点（保证每个分片有独立节点）

高并发搜索场景：

1. 分片策略：按数据增长趋势设置分片（如年分片）
2. 副本设置：2 个副本（支持大量并发查询）
3. 冷热分离：热数据多副本，冷数据降副本

五、注意事项

1. 使用 _cat/shards API 监控分片状态
2. 避免跨数据中心部署副本（网络延迟影响性能）
3. 通过 ILM（Index Lifecycle Management）自动管理分片生命周期
4. 分片总数控制：每个节点建议承载 20-25 个分片（含副本）

拓展对比

Elasticsearch分片与Redis Cluster Slot分片对比分析

一、核心机制对比

| 对比维度         | Elasticsearch分片                          | Redis Cluster Slot分片          |
|------------------|--------------------------------------------|----------------------------------|
| 设计目标         | 分布式搜索与分析                           | 高性能数据分片与负载均衡         |
| 数据单元         | 索引被拆分为多个分片                       | 16384个虚拟槽位                  |
| 分片数量         | 用户自定义（默认5）                        | 固定16384个槽位                  |
| 数据分布算法     | 文档_id哈希                                | CRC16(key) % 16384               |
| 扩容方式         | 增加副本/新建索引                          | 槽位迁移                         |
| 自动平衡         | 支持                                       | 需手动或工具辅助                 |
| 高可用机制       | 副本分片自动提升                           | 主从复制+故障转移                |

二、配置差异示例

1. Elasticsearch分片配置

PUT /logs
{
  "settings": {
    "number_of_shards": 3,    // 主分片数量
    "number_of_replicas": 1   // 每个主分片的副本数
  }
}

2. Redis Cluster Slot配置

# 节点1负责槽位0-5460
redis-cli --cluster add-node 127.0.0.1:7000 127.0.0.1:7001 --cluster-slots 0-5460

# 节点2负责槽位5461-10922
redis-cli --cluster add-node 127.0.0.1:7002 127.0.0.1:7003 --cluster-slots 5461-10922

# 节点3负责槽位10923-16383
redis-cli --cluster add-node 127.0.0.1:7004 127.0.0.1:7005 --cluster-slots 10923-16383

三、核心差异解析

1. 数据路由机制

   • ES：通过 _routing 参数控制文档存储分片

   // 自定义路由策略示例
   IndexRequest request = new IndexRequest("logs")
       .id("1")
       .source(jsonMap)
       .routing("custom_route_key");  // 自定义路由键
   

   • Redis：使用内置CRC16算法自动计算槽位，客户端直接定位节点

2. 扩容复杂度

   • ES：支持动态增加副本，但主分片数不可变
   • Redis：需执行槽位迁移命令

   redis-cli --cluster reshard 127.0.0.1:7000 --cluster-from node1-id --cluster-to node4-id --cluster-slots 1000
   

3. 故障恢复

   • ES：自动副本提升（需满足最小主节点数）
   • Redis：依赖哨兵机制或手动故障转移

四、最佳适用场景

1. Elasticsearch分片优选场景

   • 需要近实时搜索分析的日志系统
   • 需要动态扩展写入吞吐量的场景
   • 需要自动数据平衡的分布式存储

2. Redis Slot分片适用场景

   • 需要超高吞吐量的缓存系统
   • 需要精确控制数据分布的会话存储
   • 需要线性扩展的实时计数场景

五、性能监控指标对比

| 监控指标         | ES分片监控命令                   | Redis Slot监控命令              |
|------------------|----------------------------------|----------------------------------|
| 分片状态         | GET _cat/shards?v               | CLUSTER SLOTS                   |
| 负载分布         | GET _nodes/hot_threads          | CLUSTER NODES                   |
| 槽位迁移进度     | N/A                             | CLUSTER INFO                    |
| 分片存储细节     | GET _cat/indices/{index}?v      | CLUSTER KEYSLOT {key}           |