小 T 导读
:经常有用户在 TDengine 的社区上递交标签为「help wanted」的问题。这些问题大都不是 Bug,只是因为不熟悉或者不了解 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 的机制后,也成功地在这个新产品上搭建起了自己熟悉的高可用策略。
作者简介
:陈玉,曾在IBM任职数据库管理人员,有其他行业的自媒体创业经历。目前在涛思数据负责社区技术支持以及相关的运营工作。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/6332.html