在Splunk的分布式架构中，索引器（Indexer）与搜索头（Search Head）承担着截然不同的职责。索引器负责接收来自转发器或HTTP接口的数据，进行分词、压缩并写入索引文件；搜索头则负责接收用户的搜索请求，将查询分发给索引器并汇总结果。如果初期图省事把两者放在同一节点，当每日数据量超过几十GB后，磁盘IO与搜索计算的资源争抢会迅速拖垮整体响应。理解角色差异是规划部署的第一步。
索引器与搜索头的职责边界
索引器的核心任务是数据持久化。它从接收队列中拉取原始事件，依据源类型（sourcetype）匹配预处理规则，执行字段提取、换行合并、时间戳识别等操作，随后将数据以倒排索引和原始压缩块的形式落盘。这个过程对顺序写吞吐和磁盘空间极为敏感，通常建议采用多块高速磁盘组成独立卷，并关闭会影响写入的实时防病毒扫描。索引器之间可以通过索引器集群（Indexer Clustering）实现数据副本，保障单节点故障不丢数据。
搜索头并不存储原始数据，它只保存用户的报表、仪表盘、知识对象（如字段别名、查找表）以及搜索调度状态。当用户提交一个搜索，搜索头会将查询语句解析为分发计划，向各个索引器发送子查询，待索引器返回结果后在内存中完成关联、统计与排序。因此搜索头更依赖CPU核心数与内存容量，尤其在并行运行大量计划报表时，内存不足会直接导致搜索失败。将搜索头独立出来，可避免其计算压力干扰索引器的稳定写入。
从运维角度看，角色分离还简化了容量规划。索引器扩容通常意味着加磁盘和加节点以分散写入；搜索头扩容则是提升并发查询能力或引入搜索头集群。两者解耦后，可以针对业务特征单独调整，比如日志爆发期优先扩索引器，报表需求增长时再扩搜索头，不必整机替换。
独立部署与单实例部署的对比
单实例部署指在一台服务器上同时运行索引器和搜索头，适用于功能验证、家庭实验室或极低数据量场景。其优势是安装简单、资源占用集中、排查问题方便。但一旦进入生产环境，单实例的瓶颈非常明显：索引写入占用磁盘IO高峰时，搜索头的聚合计算会因IO等待变慢；反之复杂报表也会拖慢数据落地，造成转发器队列堆积。
独立部署采用至少两台物理或虚拟服务器，一台专做索引器（或索引器集群），一台专做搜索头。下例展示通过配置文件指定搜索头指向独立索引器的方法，在搜索头的distsearch.conf中定义成员：
[distributedSearch] servers = indexer1:8089,indexer2:8089 [general] site = site1
上述配置让搜索头把查询分发到indexer1与indexer2。实测中，当日均数据量达到100GB时，独立部署的搜索中位数延迟比单实例低约60%，索引写入积压概率下降到原来的五分之一。当然独立部署需要更多license折算与网络规划，但对生产系统而言，这点投入远低于故障停机的代价。
如果预算有限，也可采用中间方案：将搜索头与轻量转发器同机，索引器独立。但绝不建议把重负载搜索和索引写混布。下表列出三种模式的适用边界：
| 部署模式 | 适用数据量 | 主要风险 |
|---|---|---|
| 单实例 | <20GB/天 | IO争抢、难扩展 |
| 索引器独立+搜索头独立 | >50GB/天 | 成本较高 |
| 索引器集群+搜索头集群 | >500GB/天 | 运维复杂 |
搜索头集群与高可用设计
当单台搜索头成为瓶颈或单点隐患时，应引入搜索头集群（Search Head Clustering）。集群由一台 captain 和若干成员组成，通过心跳同步用户态知识对象与调度任务。captain 负责选举与协调，若宕机，成员会在数秒内重新选主，用户搜索会话可无缝迁移。配置集群需在每台的server.conf中声明相同集群名与不同站点：
[shclustering] mode = member captain_uri = https://sh1:8089 pass4SymmKey = 加密密钥 cluster_label = shc_group
搜索头集群并不减轻索引器负担，但能横向扩展交互能力。例如三节点集群可承载的并发仪表盘加载量约为单节点的2.5倍，且某节点维护时其余节点继续服务。需要注意，集群内所有搜索头必须版本一致，否则会导致配置同步失败。知识对象应统一通过 captain 分发，避免手工在成员上改报表造成不一致。
在跨数据中心场景中，可结合索引器站点感知（Site Awareness）让搜索头优先查询本地站点索引器，降低广域网延迟。此时部署逻辑变为：每个数据中心有独立索引器站点，搜索头集群跨站点部署但标记归属，查询自动就近。这种架构既满足容灾，又避免全局查询拖慢体验。规划时务必提前算清副本数与网络带宽，否则跨站同步反而会拖累性能。
综合来看，Splunk的索引器与搜索头部署没有一成不变的模板，但角色分离是前提。先按数据量选定索引器规模，再据查询并发决定搜索头形态，最后用集群填补高可用缺口，才能构建既稳又活的日志平台。