小 T 导读：常常有用户在 TDengine 的 GitHub 上递交标签为「help wanted」的 Issue。这些 Issue 大都不是 Bug，只是因为不相熟或者不理解 TDengine 的机制而让用户感到困惑的应用问题。咱们会定期分享一些具备共性的 Issue，心愿大家能从中有所播种。本期分享「实现 TDengine 客户端高可用的解决办法」。
原文首发于「GitHub 问题精选」TDengine 如何做到客户端高可用？
最近，在 TDengine 的 GitHub 上咱们遇到了两位集群用户，他们都提到了 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 客户端高可用的办法你学会了吗？如果大家在应用 TDengine 的过程中遇到任何问题，都能够到 GitHub 上递交你的 Issue，除了能失去官网的技术支持外，还能和不少气味相投的用户小伙伴交换哦～
https://github.com/taosdata/T…
作者简介 ：陈玉，曾在 IBM 任职数据库管理人员，有其余行业的自媒体守业经验。目前在涛思数据负责社区技术支持以及相干的经营工作。