以下为Elasticsearch架构设计与高可用方案详细说明：
冷热架构
一、冷热数据分离架构设计（文字描述模拟架构图）
[Hot Layer]
│
├─ SSD节点组（3节点）
│ ├─ 角色：ingest/data/hot
│ ├─ 存储：近7天数据
│ └─ 策略：索引自动滚动
│
[Warm Layer]
│
├─ HDD节点组（5节点）
│ ├─ 角色：data/warm
│ ├─ 存储：历史数据
│ └─ 策略：ILM策略自动迁移
│
[Coordinator Layer]
└─ 独立协调节点（2节点）└─ 角色：coordinating_only
以下是基于冷热分离架构的详细读写流程及策略解析：
一、读写流程说明
1. 数据写入流程
// 客户端写入示例（自动路由到热节点）
IndexRequest request = new IndexRequest("logs-hot-2024.05.20").source(jsonMap, XContentType.JSON).setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE); // 使用BulkProcessor自动批量提交
BulkProcessor bulkProcessor = BulkProcessor.builder((request, bulkListener) -> client.bulkAsync(request, bulkListener),new BulkProcessor.Listener() { /* ... */ }).setBulkActions(1000).setFlushInterval(TimeValue.timeValueSeconds(5)).build();
2. 数据读取流程
// 查询请求（协调节点自动路由）
SearchRequest request = new SearchRequest("logs-*").source(new SearchSourceBuilder().query(QueryBuilders.rangeQuery("@timestamp").gte("now-7d/d")).size(100));// 设置查询偏好（优先热节点）
request.preference("_only_nodes:hot"); SearchResponse response = client.search(request, RequestOptions.DEFAULT);
二、核心策略解析
1. 索引自动滚动策略（热层）
{"policy": {"phases": {"hot": {"min_age": "0ms","actions": {"rollover": {"max_age": "7d","max_size": "50gb","max_docs": 10000000},"set_priority": {"priority": 100}}}}}
}
2. ILM迁移策略（暖层）
{"policy": {"phases": {"warm": {"min_age": "7d","actions": {"allocate": {"require": {"data": "warm"},"number_of_replicas": 2},"shrink": {"number_of_shards": 1},"forcemerge": {"max_num_segments": 1}}}}}
}
三、策略核心作用
- 索引自动滚动（热层）：
- 实时索引：当前活跃索引（如logs-hot-2024.05.20）始终写入热节点组
- 自动切换：达到7天/50GB/1000万文档任一阈值时，自动创建新索引（logs-hot-2024.05.21）
- 性能保障：通过优先级设置（priority:100）确保热索引优先分配计算资源
- ILM迁移策略（暖层）：
- 自动迁移：索引年龄超过7天后，自动迁移到HDD节点组
- 存储优化：合并段文件（forcemerge）减少磁盘占用，收缩分片数（shrink）提升查询效率
- 副本扩展：增加副本数到2份，保障历史数据可用性
四、读写优化效果
| 指标 | 热层（SSD） | 暖层（HDD） |
|---|---|---|
| 写入吞吐量 | 50k+ docs/sec | 5k+ docs/sec |
| 查询延迟 | <100ms (P99) | <500ms (P99) |
| 存储成本 | $0.15/GB/month | $0.03/GB/month |
| 存储密度 | 3副本 | 2副本+压缩 |
五、架构验证命令
# 查看索引分布
GET _cat/indices?v&h=index,pri,rep,store.size,node# 监控ILM执行状态
GET _ilm/policy/logs-policy?human# 检查分片分配
GET _cluster/allocation/explain
二、高可用实战配置
一、高可用架构示意图（文字描述版）
[高可用集群架构]
├─ 主节点组（3节点）
│ ├─ 角色：master
│ ├─ 选举策略：多数派仲裁（minimum_master_nodes=2）
│ └─ 容灾：跨物理机架部署
│
├─ 热数据节点组（3节点）
│ ├─ 存储介质：SSD
│ ├─ 副本策略：1同步副本
│ └─ 容灾：自动分片重平衡
│
├─ 冷数据节点组（5节点）
│ ├─ 存储介质：HDD
│ ├─ 副本策略：2异步副本
│ └─ 容灾：跨机房异步复制
│
└─ 协调节点组（2节点） ├─ 请求路由：负载均衡 └─ 容灾：客户端重试机制
二、高可用实现原理
// 高可用核心实现
public class HighAvailability {// 1. 节点角色隔离private static final String[] MASTER_ROLES = {"master"};private static final String[] DATA_HOT_ROLES = {"data", "ingest"};// 2. 数据分片策略int numberOfShards = 5; // 分片数=节点数int numberOfReplicas = 1; // 实时同步副本// 3. 客户端重试机制RestClientBuilder.RequestConfigCallback config = builder -> builder.setConnectionRequestTimeout(5000).setSocketTimeout(60000).setMaxRetryTimeout(30000); // 自动重试超时设置
}
三、容灾能力体现
- 数据层容灾（基于配置示例）：
# 分片分配策略
cluster.routing.allocation.enable: all
indices.recovery.max_bytes_per_sec: 200mb# 故障检测（10秒超时）
discovery.zen.fd.ping_interval: 3s
discovery.zen.fd.ping_timeout: 10s
discovery.zen.fd.ping_retries: 3
- 客户端容灾（基于Java示例）：
// 多节点接入 + 失效转移
RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(new HttpHost("es01", 9200),new HttpHost("es02", 9200),new HttpHost("es03", 9200)).setFailureListener(new LoggingFailureListener()) // 节点失效日志记录.setNodeSelector(NodeSelector.SKIP_DEDICATED_MASTERS) // 自动跳过专用master节点
);
四、容灾验证命令
# 查看分片分布（R=副本分片）
GET _cat/shards?v&h=index,shard,prirep,state,docs,node# 模拟节点宕机测试
POST _cluster/nodes/es01/_shutdown# 观察分片恢复进度（应有自动重新分配）
GET _cat/recovery?v&active_only=true
五、关键配置说明
| 配置项 | 容灾作用 | 推荐值 |
|---|---|---|
| node.roles | 角色隔离防止单点故障 | 专用角色分配 |
| discovery.seed_hosts | 多节点发现防单点失效 | ≥3节点列表 |
| bootstrap.memory_lock | 防止内存交换导致性能下降 | true |
| network.host | 多网卡绑定提升网络可靠性 | site |
三、脑裂问题解决方案
一、脑裂预防三重保障
# 1. 法定节点数控制（N/2+1）
discovery.zen.minimum_master_nodes: 2# 2. 角色严格隔离（专用master节点）
node.roles: [ master ]# 3. 网络分区感知
cluster.routing.allocation.awareness.attributes: zone
node.attr.zone: zone1
二、脑裂自恢复五步法
# 1. 停服保数据（Windows PowerShell）
Stop-Service elasticsearch-service# 2. 日志定位权威分区（查看最新cluster_state_version）
Select-String -Path "elasticsearch.log" -Pattern "cluster_state_version"# 3. 重置异常节点数据
Remove-Item -Recurse -Force "D:\esdata\nodes\0\_state"# 4. 优先启动权威分区节点
Start-Service elasticsearch-service -ComputerName es-master01# 5. 增量恢复非权威节点
# 通过_cat/recovery接口监控恢复进度
三、核心原理说明
- 法定人数机制：通过minimum_master_nodes确保网络分区时只有一个分区能形成多数派
- 状态版本追踪：cluster_state_version值最大的分区自动成为权威数据源
- 元数据保护：gateway模块持久化最新集群状态，确保重启后恢复最后有效状态
四、实战验证命令
# 检查master节点状态
GET _cat/nodes?v&h=name,master,version# 查看集群健康日志
GET _cluster/health?filter_path=status,number_of_nodes# 验证分片分配策略
GET _cluster/settings?include_defaults=true&filter_path=**.awareness*
五、高可用架构建议
[机房A] [机房B]
├─ master节点（3台） └─ 协调节点（2台）
└─ 热数据节点（SSD） └─ 温数据节点（HDD）
跨机房部署时需配置：
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2
