如何设计ES的冷热数据分离架构？Elasticsearch 集群如何实现高可用？如何避免脑裂问题？如果出现脑裂如何恢复？

以下为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}}}}}
}

三、策略核心作用

1. 索引自动滚动（热层）：

• 实时索引：当前活跃索引（如logs-hot-2024.05.20）始终写入热节点组
• 自动切换：达到7天/50GB/1000万文档任一阈值时，自动创建新索引（logs-hot-2024.05.21）
• 性能保障：通过优先级设置（priority:100）确保热索引优先分配计算资源

2. 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); // 自动重试超时设置
}

三、容灾能力体现

1. 数据层容灾（基于配置示例）：

# 分片分配策略
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

2. 客户端容灾（基于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接口监控恢复进度

三、核心原理说明

1. 法定人数机制：通过minimum_master_nodes确保网络分区时只有一个分区能形成多数派
2. 状态版本追踪：cluster_state_version值最大的分区自动成为权威数据源
3. 元数据保护：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