小 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任職數據庫管理人員，有其餘行業的自媒體創業經歷。目前在濤思數據負責社區技術支持以及相關的運營工做。