用户经常通过helpwanted标签向TDengine社区提出问题。其中大多数问题并不是bug，而是令用户困惑的使用问题，因为他们不熟悉或不了解TDengine的机制。在这里，我们将定期分享一些常见的问题，希望能有所收获。当前共享了实现TDengine客户机高可用性的解决方案。
用户普遍存在的疑问表明，该问题具有代表性，希望从用户的角度出发，优化产品。
当TDengine客户端使用taos-hFQDN-Pport连接群集时，该连接是否会在客户端所在的节点发生故障时以失败告终？
回答肯定是对的。
一位用户告诉我们：很遗憾，TDengine服务器端的高可用性做得很好，客户端的高可用性却跟不上。
事实上，连接故障并非真的。为什么要这么说，让我们来仔细梳理一下。
当用户连接到TDengine集群时，连接节点被断开。此时，我们需要两个高可用性：一个用于服务器，另一个用于客户端。
当TDengine的节点故障超过规定时间未响应时，集群立即生成系统报警信息，在将损坏的节点踢出的同时触发自动负载平衡，系统自动将节点上的数据转移到其他节点。
客户机的高可用性是指TDengine在连接失败后，为客户机继续连接立即指定其他可用的数据库服务器。
问题的关键在于TDengine是否能够实现。没问题。
这里有一个真正的原因，我们并不建议您在url或taos等连接方式中指定FQDN，而是使用客户机配置文件taos.cfg连接群。后者客户端会自动连接我们配置的参数firstEP节点，如果它在连接时挂起，那么secondEP代表的节点就会继续连接。
需要指出的是，只要两个节点之一连接成功，客户机的使用就没有问题。由于firstEP和secondEP只在连接时使用，因此它不提供完整的服务列表，而是提供连接目标。节点自动获得管理节点的地址信息，前提是集群连接在这段时间内成功。仅当连接时，两个节点同时停止的可能性是非常小的。
因此，即使firstEP和secondEP失败了，只要集群能够打破外部服务的基本规则，它们还是可以正常使用。TDengine通过这种方式来维护客户端的高可用性。
维护客户机高可用性的方法当然不止于此。两者均采用loadbalance在外层实现负载平衡。两个人在这一过程中遇到了相同的问题。原来他们做四层网络负载时，只使用TCP端口，连接失败。因此，在GitHub上有一个共同的问题——如何实现客户机的高可用性。
下一步，我们将分析为什么在平衡网络负载时，他们仍然存在连接故障。
TDengine的官方文件中有一段解释了上述情况：在物联网场景中，数据包的写入通常很小，因此RPC除了支持TCP连接之外，还支持UDP连接。若报文小于15KB，则RPC采用UDP连接，否则采用TCP连接。查询类操作超过15KB，以TCP方式传输。
解决方法是，建立小于15KB的数据包使用UDP连接。
所以，当它们都加入UDP转发规则时，就能成功实现集群周围网络的负载均衡。除了能够同样实现客户机的高可用性之外，该构建还可以使开发和操作的场景更加清晰，更加易于管理。
有趣的是，第一个解决问题的yakir-Yang在发现了另一个问题后，同样对第二个提问者stringhuang充满了热情。因为他刚经历过同样的问题，所以他一眼就看出了对方的痛处。
所以，没有认知的三方在这个开放源码社区中和谐地进行技术交流。最后，提问者在了解TDengine的工作原理后，成功地为这款新产品开发出他们所熟悉的高可用策略。
