我使用亞馬遜路由53將DNS請求路由到負載均衡器。爲了負載平衡，我使用ha-proxy負載均衡器路由53將請求路由到ha-proxy。亞馬遜路由53與ha-proxy
在路由53中，我給了三個負載平衡器一個權重33.33％。假設客戶端請求路由53時，將請求路由到第一個ha-proxy服務器並建立tcp連接。
所以問題是什麼時候客戶端發出第二個請求去哪裏？是否有可能第二個請求轉到已建立tcp連接的第一臺服務器？
有一個在給定的圖像三個服務器和也有路由-53客戶端作出的請求來加權的使用HA代理路由-53 DNS。
下一個請求去的地方沒有明確定義。如果你在DNS響應中設置了一個短的TTL，那麼確保比你期望的要小，因爲客戶可能會忽略或不能訪問TTL信息。
但是，您仍然需要較短的TTL，以便客戶端不會遇到無法使用代理的A記錄。
以33.3％加權你的DNS可能不是最好的計劃。您可以使用每個DNS響應返回所有健康代理的IP地址 - 無需平衡每個代理的請求數量。
讓我驗證我對設置的理解。假設這是正確的，這裏的答案的其餘部分應該是適用的。
場景：
您有多個HAProxy的服務器，模式TCP，終止TLS和平衡使用leastconn請求到後端服務器，以便用最少連接數後端服務器將接收下一個呼入連接。
分析：
你想要的東西在後臺平衡，所以你不需要的重量在前面側的DNS響應正確，使這項工作。你真正需要做的就是健康檢查代理服務器，如果代理服務器的IP地址不健康，請不要公佈代理服務器的IP地址。否則，請用每個DNS響應返回所有代理地址。
理由：
不要緊其代理客戶端連接到。返回所有地址將以隨機順序返回它們，客戶端將隨意使用一個地址。
每個代理都保留自己對每個後端連接數量的計數，並始終將連接發送到哪個後端從其視角的最小連接。它不需要知道其他代理所持有的連接數，因爲每個代理都獨立地確保將相同數量的連接發送到每個後端服務器。因此，在需求高峯期，每個代理髮送給每個後端的連接數量在每個代理中都是相同的，+/- 1，並且相同的代理僅受DNS的隨機性影響......並且前端的不平衡會自行消除，因爲如果一個IP地址接收到的流量比其他流量多，那隻意味着連接到的連接數量，該代理的所有後端都高於其他端口的數量，但是無論這個數字是多少，它在峯值負載時仍然是+/- 1，並且在高峯負載下的分佈應該是您唯一真正關心的問題。
隨着越來越多的客戶斷開連接而不是連接，您將離開一段時間的峯值需求（按照定義），並且連接數量往往會變得不那麼平衡，但這也不重要，因爲代理將會在新連接到達時再次將其恢復到原來的水平 - 它們會自動從服務器角度給予服務器的連接數最少，並且我們已經假定在這一點上您沒有處於高峯需求，所以精確度平衡變得不那麼重要。在非峯值期間傳遞到任何一臺後端服務器的併發連接數量將不會超過在此配置達到峯值期間交付給服務器的連接數量。
請描述你想要的行爲，並解釋爲什麼這種行爲是可取的。 HAProxies在哪裏？他們在EC2嗎？如果是這樣，他們是否在同一個AWS區域？你在平衡哪些服務？ HTTP/HTTPS？ WebSockets的？還有別的嗎？ –
@ Michael-sqlbot鑑於Haproxy節點託管在AWS EC2實例上，並且AWS Route 53根據賦予AWS Route 53上每個haproxy節點的權重，將TLS請求路由到這些Haproxy節點（託管在EC2實例上），以平衡負載到Haproxy節點。因爲這基本上是用於聊天應用程序，其中Haproxy節點基於least_conn策略將TLS請求傳輸到後端聊天服務器（在AWS ELB中不可用）。在應用程序中，我們不知道將有多少用戶在那裏。因此，需要根據其內存使用情況將請求路由到Haproxy節點，並動態更改Route 53中每個服務器的權重。 – patel