publishing the cluster state
master节点负责变更集群状态信息，一次变更多个操作（batch），发布到所有节点。
发布过程
- master 发布新的集群状态信息到所有节点。
- 所有节点回复 acknowledgement ，但不应用。
- master 收到大多数 master-eligible 的 acknowledgement后，意味着集群状态信息提交成功（committed）。
- master发布 应用集群信息 的消息。
- 所有节点 应用 集群信息，并再次回复 acknowledgement。
上述过程，从第一步开始，到第五步，必须在 30s 内完成。这由参数 cluster.publish.timeout 控制，默认30s 。
如果30s后，集群状态还未完成committed（第三步），则集群状态信息会被拒绝，master节点认为自己失败（failed），让出master角色，开始选举新master。
如果30s内，集群状态完成committed，master节点认为变更成功。master会发布"应用"消息，继续等待所有节点的再次 acknowledgement 或 timeout（30s）。
如果有节点 timeout，它会被master认为是 lagging（滞后）的。master 继续等待 lagging 节点的第二个acknowledgement，等待时间由参数 cluster.follower_lag.timeout 控制，默认90s 。如果90s还没收到，lagging 节点会被认为 failed，被master移除集群。
集群状态一般都基于previous集群状态信息进行增量更新，如果有节点没有previous集群状态信息，master会给它推送全量的集群状态信息。
cluster fault detection
- follower checks：master 定期检查其他节点，确定他们都是连接的，健康的。
- leader checks：其他节点 定期检查 master，确定它是健康的。
上述checks，可偶尔失败、timeout。如果连续失败，则节点会被认为 faulty 。非master节点faulty，master将其remove出集群。master节点faulty，执行检测的节点启动discovery流程，寻找或选举新master。连续次数，通过参数
- cluster.fault_detection.leader_check.retry_count: 3
- cluster.fault_detection.follower_check.retry_count: 3
如果master检测到节点断开连接，该情况被认为 immediate failure，忽略timeout、retry设置，直接remove该节点。
如果节点检测到master断开连接，该情况被认为 immediate failure，忽略timeout、retry设置，直接启动discovery流程，寻找或选举新master。
discovery and cluster formation settings
expert settings
cluster.election.duration
每次选举的时间，超过该时间后，认为选举失败，重新选举。默认500ms。
cluster.follower_lag.timeout
master等待lagging节点第二次acknowledgement的时间，默认90s
cluster.join.timeout
节点发送 join cluster请求后，等待的时间，超过后它认为请求失败，重发。默认60s
cluster.publish.timeout
master节点等待其他节点应用集群信息，并返回第二次acknowledgement的时间，默认30s
总结
- 网络连接检查、健康检查：持续30s 失败，faulty。
- 断开连接：立马 faulty。
- 非master节点应用集群状态信息：30s timeout 后变 lagging，120s（30+90） 后被 remove 出集群
- master发布集群状态：30s 未 committed，自动放弃master，重新选举
