尧图网站建设 
nats-server 如何用 feature_flags 在 JetStream 集群滚动升级时控制特性开关【免费下载链接】nats-serverHigh-Performance server for NATS.io, the cloud and edge native messaging system.项目地址: https://gitcode.com/GitHub_Trending/na/nats-server在 JetStream 集群做滚动升级时有一类行为变化不是靠升级命令本身触发的而是由服务内置的特性开关feature flag决定。nats-server 在 feature_flags.go 中定义了三个当前生效的开关开关名当前默认值源文档中的版本说明js_ack_fc_v2false2.14.0 引入v1/v2 格式都支持当前默认仍用 v1何时改为 v2 默认TBD尚未确定js_raft_delete_rangetrue2.14.0 引入2.15.0 起默认开启要求升级时所有服务器都在 2.14.0 以上计划 2.16.0 移除js_snapshot_sourcesfalse2.15.0 引入两种编码都接受当前只发出 v1何时默认开启TBD尚未确定其中两个开关的源注释给出了明确的集群一致性警告js_raft_delete_range只在集群中每个 peer 都是支持接收deleteRangeOp的版本时才启用旧版本 peer 在 apply 未知 stream entry operation 时会 panic。js_snapshot_sources只在每个 peer 都接受 v2 编码时才启用旧版本 peer 会直接拒绝整个快照。所以滚动升级的任务是在每台节点的配置里显式声明要 opt-in 或 opt-out 的开关并能在启动后核对实际生效值确保新旧版本节点在同一个协议行为下完成滚动。在配置文件中声明 feature_flags开关通过服务器配置文件里的feature_flags块声明每个键的值必须是布尔值。opts.go 中case feature_flags分支负责解析键值不是 bool 时解析失败并返回配置错误feature_flags_test.go 给出了一个负例值写成字符串true时进程启动报错error parsing feature flag opt_in_flag: expected bool, got string因此配置值必须写裸布尔量。以在 2.15.0 节点上临时关掉头上的默认开关为例在对应节点的配置文件中加入feature_flags { js_raft_delete_range: false }生效规则同样由 feature_flags.go 定义用户在配置中给出的值优先于系统默认值getFeatureFlag。配置里写了代码不认识或该版本已移除的开关时getFeatureFlag一律返回false即视为未启用不会报错但会在启动日志里归入Unsupported一类见下文。启动后用日志核对生效值服务器启动时 server.go 会调用printFeatureFlags。注意它的第一个判断是只要配置中没有写任何feature_flags就不打印这一节。也就是说启动日志里出现 Feature flags 行本身就说明这台节点有用户配置。打印格式feature_flags.go如下下为按当前实现推导的示例输出Feature flags: Configured: js_raft_delete_range (opt-out)括号里的状态含义相对默认值为true的开关配false显示opt-out、配true显示enabled相对默认值为false的开关配true显示opt-in、配false显示disabled。写了不认识的键时多一行Unsupported: some_unknown_flag滚动升级期间逐台检查启动日志就能确认每台节点实际声明了哪些开关、方向是否正确。用 /varz 端点核对合并后的最终值启动日志只反映用户配置而运行时的真实行为取决于「默认值 用户配置」的合并结果。monitor.go 中Varz会把getMergedFeatureFlags()的完整合并结果写入/varz端点响应的feature_flags字段monitor.go 定义了该字段curl http://server:http_port/varz响应 JSON 中的feature_flags是包含全部已知开关的最终值未知键会被过滤掉getMergedFeatureFlags只保留内置表里的键。monitor_test.go 的TestMonitorVarzFeatureFlags验证的正是「默认值 用户覆盖值」的合并结果。对集群里每台节点请求一次/varz比较feature_flags字段即可确认所有节点在同一个行为组合上。另外events.go 中的 ServerInfoZ响应也携带feature_flags字段内容同样是合并后的结果可供连入的客户端侧核对。滚动升级时的版本边界以下内容逐条来自 feature_flags.go 的源注释是当前版本组合升级的依据js_raft_delete_rangeapply 侧从 2.14.0 起就支持接收deleteRangeOp所以升级目标是「所有服务器都在 2.14.0 以上」低于 2.14.0 的 peer 在 apply 未知 stream entry operation 时会 panic。该开关计划 2.16.0 移除届时配置里再声明它只会进入Unsupported列表。js_snapshot_sources默认关闭当前节点只发出 v1 编码的快照只有当集群所有 peer 都接受 v2 编码时才能开启否则旧 peer 会拒绝整个快照。js_ack_fc_v2默认关闭$JS.ACK.与$JS.FC.目前走 v1 格式v2 成为默认的时间源文档标记为TBD开启前需自行确认对端客户端/服务端的兼容性。限制与边界配置文件里声明的开关值必须是 bool否则配置解析失败、服务器无法启动错误信息见上文。写入不存在的开关不会导致启动失败但一律按「未启用」处理只体现在启动日志的Unsupported行和/varz端点会将其过滤掉。源注释中的「何时启用 v2」「何时移除」等时间点TBD、2.16.0属于当前代码的规划说明具体以目标升级版本的发布说明为准。完成核对后的落点是集群内每个节点的/varz返回相同的feature_flags合并值且每台节点启动日志的Configured行与预期方向一致——满足这两点滚动升级期间各节点才处于同一组协议行为下。【免费下载链接】nats-serverHigh-Performance server for NATS.io, the cloud and edge native messaging system.项目地址: https://gitcode.com/GitHub_Trending/na/nats-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 nats-server 如何用 feature_flags 在 JetStream 集群滚动升级时控制特性开关
nats-server 如何用 feature_flags 在 JetStream 集群滚动升级时控制特性开关【免费下载链接】nats-serverHigh-Performance server for NATS.io, the cloud and edge native messaging system.项目地址: https://gitcode.com/GitHub_Trending/na/nats-server在 JetStream 集群做滚动升级时有一类行为变化不是靠升级命令本身触发的而是由服务内置的特性开关feature flag决定。nats-server 在 feature_flags.go 中定义了三个当前生效的开关开关名当前默认值源文档中的版本说明js_ack_fc_v2false2.14.0 引入v1/v2 格式都支持当前默认仍用 v1何时改为 v2 默认TBD尚未确定js_raft_delete_rangetrue2.14.0 引入2.15.0 起默认开启要求升级时所有服务器都在 2.14.0 以上计划 2.16.0 移除js_snapshot_sourcesfalse2.15.0 引入两种编码都接受当前只发出 v1何时默认开启TBD尚未确定其中两个开关的源注释给出了明确的集群一致性警告js_raft_delete_range只在集群中每个 peer 都是支持接收deleteRangeOp的版本时才启用旧版本 peer 在 apply 未知 stream entry operation 时会 panic。js_snapshot_sources只在每个 peer 都接受 v2 编码时才启用旧版本 peer 会直接拒绝整个快照。所以滚动升级的任务是在每台节点的配置里显式声明要 opt-in 或 opt-out 的开关并能在启动后核对实际生效值确保新旧版本节点在同一个协议行为下完成滚动。在配置文件中声明 feature_flags开关通过服务器配置文件里的feature_flags块声明每个键的值必须是布尔值。opts.go 中case feature_flags分支负责解析键值不是 bool 时解析失败并返回配置错误feature_flags_test.go 给出了一个负例值写成字符串true时进程启动报错error parsing feature flag opt_in_flag: expected bool, got string因此配置值必须写裸布尔量。以在 2.15.0 节点上临时关掉头上的默认开关为例在对应节点的配置文件中加入feature_flags { js_raft_delete_range: false }生效规则同样由 feature_flags.go 定义用户在配置中给出的值优先于系统默认值getFeatureFlag。配置里写了代码不认识或该版本已移除的开关时getFeatureFlag一律返回false即视为未启用不会报错但会在启动日志里归入Unsupported一类见下文。启动后用日志核对生效值服务器启动时 server.go 会调用printFeatureFlags。注意它的第一个判断是只要配置中没有写任何feature_flags就不打印这一节。也就是说启动日志里出现 Feature flags 行本身就说明这台节点有用户配置。打印格式feature_flags.go如下下为按当前实现推导的示例输出Feature flags: Configured: js_raft_delete_range (opt-out)括号里的状态含义相对默认值为true的开关配false显示opt-out、配true显示enabled相对默认值为false的开关配true显示opt-in、配false显示disabled。写了不认识的键时多一行Unsupported: some_unknown_flag滚动升级期间逐台检查启动日志就能确认每台节点实际声明了哪些开关、方向是否正确。用 /varz 端点核对合并后的最终值启动日志只反映用户配置而运行时的真实行为取决于「默认值 用户配置」的合并结果。monitor.go 中Varz会把getMergedFeatureFlags()的完整合并结果写入/varz端点响应的feature_flags字段monitor.go 定义了该字段curl http://server:http_port/varz响应 JSON 中的feature_flags是包含全部已知开关的最终值未知键会被过滤掉getMergedFeatureFlags只保留内置表里的键。monitor_test.go 的TestMonitorVarzFeatureFlags验证的正是「默认值 用户覆盖值」的合并结果。对集群里每台节点请求一次/varz比较feature_flags字段即可确认所有节点在同一个行为组合上。另外events.go 中的 ServerInfoZ响应也携带feature_flags字段内容同样是合并后的结果可供连入的客户端侧核对。滚动升级时的版本边界以下内容逐条来自 feature_flags.go 的源注释是当前版本组合升级的依据js_raft_delete_rangeapply 侧从 2.14.0 起就支持接收deleteRangeOp所以升级目标是「所有服务器都在 2.14.0 以上」低于 2.14.0 的 peer 在 apply 未知 stream entry operation 时会 panic。该开关计划 2.16.0 移除届时配置里再声明它只会进入Unsupported列表。js_snapshot_sources默认关闭当前节点只发出 v1 编码的快照只有当集群所有 peer 都接受 v2 编码时才能开启否则旧 peer 会拒绝整个快照。js_ack_fc_v2默认关闭$JS.ACK.与$JS.FC.目前走 v1 格式v2 成为默认的时间源文档标记为TBD开启前需自行确认对端客户端/服务端的兼容性。限制与边界配置文件里声明的开关值必须是 bool否则配置解析失败、服务器无法启动错误信息见上文。写入不存在的开关不会导致启动失败但一律按「未启用」处理只体现在启动日志的Unsupported行和/varz端点会将其过滤掉。源注释中的「何时启用 v2」「何时移除」等时间点TBD、2.16.0属于当前代码的规划说明具体以目标升级版本的发布说明为准。完成核对后的落点是集群内每个节点的/varz返回相同的feature_flags合并值且每台节点启动日志的Configured行与预期方向一致——满足这两点滚动升级期间各节点才处于同一组协议行为下。【免费下载链接】nats-serverHigh-Performance server for NATS.io, the cloud and edge native messaging system.项目地址: https://gitcode.com/GitHub_Trending/na/nats-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考