要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间，以实现实时分析。点击[此处](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)了解更多信息。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 管理集群终端节点的 DNS 解析
<a name="timestream-for-influx-managing-dns"></a>

适用于 InfluxDB 3 多节点集群的 InfluxDB Timestream 使用基于 DNS 的流量分配来平衡节点间的连接。当发生故障转移或节点被替换时，DNS 记录会自动更新以指向可用实例。为了确保您的应用程序能够发现这些变化并保持最佳的流量分布，正确的 DNS 解析配置至关重要。

## 了解 DNS 缓存
<a name="timestream-for-influx-dns-caching-issue"></a>

许多编程环境都会缓存 DNS 查找以提高性能。但是，这种缓存可以防止您的应用程序在故障转移后发现更新的 IP 地址，也无法在多个群集节点之间分配连接。影响因语言和运行时间而异：
+ **基于 Java/JVM 的应用程序** — JVM 缓存 DNS 查找以获取可配置的 (TTL)。 time-to-live有些配置会无限期缓存，直到 JVM 重新启动。
+ **其他语言** — Python、Go、Node.js 和其他运行时通常依赖操作系统 DNS 解析，可能不会表现出相同的缓存行为。

## 解决方案 1：配置 JVM DNS TTL（Java 应用程序）
<a name="timestream-for-influx-jvm-ttl"></a>

**对于连接到 InfluxDB 3 集群终端节点的 InfluxDB Timestream 的 Java 应用程序，请将 JVM DNS 缓存 TTL 设置为零。**这样可以确保每个连接都会触发全新的 DNS 查找，从而实现适当的流量分配和即时故障转移检测。

检查您当前的 TTL 设置：

```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```

使用以下方法之一配置 TTL：
+ **全局配置**-设置`networkaddress.cache.ttl`在`$JAVA_HOME/jre/lib/security/java.security`：

  ```
  networkaddress.cache.ttl=0
  ```
+ **特定于应用程序的配置**-在建立网络连接之前，在应用程序初始化代码中设置该属性：

  ```
  java.security.Security.setProperty("networkaddress.cache.ttl", "0");
  ```
+ **JVM 参数** — 启动应用程序时作为系统属性传递：

  ```
  java -Dsun.net.inetaddr.ttl=0 -jar your-application.jar
  ```

**注意**  
对于非集群终端节点或常规 AWS 资源，60 秒的 TTL 通常就足够了。零 TTL 建议特定于 InfluxDB 3 集群端点，在这些端点中，流量分配和快速故障转移检测至关重要。

## 解决方案 2：通过权威域名服务器直接解析
<a name="timestream-for-influx-direct-resolution"></a>

如果 TTL 配置不足（例如，由于操作系统级缓存中间，或者您的编程语言不存在 DNS 缓存问题），则可以通过直接查询权威域名服务器来强制进行全新 DNS 解析。仅在标准 TTL 配置无法解决问题时才使用此方法。

**直接解析工作流程**

1. 确定您的集群终端节点的权威域名服务器：

   ```
   dig <cluster-endpoint> NS
   ```

   在输出中，请注意后面列出的域名服务器。`AUTHORITY SECTION` `IN SOA`例如：`ns-1458.awsdns-54.org`。

1. 直接查询权威域名服务器以绕过缓存：

   ```
   dig @ns-1458.awsdns-54.org <cluster-endpoint>
   ```

   这将返回端点的当前 IP 地址，反映基于 DNS 的实际流量分布。

1. 使用已解析的 IP 地址进行应用程序连接。定期或在出现连接错误时重复此解决方法以刷新地址。

**示例**：

```
# Find authoritative nameserver
dig my-cluster.timestream-influxdb.us-east-1.amazonaws.com NS

# Resolve using authoritative nameserver
dig @ns-1458.awsdns-54.org my-cluster.timestream-influxdb.us-east-1.amazonaws.com

# Use returned IP addresses in your application
```

## 处理节点 IP 变更
<a name="timestream-for-influx-handling-ip-changes"></a>

**重要**  
节点 IP 地址**不是静态**的。它们在故障转移、节点重启、维护操作和集群扩展期间会发生变化。切勿无限期缓存已解析的 IP 地址。

实施以下做法来处理 IP 变更：
+ **定期重新**解析-使用后台任务每 30-60 秒重新解析端点。将新 IP 地址与缓存值进行比较，并相应地更新您的连接池。
+ **错误驱动的重新解决**-当连接失败（超时、连接被拒绝、重置）时，请立即重新解析端点并使用更新后的 IP 地址重试。
+ **正常连接耗尽** — 当 IP 地址不再在 DNS 记录集中时，允许进行中的请求完成，但停止创建与该 IP 的新连接。
+ **创建新连接**-重新解析后，使用更新的 IP 地址创建新连接。固定到旧连接的现有连接 IPs 不会从重新解析中受益。

## 最佳实践
<a name="timestream-for-influx-dns-best-practices"></a>
+ 从 **TTL 配置开始** — 对于 Java 应用程序，请务必`networkaddress.cache.ttl=0`先尝试进行设置。这是最简单、最有效的解决方案。
+ **谨慎使用直接解析** — 仅在 TTL 配置不足或处理持久中间缓存时才使用权威域名服务器查询。
+ **自动发现域名服务器——不要对域名服务器**地址进行硬编码。动态发现它们，因为域名服务器分配可能会发生变化。
+ **仅适用于集群终端节点**-这些技术适用于使用基于 DNS 的分发的集群级终端节点（写入和读取）。直接针对单个节点的特定于节点的端点不需要此配置。
+ **测试您的实现**-验证您的应用程序是否正确地将连接分配到多个节点上，并从模拟的节点故障中恢复。