京公网安备11010502063487号本机真实对比translog.durability=request(默认，每次等fsync落盘)写2000条耗时10.305秒，async(每5秒批量fsync)同样2000条只要0.529秒，快约19.5倍。request模式真实保证写入成功即落盘(第96篇kill -9实验正是在此模式下验证)，async模式真实在崩溃窗口内可能丢失最近几秒数据，这是吞吐与数据安全边界的真实权衡。
本机真实脚本update(counter+=1)验证_version/_seq_no都递增，证明底层是读-改-写整篇重写而非原地修改。真实20个并发update默认retry_on_conflict=0时只有1个成功19个冲突失败；调到5后成功数涨到8个但仍有12个重试耗尽后失败——证明retry_on_conflict只能缓解不能消除高并发竞争失败。
本机真实索引文档拿到_seq_no=0，带这个值写入真实成功，seq_no前进到1。用已经过期的seq_no=0再写，真实直接409报错，错误信息精确回显'required seqNo[0]...current has seqNo[1]'——证明乐观并发控制真实靠比较版本标识的compare-and-swap机制，而非加锁。
本机真实只传if_seq_no不传if_primary_term，真实400报错两者必须成对出现；反过来只传if_primary_term同样400报错。真实又验证正确seq_no=0配瞎编的primary_term=99，依然409失败文档完全没被改动——证明两个值真实是各自独立被精确检查的复合条件，不存在seq_no对了就放行的宽松逻辑。
本机真实用20线程手工实现读-算-写CAS逻辑，不重试时真实只有1个成功19个放弃。加上遇冲突就重读重试(最多10次)的循环后，成功数真实涨到17个，但仍有3个尝试10次后真实放弃——证明客户端重试能大幅缓解但不能消除高并发版本冲突失败，跟第103篇update的retry_on_conflict现象一致。
本机真实发现write线程池queue_size不支持动态修改，报错'not dynamically updateable'需改配置重启。真实改成size=1/queue_size=2重启后，30个并发写入真实只有2个成功，28个429拒绝(es_rejected_execution_exception)，错误信息精确嵌着线程池实时状态——这是写入过载时真实的保护机制，应降速或退避重试而非丢弃数据。
本机真实查到indexing_pressure内存上限107374182字节，精确等于1GB堆的10%。真实构造6个约29.4MB的大bulk并发请求，只有3个成功3个被拒绝，错误信息精确嵌着内存记账(93.3MB已占用+31.1MB新请求超过107MB上限)。这是按字节数限制的独立保护机制，跟上一篇按数量限制的线程池队列拒绝互补运作。
本机真实用150MB单条文档直接413被拒绝，撞上http.max_content_length默认100mb上限。50MB文档(低于上限)成功写入但耗时明显更长。真实测keyword字段值32766字节成功、32767字节(多1字节)整条写入直接失败——Lucene硬编码单个term最大32766字节，错误信息'all were skipped'容易误导，实际是整条请求失败而非静默截断。
本机真实观察cluster state version：创建索引让version从708跳到711(一次跳3，证明内部多次独立状态更新)。集群稳定后连续写两条文档，version真实一次都没变——纠正了之前看似由文档写入引起的+1变化(实为分片分配收尾巧合)，证明纯数据写入从不触碰cluster state。改集群设置version精确加1。
本机真实查到单节点node.role='cdfhilmrstw'身兼全部角色。真实配置ingest pipeline验证写入时自动加工文档，多出两个新字段。真实用_simulate预览转换效果不会真写入索引。真实故意写缺字段的文档触发脚本处理器报错，整条写入真实被完整拒绝而非静默跳过这一步。
本机真实另起独立ES进程，不设discovery.type/cluster.initial_master_nodes，用multi-node模式启动：进程不崩溃但真实永远卡住，日志写着'has not joined a bootstrapped cluster yet'，HTTP端口始终连接失败(000)。加上cluster.initial_master_nodes重启后，真实8秒内成功组成单节点集群达到green——该设置只在首次引导时生效，避免脑裂风险。
本机真实把唯一master候选节点加进voting_config_exclusions，API真实超时('timed out waiting for voting config exclusions to take effect')，但排除记录已写入cluster state，集群依然green。清空排除同样超时，报错精确提示wait_for_removal=false，加上后立刻清空成功——证明该机制等待节点真正离开确认而非立即生效，超时不等于失败。