Cassandra 3.11.9生产环境system_auth应选SimpleStrategy还是NetworkTopologyStrategy

1. 键空间策略选择 #

不管集群是单数据中心还是多数据中心，system_auth 键空间都优先推荐使用 NetworkTopologyStrategy，不建议使用 SimpleStrategy。
原因如下：

• SimpleStrategy 完全不感知机架/可用区（AZ）分布，仅按令牌环顺时针选择副本节点，哪怕集群配置了 EC2_snitch 也不会生效，很容易出现多个副本落在同一个 AWS AZ 的情况，一旦该 AZ 故障，整个集群的认证授权功能会直接失效。
• NetworkTopologyStrategy 可以配合 EC2_snitch 自动感知 AZ 分布，强制副本跨 AZ 放置，可用性更高，后续如果要扩容多数据中心也不需要修改策略，兼容性更好。

2. 副本因子（RF）配置建议 #

针对你当前单数据中心、2~3个 AWS AZ、绝大多数查询使用 local_one 一致性级别的场景：

• 如果你集群有3个节点分别分布在3个不同 AZ：RF 设置为3是最优选择，NetworkTopologyStrategy 会自动保证每个 AZ 存放1个副本，完全匹配 local_one 读取逻辑，不会产生跨 AZ 访问延迟。
• 如果你集群只有2个 AZ：RF 建议设置为2，每个 AZ 存放1个副本，避免单个 AZ 存放2个副本导致的可用性风险。
  注意：system_auth 的副本因子不能小于读一致性级别要求的副本数，你使用 local_one 的场景下 RF≥1即可满足基础要求，但为了高可用建议至少设置为2。

3. 当前查询延迟和配置的关联 #

你观测到的 Executing single-partition query on roles 延迟问题，和当前 system_auth 使用 SimpleStrategy 的配置有直接关系：

你当前使用 SimpleStrategy + RF=3 的配置，副本放置不感知 AZ 分布，极大概率出现2~3个 system_auth 副本落在同一个 AWS AZ 的情况。当请求落到没有本地副本的节点时，节点需要跨 AZ 拉取数据，就会产生额外的网络延迟。哪怕你调大了认证缓存参数，缓存失效后的第一次查询仍然会触发跨 AZ 读，所以会频繁观测到该步骤耗时较高。
再加上你关闭了 dynamic_snitch，节点不会自动优选最近的副本节点处理请求，进一步放大了副本放置不合理带来的延迟影响。

4. 修复方案 #

1. 执行 CQL 命令修改 system_auth 键空间策略，注意将命令中的 dc1 替换为你集群实际的数据中心名称（可通过 nodetool gossipinfo 查看节点的 DC 标签）：
   ALTER KEYSPACE system_auth WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'dc1' : 3};
2. 执行 nodetool repair system_auth 完成副本重分布，保证副本跨 AZ 放置。
3. 若调整后仍偶发延迟，可继续调大 roles_validity_in_ms 到2小时（7200000）及以上，只要集群没有频繁的角色/权限变更操作，该值设置较高不会带来负面问题。

内容的提问来源于stack exchange，提问作者evyatars