使用 nodejs 在 Cassandra 中重试策略答案

【问题标题】：Retry policies in Cassandra using nodejs使用 nodejs 在 Cassandra 中重试策略
【发布时间】：2018-06-20 11:40:32
【问题描述】：

我终于在nodejs中为Cassandra编写了一个重试策略，我有一个用例，每当有一个节点副本可用时，我需要通过修改我的一致性来允许读写最低水平。

我已附上我更新的重试代码（retry.js 中的 DowngradeRetryPolicy），请您检查链接并提供您的 cmets，

1) 我希望在使用此重试策略时遇到问题列表？
2）这段代码有什么问题吗？我需要做出改变来处理极端情况吗？

【问题讨论】：

【解决方案1】：

使用降级一致性重试策略会使您的应用程序一致性保证处于最低水平。第一次使用较低的一致性级别在理论上是等效的。

我个人认为这种类型的策略没有多大用处，除非在您处理应用程序的“正常模式”和“降级模式”的情况下。

关于代码，我觉得不错。

【讨论】：

我使用降级重试策略的原因：我有两个节点安装的依赖（RF =2，Write Consistency =2，Read Consistency =2），如果节点故障，我需要支持读写。
所以告诉我一件事，如果我有一个节点故障，那么使用降级策略我将能够使用一个 cassandra 节点执行写入和读取，然后在启动第二个节点后，将它会自动将写入第一个节点的所有数据（在故障期间）复制到第二个节点（我们现在购买了）？还是我们需要进行节点修复？
嘿@jorgebg，你能告诉我吗？
这取决于该节点的停机时间 - 当节点不可用时，协调节点将存储“提示”，当节点返回时可以重播（提示切换）。但是这些提示的存储时间是有限制的。有关详细信息，请参阅docs.datastax.com/en/cassandra/3.0/cassandra/operations/…。如果节点宕机时间过长，则需要进行修复。

【解决方案2】：

问题...根据docs，策略接口由四个方法组成：

onReadTimeout、onUnavailable、onWriteTimeout 和 onRequestError

在您的政策中，我只看到 3。如果有遗漏，会发生什么？是否使用默认逻辑？

【讨论】：

我想我有答案了...util.inherits(MyRetryPolicy, cassandra.policies.retry.RetryPolicy); 表示继承默认策略:)。干得好，谢谢！