小 T 导读
：常常有用户在 TDengine 的社区上递交标签为「help wanted」的问题。这些问题大都不是 Bug，只是由于不熟悉或者不了解 TDengine 的机制而让用户感到困惑的使用问题。咱们会按期分享一些具有共性的问题，但愿你们能从中有所收获。本期分享「实现 TDengine 客户端高可用的解决方法」。
原文首发于
TDengine 如何作到客户端高可用？
最近，在 TDengine 的开源社区上咱们遇到了两位集群用户，他们都提到了TDengine客户端高可用的问题：
用户共同的疑问说明了这个问题是颇有表明性的，因此咱们精选出来，但愿能够从用户的角度对产品的优化造成更多的思考。
咱们将这个问题细化一下就是「在 TDengine 客户端使用 taos -h FQDN -P port 链接集群的过程当中，若是客户端所在节点出现了宕机，本次链接是否是就会以失败而了结呢？」
答案显然是「是的」。
一位用户和咱们表示：TDengine服务端的高可用都作好了，客户端的高可用却没有跟上，实在是太惋惜了。
事实上，链接失败不假。但其实
TDengine 并不鼓励用户使用如上的方式链接集群
。为何这么说呢，咱们来给你们仔细梳理一下。
假设一个用户在链接 TDengine 集群时，他所链接的节点挂掉了。在这一刻，咱们会须要两种高可用：一是来自服务端，二是来自客户端。
服务端的高可用，指的是当 TDengine 的节点发生故障且超出规定时间无响应时，集群马上产生系统报警信息并踢掉损坏节点，同时触发自动的负载均衡，系统自动把该数据节点上的数据转移到其余数据节点。
而客户端的高可用，指的是 TDengine 在链接失败时当即指定其余可用的数据库服务端供客户端继续链接。
重点来了，TDengine 能实现这样的功能吗？
固然能够
。
下面就是咱们并不建议你们在 url 或者 taos 等链接方式中指定 FQDN，而是使用客户端配置文件 taos.cfg 去链接集群的真正缘由。后者，客户端会自动链接咱们配置好的参数 firstEP 节点，若是在链接瞬间这个节点挂掉了，则会继续链接参数 secondEP 所表明的节点。
值得注意的是，只要这两个节点有一个链接成功，客户端的使用就已经没有问题了。由于 firstEP 和 secondEP 只在链接的瞬间会被使用，它提供的并非完整服务列表，而是链接目标。只要在这短暂的零点几秒内集群链接成功，该节点就会自动获取管理节点的地址信息。而只在链接的这一瞬间，两个节点同时宕机掉的可能性是极低的。后续，即便 firstEP 和 secondEP 两个节点全都坏掉，只要集群能够对外服务的基本规则没有被打破，就仍然能够正常使用。这就是 TDengine 维护客户端高可用的方法。
固然，维护客户端高可用的方法不仅这一个。这两位用户均使用了 load balance 在外层包裹一层负载均衡。在这个过程当中，两我的又各自遇到了一样的问题。原来他们在作四层网络负载的时候，都只使用了 TCP 端口，链接都失败了。因而，GitHub 上才有了他们共同的疑问——
TDengine 究竟是如何实现客户端的高可用的
。
下面咱们分析一下，他们为何在作网络负载均衡时仍是会出现链接失败的问题。
TDengine 的官方文档上有一段内容能够解释上面的状况：考虑到物联网场景下，数据写入的包通常不大，所以除支持 TCP 链接以外，RPC 还支持 UDP 链接。当数据包小于 15KB 时，RPC 将采用 UDP 方式进行链接，不然将采用 TCP 链接。超过 15KB 的，或者是查询类的操做，采起 TCP 的方式进行传输。
这就是答案了，创建链接的数据包小于 15KB，走的是 UDP 的链接。
因此，当他们都加上 UDP 的转发规则以后都成功完成了集群外围的网络负载均衡。这样搭建的好处，除了能够一样完成客户端的高可用之外，还会使“开发”与“运维”的场景更加清晰，更加便于管理。
有趣的是，第一位解决问题的 yakir-Yang 在发现了另一个问题后还对第二位提问者 stringhuang 作了热心的解答。由于他刚刚经历过如出一辙的问题，一眼就看到了另外一位提问者的痛点。
因而互不认知的三方，便在这个开源社区里进行了一次和谐的技术互动。最终的结果是：提问者们在了解了 TDengine 的机制后，也成功地在这个新产品上搭建起了本身熟悉的高可用策略。
这也是咱们最乐于看到的场景
。
TDengine 客户端高可用的方法你学会了吗？
做者简介
：陈玉，曾在IBM任职数据库管理人员，有其余行业的自媒体创业经历。目前在涛思数据负责社区技术支持以及相关的运营工做。