处理主机更换和连接失速问题

当 Neptune 更换主机时（例如，在维护或故障转移期间），与该主机的现有连接将失效。在容器化环境中，如果客户端不能优雅地处理替换，这可能会使容器中的所有线程停滞不前。

使用当前的客户端版本

如果您使用 Gremlin 查询语言，请使用与 Neptune 引擎版本兼容的 TinkerPop 驱动程序版本（参见兼容性使用 Gremlin 访问 Neptune 图形表）。如果您使用 Java 驱动程序，请考虑neptune-gremlin-client使用 J TinkerPop ava 驱动程序的包装，它添加了连接管理功能，例如端点运行状况检查和故障转移处理。它遵循与底层 TinkerPop 驱动程序相同的版本兼容性规则。

使用 3.x neptune-gremlin-client 版本（或最低版本 2.0.7），具体取决于您的 Neptune 版本允许的内容。这些较新的版本提高了弹性和连接处理能力。

对于使用 Neo4j 驱动程序的 OpenCypher 用户，请在故障转移期间检测到连接故障时关闭并重新创建Driver对象。Neptune 支持 Bolt 协议版本 1 到 4.0。有关更多信息，请参阅 使用 openCypher 和 Bolt 的 Neptune 最佳实践。

使用集群或读取器终端节点

不要直接连接到实例终端节点。使用集群终端节点进行写入，使用读取器终端节点进行读取。如果您必须将实例终端节点与一起使用neptune-gremlin-client，请通过 /status API 启用终端节点运行状况检查筛选。

配置带容差的存活探针

将你的 Kubernetes 活跃度探测设置failureThreshold为至少 30，周期为 10 秒（总计 300 秒）。这可以防止 Kubernetes 在大约 5 分钟的时间段内在 Neptune 完成主机更换时重启 Pod。

使用退避实现重试

主机更换期间单个失败的请求不应使容器崩溃。在连接失败时实现带有指数退避的重试逻辑，这样替换期间的暂时错误就可以在没有干预的情况下得到解决。有关可重试异常的指导，请参阅 Nept un e 交易异常。