以下為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
