汤不热吧跨集群搜索（Cross-Cluster Search, CCS）是 Elasticsearch 中一项强大的功能，它允许用户在单个请求中查询多个独立运行的 Elasticsearch 集群。这对于需要跨越地理位置、满足数据主权要求（如 GDPR），或简单地将大规模基础设施划分为可管理单元的场景至关重要。
本文将详细介绍 CCS 的架构原理，并提供具体操作步骤，教你如何配置和执行跨集群搜索。
什么是跨集群搜索（CCS）？
CCS 允许一个“本地”集群（协调集群，Coordinating Cluster）作为代理，向一个或多个“远程”集群（Remote Clusters）发送查询请求，并将所有结果合并后返回给用户。这意味着数据不必移动，查询逻辑在协调集群中集中管理。
CCS 架构核心优势
- 地理分布式数据管理： 将数据存储在最靠近用户的地理位置（例如，美国用户数据在美国集群，欧洲用户数据在欧洲集群），同时允许全球管理员进行统一查询。
- 隔离与规模化： 不同的业务线或租户可以拥有独立的集群，但通过 CCS 实现集中搜索。
- 成本优化： 无需昂贵的 Logstash/Beats 管道将所有数据汇集到一个巨型集群中。
实操：配置和执行跨集群搜索
假设我们有两个集群：
* Cluster A (本地/协调集群): 用于发起搜索请求。
* Cluster B (远程集群): 包含需要被检索的数据。
步骤 1：准备远程集群数据
首先，确保远程集群 B 上有一个索引和一些数据。假设 Cluster B 的地址是 cluster-b.example.com。
# 在 Cluster B 上创建索引并添加数据
PUT https://cluster-b.example.com:9200/products_eu
PUT https://cluster-b.example.com:9200/products_eu/_doc/1
{
"name": "European Gadget",
"price": 199,
"location": "EU"
}
步骤 2：配置 API Key (安全推荐)
为了让 Cluster A 能够安全访问 Cluster B，推荐使用 API Key。在 Cluster B 上生成一个具有只读权限的 API Key。
# 在 Cluster B 上生成 API Key
POST https://cluster-b.example.com:9200/_security/api_key
{
"name": "ccs_key_for_cluster_a",
"role_descriptors": {
"ccs_reader_role": {
"cluster": ["monitor"],
"index": [
{
"names": ["products_eu"],
"privileges": ["read"]
}
]
}
}
}
# 假设返回的 API Key 是 AAAA_BBBB_CCCC_DDDD
步骤 3：在本地集群 A 中定义远程连接
现在，使用 Cluster A 的 API 将 Cluster B 定义为一个远程集群，并指定连接方式（使用上一步生成的 API Key）。假设 Cluster A 的地址是 cluster-a.example.com。
我们将远程集群命名为 eu_remote。
# 在 Cluster A 上配置远程集群
PUT https://cluster-a.example.com:9200/_cluster/settings
{
"persistent": {
"cluster": {
"remote": {
"eu_remote": {
"skip_unavailable": true,
"mode": "sniff",
"proxy_address": "cluster-b.example.com:9200",
"api_key": "AAAA_BBBB_CCCC_DDDD"
}
}
}
}
}
配置说明：
* eu_remote: 远程集群的别名。
* skip_unavailable: 如果远程集群暂时无法访问，则跳过它而不是失败。
* mode: 使用 sniff 或 proxy。对于大型分布式部署，sniff 模式通常更高效。
* api_key: 用于认证访问 Cluster B 的凭证。
步骤 4：执行跨集群搜索
现在，我们可以从 Cluster A 发起一个搜索请求，同时查询本地索引（假设为 products_us）和远程集群 eu_remote 上的索引 products_eu。
# 在 Cluster A 上发起 CCS 查询
GET https://cluster-a.example.com:9200/products_us,eu_remote:products_eu/_search
{
"query": {
"match": {
"name": "Gadget"
}
},
"size": 10
}
结果解析：
Cluster A 会将查询发送到 Cluster B 的 products_eu 索引，同时查询本地的 products_us 索引。然后，它将合并来自两个集群的命中（hits）和聚合结果，并返回给用户。在返回结果的文档元数据中，_index 字段会以 eu_remote:products_eu 或 products_us 的形式明确标识数据来源。
架构性能考量
虽然 CCS 提供了极大的便利，但其性能主要受以下因素影响：
- 网络延迟： 跨地理位置的查询性能受制于协调集群与远程集群之间的网络延迟。长距离网络延迟直接影响查询响应时间。
- 查询类型： 如果查询涉及深度分页（Deep Paging）或需要大量数据传输的聚合，性能影响会更大。
- 连接配置： 保持连接活跃（Keep-Alive）和使用高性能的认证机制（如 API Keys 或 Kerberos）有助于降低每次查询的握手开销。
对于需要极低延迟的场景，可以考虑使用 CCR（Cross-Cluster Replication，跨集群复制）代替 CCS，但 CCR 涉及数据移动，适用场景不同。