是否需要 LB 优先于 Cassandra C# 驱动程序中的内置策略？ [关闭]

Posted 2023-02-16

【中文标题】是否需要 LB 优先于 Cassandra C# 驱动程序中的内置策略？ [关闭]

【英文标题】：Is there a need for a LB in preference for the built-in policies in Cassandra C# driver? [closed]

【发布时间】：2021-11-23 17:00:49

【问题描述】：

我有一个 Ldap 服务器，它为我的每个 api 实例提供访问密钥和端点。我需要灵活，目标是能够在不停机的情况下更改数据库集群。

我的第一个想法是在 cassandra 集群前面放置一个 LB，但我想我会失去驱动程序所做的优化（我猜我真的不知道我是 Cassandra 的新手）所以我只是给启动与 LB 端点对应的 API 时的一个 ContactPoint。当我需要提高吞吐量时，我只需在 LB 后面弹出额外的节点，它会通过持续的健康检查来管理拥塞。它可能会增加延迟，但通过我的内部 DNS，我可以更改端点 IP（我不知道驱动程序会经常执行 DNS 查询，或者当 ContactPoint 不可用时是否会执行此操作）并在 LB 崩溃时保持服务正常运行或其他。

现在，如果它影响性能，我可以将我的所有 Cassandra 节点添加到 ContactPoints 并让驱动程序发挥他的作用。问题是我每次更改 Cassandra 集群时都需要更改 ContactPoints，而且我不知道是否可以在不重新启动 Api 服务的情况下做到这一点，这意味着对我的所有 Api 实例进行手动干预。也许我可以更改它们并且单例添加一些 rw mutex 块所有读取器更改列表，重新连接到每个节点并让读取器返回访问权限。也许吧，但我不这么认为......我更喜欢使用 LB，但如果他们是这里的一些 Cassandra 专家或 Datastax 开发人员！

是否需要 LB 优先于 Cassandra C# 驱动程序中的内置策略？

【参考方案1】：

不建议使用硬件或软件负载平衡器和/或虚拟 IP (VIP)。

正如您已经说过的，Cassandra 驱动程序使用内置的负载平衡策略，并且了解集群拓扑以及节点的运行状况。当您在集群前面放置负载均衡器或 VIP 时，驱动程序将失去智能路由请求的能力。

例如，如果您使用 Java 驱动程序，默认情况下，驱动程序使用负载平衡策略，将查询路由到本地数据中心，并使用令牌感知策略将请求路由到拥有正在查询的数据。

驱动程序知道集群中的节点，因为它连接到接触点（节点 IP 地址列表）以在启动时建立控制连接。驱动程序使用控制连接来执行包括查询系统表以了解集群拓扑的任务。使用控制连接，驱动程序还可以自动监听集群的变化，以便实时了解节点添加、节点中断、新数据中心和停用等情况。

由于这些原因，不建议使用外部负载平衡器或 DNS 虚拟 IP，因为它会影响驱动程序以最佳方式运行的能力。

如果您有兴趣，请查看 Control connection 和 Load balancing 上的 Java 驱动程序文档。干杯！

【讨论】：

非常感谢您的宝贵时间！好的，我只需要定义一种“主”节点，当我执行 Cassandra.Builder 时，我将使用它作为集群的入口点，然后它将选择拓扑。 .net 核心驱动程序和 java 驱动程序（spring boot，micronaut ...我猜）之间的支持有什么不同吗？

FWIW 使用“master”或“primary/secondary”不适用于 C*——所有节点都相同，没有单点故障。大多数开发人员在种子列表中使用相同的节点作为接触点——在本地 DC 中选择至少 2 个节点。不，C# 驱动程序以相同的方式工作。干杯！