《Elasticsearch 集群》系列，共包含以下文章：

• 1?? 冷熱集群架構
• 2?? 合適的鍋炒合適的菜：性能與成本平衡原理公式解析
• 3?? ILM（Index Lifecycle Management）策略詳解
• 4?? Elasticsearch 跨機房部署
• 5?? 快照與恢復功能詳解
• 6?? Elasticsearch 快照恢復 API 參數詳解
• 7?? 安全地刪除快照倉庫、快照
• 8?? 快照生命周期管理 SLM（理論篇）
• 9?? 快照生命周期管理 SLM（實戰篇）
• 🔟 跨集群檢索（Cross-Cluster Search）

😊 如果您覺得這篇文章有用 ?? 的話，請給博主一個一鍵三連 🚀🚀🚀 吧 （點贊 🧡、關注 💛、收藏 💚）！！！您的支持 💖💖💖 將激勵 🔥 博主輸出更多優質內容！！！

1.關鍵因素考量

在跨機房和跨機架部署 Elasticsearch 時，需要考慮以下關鍵因素以確保集群的 穩定性、性能 和 可靠性。

1.1 網絡因素

• 網絡延遲：機房之間的網絡延遲應盡可能低（建議 $<10ms$）。
• 帶寬容量：確保有足夠帶寬處理節點間通信和數據傳輸。
• 網絡穩定性：避免頻繁的網絡抖動和中斷。
• 跨機房專線：考慮使用專用網絡連接而非公共互聯網。

1.2 集群配置

• 分片分配感知：配置 cluster.routing.allocation.awareness.attributes 實現機架/機房感知。
• 副本策略：確保每個分片的副本分布在不同的機架/機房。
• 最小主節點數：設置 discovery.zen.minimum_master_nodes 防止腦裂（通常為 (master節點數/2)+1 ）。

1.3 硬件與架構

• 機架/機房標記：為節點配置明確的機架/機房屬性（如 node.attr.rack_id）。
• 主節點分布：將主合格節點均勻分布在不同的機架/機房。
• 負載均衡：確保數據節點在各機架/機房間均衡分布。

1.4 性能優化

• GC 調優：因跨機房通信增加延遲，需優化垃圾回收設置。
• 索引刷新間隔：可適當增加 refresh_interval 減少頻繁刷新。
• 批量操作：增加批量操作大小以減少跨機房請求次數。

1.5 容災與恢復

• 快照策略：定期備份到異地機房。
• 故障轉移測試：定期模擬機房故障測試恢復流程。
• 跨機房復制：考慮使用 CCR（跨集群復制）實現異地容災。

1.6 監控與運維

• 監控網絡指標：密切監控跨機房延遲、丟包率等。
• 日志集中收集：將各機房日志集中到統一位置分析。
• 運維工具：確保運維工具能跨機房操作。

1.7 成本考量

• 帶寬成本：評估跨機房數據傳輸成本。
• 硬件成本：考慮是否需要增加副本數提高容錯能力。
• 維護成本：跨機房部署增加的運維復雜度。

通過綜合考慮這些因素，可以構建一個既具備高可用性又能保持良好性能的跨機房 Elasticsearch 集群。

2.跨機房部署實際案例：電商平臺全球搜索服務

2.1 業務背景

某大型跨境電商平臺需要為其全球用戶提供商品搜索服務，要求：

• 1?? 亞洲、歐洲、美洲用戶訪問延遲均低于 $200ms$。
• 2?? 單個機房故障不影響搜索服務可用性。
• 3?? 支持跨地區商品數據實時搜索。

2.2 集群架構設計

2.2.1 機房布局

[北京機房] - 主數據中心├─ 機架A (10個數據節點)├─ 機架B (10個數據節點)└─ 機架C (3個主節點 + 2個協調節點)[法蘭克福機房] - 歐洲災備中心├─ 機架A (5個數據節點)└─ 機架B (3個主節點 + 2個協調節點)[弗吉尼亞機房] - 美洲災備中心├─ 機架A (5個數據節點)└─ 機架B (3個主節點 + 2個協調節點)

2.2.2 關鍵配置

elasticsearch.yml 部分配置：

# 北京節點配置示例
cluster.name: global-ecommerce-search
node.attr.zone: bj
node.attr.rack: rack_a  # 或rack_b/rack_c
discovery.seed_hosts: ["bj-es01:9300", "fra-es01:9300", "vir-es01:9300"]
cluster.initial_master_nodes: ["bj-master01", "bj-master02", "fra-master01"]

跨機房路由設置：

PUT _cluster/settings
{"persistent": {"cluster.routing.allocation.awareness.attributes": "zone,rack","cluster.routing.allocation.awareness.force.zone.values": "bj,fra,vir","cluster.remote.bj.seeds": "bj-es01:9300","cluster.remote.fra.seeds": "fra-es01:9300","cluster.remote.vir.seeds": "vir-es01:9300"}
}

2.2.3 索引策略

商品索引配置：

PUT products
{"settings": {"number_of_shards": 12,"number_of_replicas": 2,"auto_expand_replicas": "0-1","routing.allocation.include.zone": "bj,fra,vir"},"mappings": {...}
}

2.2.4 跨集群復制（CCR）配置

PUT _ccr/auto_follow/global_products
{"remote_cluster": "bj","leader_index_patterns": ["products"],"follow_index_pattern": "{{leader_index}}-follower"
}

2.3 實際運行效果

2.3.1 性能指標

指標	北京本地訪問	歐洲跨機房訪問	美洲跨機房訪問
平均查詢延遲	$45ms$	$120ms$	$150ms$
索引吞吐量	$12,000$ docs/s	$8,000$ docs/s	$7,500$ docs/s
故障轉移時間	-	$28s$	$32s$

2.3.2 故障處理實例

事件：? 2023 年北京機房網絡中斷 15 分鐘。

系統響應：

• 自動將流量切換到 法蘭克福 機房。
• 協調節點自動將寫入請求路由到 弗吉尼亞 機房。
• 網絡恢復后自動同步數據差異。
• 用戶感知到的服務中斷時間為 $32$ 秒。

2.4 經驗總結

• 主節點分布：保持奇數個主節點且分布在多個機房（采用 3-2-2 分布）。
• 數據冷熱分離：將熱數據主要存放在北京機房，其他機房存放溫數據。
• 動態調整：根據時區自動調整各機房副本數（亞洲白天增加北京副本）。
• 監控重點：
  • 跨機房網絡延遲（GET _nodes/stats/transport）
  • 分片同步狀態（GET _cat/recovery?v）
  • 跨集群復制延遲（GET _ccr/stats）

這個方案成功支持了平臺日均 5 億次搜索請求，在雙11大促期間承受了 3 倍流量增長，同時保證了 $99.99\%$ 的可用性。