小 T 導讀：經常有用戶在 TDengine 的 上遞交標簽為「help wanted」的 Issue。這些 Issue 大都不是 Bug，只是因為不熟悉或者不了解 TDengine 的機制而讓用戶感到困惑的使用問題。我們會定期分享一些具備共性的 Issue，希望大家能從中有所收獲。本期分享「實現 TDengine 客戶端高可用的解決方法」。
最近，在 TDengine Database 的 GitHub 上我們遇到了兩位集群用戶，他們都提到了TDengine客戶端高可用的問題：
用戶共同的疑問說明了這個問題是很有代表性的，所以我們精選出來，希望可以從用戶的角度對產品的優化形成更多的思考。
我們將這個問題細化一下就是「在 TDengine 客戶端使用 taos -h FQDN -P port 連接集群的過程中，如果客戶端所在節點出現了宕機，本次連接是不是就會以失敗而告終呢？」
答案顯然是「是的」。
一位用戶和我們表示：TDengine 服務端的高可用都做好了，客戶端的高可用卻沒有跟上，實在是太可惜了。
事實上，連接失敗不假。但其實 TDengine 并不鼓勵用戶使用如上的方式連接集群。為什么這么說呢，我們來給大家仔細梳理一下。
假設一個用戶在連接 TDengine Database 集群時，他所連接的節點掛掉了。在這一刻，我們會需要兩種高可用：一是來自服務端，二是來自客戶端。
服務端的高可用，指的是當 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 Database 的過程中遇到任何問題，都可以到 GitHub 上遞交你的 Issue，除了能得到官方的技術支持外，還能和不少志同道合的用戶小伙伴交流哦～
作者簡介：陳玉，曾在IBM任職數據庫管理人員，有其他行業的自媒體創業經歷。目前在濤思數據負責社區技術支持以及相關的運營工作。
