为什么缓存事实能提速
默认每个 play 开头会对每台主机做一次事实采集：建立连接、收集系统信息、返回并解析。一个仓库里既有配置 play 又有巡检 play 时，同一批主机会被反复探测，纯重复劳动。事实缓存把采集结果按主机存到一个后端，设置为智能模式后，命中缓存的主机直接跳过探测。收益随“多 play 跑同一批主机”和“节点数量”放大。
基本信息
| 启用开关 | gathering（smart 为缓存优先）、fact_caching 指定后端 |
|---|---|
| 连接配置 | fact_caching_connection 指定存储位置或连接地址 |
| 有效期 | fact_caching_timeout（秒），决定缓存多久后重新采集 |
| 键前缀 | fact_caching_prefix，多个仓库共用一个后端时用来隔离 |
| 常用后端 | jsonfile（核心内置、可直接查看）、yaml 与 redis、memcached 等插件 |
| 刷新手段 | 对指定主机显式运行 setup，或等缓存过期 |
典型使用场景
- 同一批主机被多个 play 先后处理：第一次采集，后续 play 直接命中缓存
- 定时巡检：事实变化慢，缓存有效期设成巡检周期即可
- 临时排障：把后端设为文件，可以直接打开看某台机器上次采集到什么
- 多控制节点共享同一批目标机：用集中式后端让缓存相互可见
- 只需要少数几个事实字段的场景：先降采集范围，再叠加缓存
- 刚做完挂载或网卡变更：对相关主机显式重采，避免用过期的值做判断
配置与刷新
配置与刷新
# ansible.cfg
[defaults]
gathering = smart # 缓存命中则跳过采集
fact_caching = jsonfile # 结果落地为文件，便于人工检查
fact_caching_connection = /var/tmp/ansible_facts
fact_caching_prefix = prod_ # 多仓库共用时做命名隔离
fact_caching_timeout = 43200 # 秒：12 小时，按事实变化频率设定
# 集中式后端（需要相应集合与网络可达）
# fact_caching = community.general.redis
# fact_caching_connection = 127.0.0.1:6379:0
# 只重采部分事实（yaml 片段）
# - name: 刷新网络相关事实
# ansible.builtin.setup:
# gather_subset: ['!all', 'network']后端选型对照
| 后端 | 特点 | 适用 |
|---|---|---|
| jsonfile | 核心内置，按主机一个文件，肉眼可读 | 单控制节点、需要人工排查的场合 |
| yaml 类插件 | 同样是文件，格式更友好 | 偏好文本可读的小规模环境 |
| redis | 集中式、带过期时间，多控制节点共享 | CI 与控制节点分离的团队 |
| memcached | 集中式、纯内存 | 对持久化无要求、追求读取速度 |
| memory | 仅进程内有效 | 单次运行内的重复采集，重启即失效 |
缓存是快照而不是实时状态。缓存有效期应当匹配事实本身的变化节奏：内核、CPU、内存这类几乎不变的信息可以设长；挂载点、网卡地址可能因运维操作改变，最短的合理做法是对这类主机保留显式重采的任务。
打开缓存后，依赖 ansible_default_ipv4、ansible_mounts 等字段做判断的任务可能基于旧值决策。变更了网络或存储之后再跑这类任务，先刷新对应主机的缓存，否则判断结果与实际不符且不易察觉。
效果怎么量
同一批主机连跑两次同一 playbook，比较耗时差；再用显式采集的对照跑一次，三者对比就能看出事实采集到底占多少。占比高才值得引入缓存，占比低时缓存只会带来陈旧数据的风险与额外的排查成本。判断依据是数据，不是感觉。