構建代理中心

Question

首先，我收集有關此問題的信息，以便我可以以更優雅的方式實現此功能。

讓我們來看看下面的圖片

目標服務器（綠圈）

這是我用它來獲取一些數據的API服務器。

特點：

• 只有https連接JSON格式
• 響應。
• 可以接受get這樣的請求[https://api.server.com/user=1&option&api_key=？ ]

代理控制器（藍色正方形）

它存儲代理的列表的簡單服務器;發送和接收一些數據;我想談談我將在其上運行的軟件。

特點：

• 代理列表
• API密鑰列表

我認爲這應該是一個hashmap如果我想擴展我的應用程序存儲IP =>標記列表或數據庫表。

工人

只需分析JSON響應和傳遞數據的分貝。

讓我們走近代理服務器。

第一個想法：

• 創建newFixedThreadPoolExecutor
• 通網址/令牌工人：server.submit（新工人（URL，令牌，代理））
• 工人分析數據，並把它傳遞到db。

但在我看來，這個解決方案相當龐大且難以維護，我想要讓端點收集統計信息，殺死或產生新的工作人員等等。

第二個想法：

1. 工人產生像https://host/user=1&option=1
2. 它傳遞給代理控制器
3. 代理控制器指定給該請求的API密鑰和代理服務器
4. 執行請求的請求
5. 接受回覆
6. 將它傳回工人（我認爲最好的想法是在工作人員和代理控制器之間放置負載均衡器）。

這個解決方案對我來說似乎很拗口。例如，如果工作人員死了，代理服務器向死去的工作人員發送一堆請求，並可能導致數據丟失。

第三想法：

同爲第二但不是直接將數據發送到工人的代理控制器將它傳遞給局部總線。我找到了一些關於apache駱駝的信息，可以讓我組織這個解決方案。在這種情況下，死亡的工作人員是死的工人，dataloss等於零（也許）。

當然，這三種情況都不會處理錯誤。通過重新發送請求和其他數據可以解決一些錯誤。一些錯誤可以通過重新分配工人來解決。

因此，您認爲在這種情況下最好的解決方案是什麼？我錯過了稍後會出現的一些隱藏問題嗎？我應該使用哪些工具？

謝謝

Answer 1

什麼試圖達到？ 也許你可以考慮使用這種架構： NGINX（代理+負載平衡） - >工人服務器 - >數據庫服務器（可能使用一些NoSQL的像卡珊德拉）