# Poppen.de 建筑 > 原文： [http://highscalability.com/blog/2010/4/12/poppende-architecture.html](http://highscalability.com/blog/2010/4/12/poppende-architecture.html) 這是 Alvaro Videla 的來賓，他描述了 [Poppen.de](http://www.poppen.de/) 這個流行的德國約會網站的架構。 該站點非常類似于 NSFW，因此在單擊鏈接之前請多加注意。 我發現最有趣的是，他們如何使用 Nginx，MySQL，CouchDB 和 Erlang，Memcached，RabbitMQ，PHP，Graphite，Red5 和 Tung 等技術，成功地將一些舊代碼與一些新代碼成功融合。 ## 什么是 Poppen.de？ Poppen.de（NSFW）是德國最熱門的約會網站，盡管與 Flickr 或 Facebook 這樣的巨頭相比，它可能是一個很小的網站，但如果您開始遇到一些擴展問題，我們認為這是一個不錯的架構。 ## 統計資料 * 2.000.000 用戶 * 20.000 個并發用戶 * 每天 300.000 條私人消息 * 每天 250.000 次登錄 * 我們有一個由 11 個開發人員，2 個設計師和 2 個 sysadmin 組成的項目團隊。 ## 商業模式 該網站使用免費增值模式，用戶可以免費執行以下操作： * 搜索其他用戶。 * 互相寫私信。 * 上傳圖片和視頻。 * 有朋友 * 視頻聊天。 * 多得多… 如果他們想發送無限制的消息或上傳無限制的圖片，則可以根據需要為不同類型的成員付費。 視頻聊天和網站的其他部分也是如此。 ## 工具箱 ### Nginx 的 我們所有的網站都通過 Nginx 提供服務。 我們有 2 臺 Nginx 前端服務器，在高峰時間每分鐘向 www.poppen.de 發送 150.000 個請求。 它們是使用四年的計算機，每個計算機只有一個 CPU 和 3GB RAM。 然后，我們有單獨的機器來提供站點圖像。 每分鐘由 3 個 nginx 服務器處理* .bilder.poppen.de（圖像服務器）有 80.000 個請求。 Nginx 讓我們做的很酷的事情之一就是從 Memcached 發出很多請求，而無需點擊 PHP 機器來獲取已經緩存的內容。 因此，例如，用戶配置文件是站點中 CPU 占用最大的頁面之一。 請求配置文件后，我們會將全部內容緩存在 Memcached 上。 然后 Nginx 服務器將命中 Memcached 并從那里傳遞內容。 每分鐘有 8000 個請求從 Memcached 發送出去。 我們有 3 個 Nginx 服務器正在從本地緩存中傳遞圖像。 用戶將他們的圖片上傳到中央文件服務器。 圖片請求將命中 3 臺 Nginx 服務器之一。 如果圖片不在本地緩存文件系統中，則 Nginx 將從中央服務器下載圖片，將其存儲在本地緩存中并提供服務。 這使我們可以負載均衡圖像分布并減輕主存儲機中的負載。 ### PHP-FPM 該站點在 PHP-FPM 上運行。 我們使用 28 臺 PHP 機器，每個機器具有兩個 CPU 和 6GB 的內存。 他們每個運行 100 個 PHP-FPM 工作進程。 我們使用啟用 APC 的 PHP5.3.x。 PHP 5.3 版本使我們可以減少 30％以上的 CPU 和內存使用率。 該代碼是使用 symfony 1.2 PHP 框架編寫的。 一方面，這意味著額外的資源占用，另一方面，它使我們可以加快開發速度，并擁有眾所周知的框架，可以使我們輕松地將新開發人員集成到團隊中。 這里并不是所有的東西都是“花和玫瑰”。 因此，盡管我們擁有該框架提供的許多優勢，但我們還是不得不對其進行大量調整，以使其達到服務于 www.poppen.de 的任務。 我們所做的就是使用 XHProf（Facebook 的 PHP 概要分析庫）對站點進行概要分析，然后優化瓶頸。 由于該框架易于自定義和配置，因此我們能夠緩存大多數昂貴的計算，這些計算給 APC 中的服務器增加了額外的負載。 ### 的 MySQL MySQL 是我們的主要 RDBMS。 我們有幾臺 MySQL 服務器：一臺 32GB 的機器，帶有 4 個 CPU，用于存儲所有與用戶有關的信息，例如個人資料，圖片元數據等。該機器已有 4 年的歷史。 我們計劃將其替換為分片群集。 我們仍在設計此系統，以盡量減少對我們的數據訪問代碼的影響。 我們希望按用戶 ID 對數據進行分區，因為網站上的大多數信息都以用戶本身為中心，例如圖像，視頻，消息等。 我們有 3 臺機器在用戶論壇的主從配置中工作。 然后有一個服務器群集，用作網站自定義消息系統的存儲。 目前，它有超過 2.5 億條消息。 它們是在主從站主/從站從站系統中配置的 4 臺機器。 我們還有一個由 4 臺計算機組成的 NDB 集群，用于寫入大量數據，例如哪個用戶訪問了哪個其他用戶的個人資料的統計信息。 我們嘗試盡可能避免像瘟疫這樣的聯接并緩存。 數據結構被高度非規范化。 為此，我們創建了摘要表，以簡化搜索。 大多數表都是 MyISAM，可提供快速查找。 我們看到越來越多的問題是全表鎖。 我們正在轉向 XtraDB 存儲引擎。 ### 記憶快取 我們大量使用 Memcached。 我們有超過 51 個節點的 45 GB 緩存。 我們將其用于會話存儲，視圖緩存（如用戶配置文件）和函數執行緩存（如查詢）等。我們對用戶表擁有的大多數按主鍵進行的查詢都緩存在 Memcached 中，然后從那里傳遞 。 我們擁有一個系統，該系統可在每次修改該表的一條記錄時自動使緩存無效。 將來改善緩存失效的一種可能解決方案是使用新的 Redis Hash API 或 MongoDB。 使用這些數據庫，我們可以以足夠的粒度更新緩存，而無需使其無效。 ### 兔子 MQ 自 2009 年中以來，我們將 RabbitMQ 引入了我們的堆棧。 這是一個易于部署并與我們的系統集成的解決方案。 我們在 LVS 后面運行兩個 RabbitMQ 服務器。 在上個月，我們一直在將越來越多的東西移到隊列中，這意味著目前 28 臺 PHP 前端計算機每天大約發布 50 萬個作業。 我們向隊列發送日志，電子郵件通知，系統消息，圖像上傳等等。 為了使消息入隊，我們使用了 PHP-FPM 提供的最酷的功能之一，即 fastcgi_finish_request（）函數。 這使我們能夠以異步方式將消息發送到隊列。 在生成必須發送給用戶的 HTML 或 JSON 響應后，我們將調用該函數，這意味著用戶不必等待我們的 PHP 腳本清理完畢，例如關閉 Memcached 連接，DB 連接等。 同時，所有保存在內存數組中的消息都將發送到 RabbitMQ。 這樣，用戶也不必等待。 我們有兩臺專用于處理這些消息的機器，目前總共運行 40 個 PHP 進程以消耗作業。 每個 PHP 進程消耗 250 個工作，然后死亡并重新生成。 我們這樣做是為了避免 PHP 出現任何形式的垃圾回收問題。 將來，我們可能會增加每個會話消耗的作業數量，以提高性能，因為事實證明重新分配 PHP 進程會占用大量 CPU。 該系統使我們可以改善資源管理。 例如，在高峰時間，我們甚至每分鐘可以登錄 1000 次。 這意味著我們將對 users 表進行 1000 個并發更新，以存儲用戶的上次登錄時間。 因為現在我們使這些查詢入隊，所以我們可以依次依次運行每個查詢。 如果我們需要更高的處理速度，我們可以將更多的使用者添加到隊列中，甚至可以將機器加入集群中，而無需修改任何配置或部署任何新代碼。 ### CouchDB 為了存儲日志，我們在一臺計算機上運行 CouchDB。 從那里我們可以按模塊/動作查詢/分組日志； 事實證明，發現問題出在哪里很有用。 在將 CouchDB 用作日志聚合器之前，我們必須在每臺 PHP 機器上登錄并拖尾-f，然后從那里嘗試找出問題所在。 現在，我們將所有日志中繼到隊列，然后使用者將它們插入 CouchDB。 這樣，我們可以在集中的地方檢查問題。 ### 石墨 我們使用[石墨](http://graphite.wikidot.com/)從網站收集實時信息和統計信息。 從每個模塊/動作的請求到 Memcached 命中/未命中，RabbitMQ 狀態監視，服務器的 Unix 負載等等。 Graphite 服務器每分鐘進行約 4800 次更新操作。 實踐證明，該工具對于查看站點中的實際情況非常有用。 它是簡單的文本協議，其圖形功能使它易于使用，幾乎可以即插即用到我們要監視的任何系統。 我們使用 Graphite 做的一件很酷的事情是監視同時運行的網站的兩個版本。 去年一月，我們部署了由新版本的 symfony 框架支持的代碼。 這意味著我們可能會遇到性能下降的情況。 我們能夠在一半的服務器中運行該站點的一個版本，而新版本則在其他服務器中運行。 然后，在 Graphite 中，我們為每半創建 Unix 負載圖，然后進行實時比較。 由于我們發現新版本的 Unix 負載較高，因此我們啟動了 XHProf 分析器并比較了這兩個版本。 我們使用 APC 存儲“標志”，這些標志使我們可以啟用/禁用 XHProf，而無需重新部署代碼。 我們有一個單獨的服務器，在其中發送 XHProf 配置文件，然后從那里匯總它們并進行分析，以找出問題所在。 ### 紅色 5 我們的網站還向用戶提供視頻。 我們有兩種。 一種是來自用戶配置文件的視頻，這些視頻是用戶制作和上傳的電影。 此外，我們還有一個視頻聊天功能，可讓我們的用戶互動并分享他們的視頻。 在 2009 年中，我們每月向用戶流式傳輸 17TB 的視頻。 ### 宗宗 Tsung 是用 Erlang 編寫的分布式基準測試工具。 我們使用它來進行 HTTP 基準測試，并比較我們計劃使用的 MySQL 的不同存儲引擎，例如新的 XtraDB。 我們有一個工具可以記錄到主 MySQL 服務器的流量，并將該流量轉換為 Tsung 基準測試會話。 然后，我們重播了這些流量，并通過 Tsung 生成的數千個并發用戶訪問了實驗室中的計算機。 很棒的事情是，我們可以產生更接近實際生產環境中發生情況的測試方案。 ## 得到教訓 * 雖然面向 Buzz 的開發很酷，但**仍在尋找具有重要社區的工具**。 當有問題需要解決時，或者需要將人員納入團隊時，文檔和良好的社區將非常寶貴。 symfony 規定，可以免費獲得 5 本以上的官方書籍。 CouchDB 和 RabbitMQ 的開發人員也提供了良好的支持，它們具有活躍的郵件列表，可以及時回答問題。 * **了解您正在使用什么以及這些系統/庫的局限性是**。 我們從 symfony 中學到了很多東西。 可以在哪里進行調整以及可以改進什么。 就 PHP-FPM 而言，我們可以這么說，只是通過閱讀文檔，我們發現強大的 fastcgi_finish_request（）函數被證明是非常有用的。 另一個例子是 Nginx，Nginx 社區已經解決了一些問題，例如我們對圖像存儲緩存的解釋。 * **擴展工具**。 如果他們運行良好，則無需在當前堆棧中引入新軟件。 我們已經編寫了幾個 Nginx 模塊，這些模塊甚至已經被 Nginx 社區測試過。 這樣，您可以回饋。 * **D** **對于無關緊要的**并不保守。 石墨似乎是在生產中運行的一種很酷的工具，但是關于它的報道并不多。 我們只需要嘗試一下。 如果它不起作用，我們可以禁用它。 如果我們無法在系統中得到一個很好的 Unix Load 圖，誰也不會哭。 今天，甚至我們的產品經理都喜歡它。 * **測量所有**：Unix 負載，站點使用情況，Memcached 命中率/丟失率，每個模塊/動作的請求等。學習解釋這些指標。 * **創建工具，使您可以盡快對問題做出反應**。 如果您必須回滾部署，那么您不想花費一秒鐘以上的時間。 * **創建工具，使您可以實時分析網站的情況**。 在實驗室中，大多數測試都給出了樂觀的信息，但隨后卻無法應對生產負荷。 ## 未來 * 構建一個新的，更具可伸縮性的消息系統，因為當前版本相當舊，并且并非針對如此大量的消息而設計。 * 將越來越多的處理任務移至隊列系統。 * 將更多的 Erlang 應用程序添加到我們的系統中。 事實證明，RabbitMQ 對我們和 CouchDB 都適用。 它們是易于安裝和部署的系統，從而增加了我們對 Erlang 作為語言/平臺的信任。 * 我們正在尋找 Red5 的替代產品，可能是用 Erlang 編寫的 Oneteam Media Server。 目前，當我們使用開源 Erlang 產品時，我們可能會開始使用該語言編寫我們自己的應用程序，因為現在我們已經有了使用它的經驗。 * 改進我們的日志可視化工具。 我要感謝 Alvaro Videla 的出色寫作。 如果您想共享 fablous 系統的體系結構，請 [與聯系我](http://highscalability.com/contact/)，我們將開始。 讓我們做數學。 每分鐘有 15 萬個請求到 www。*，這意味著每秒有 2500 個請求。 他們有 28 個 PHP 框，每個框有 100 個進程。 這意味著 2800 個 PHP 進程。 您需要盡可能多的 PHP 進程來處理并發請求（不是每秒）。 這意味著它們的腳本要么花費 1 秒來執行每個腳本，要么它們有很多方法可以執行。 不管哪種方式，東西都壞了。 我知道有使用 2-4 臺服務器使用 PHP 滿足此請求數量的網站。 不是 28。 Quote： **此系統使我們可以改善資源管理。 例如，在高峰時間，我們甚至每分鐘可以登錄 1000 次。 這意味著我們將對用戶表進行 1000 個并發更新，以存儲用戶的上次登錄時間** 不，這并不意味著您有 1000 個并發更新。 這意味著您每秒大約有 16 次登錄，這意味著您可能有 10-20 次并發更新。 大多數時候少很多。 還要注意，它們有 50 個 memcached 節點。 他們必須處理多少臺服務器來處理這種中等負載？ 太瘋狂了 結論：并不令人印象深刻，我還沒有看到任何新見解。 我對他們的代碼的效率提出了很多質疑。 您好 Alvaro，感謝您對體系結構的有趣了解。 我提出了兩個問題：-如何衡量并發用戶（超時？），為什么使用這么小的數據集使用如此多的節點進行內存緩存？ 問候，保羅 您可以提供指向 Graphite 的鏈接嗎？ 聽起來很有趣，我們已經開始研究這些系統，但是它的含義如此普遍，以至于簡單的 Google 都無法提出我認為正確的任何東西。 可以在 [http://graphite.wikidot.com/](http://graphite.wikidot.com/) 上找到石墨網站。 @霜： -對 poppen.de 的 150.000 請求并不意味著它們全部都到達了 PHP 后端。 “我知道使用 2-4 臺服務器使用 PHP 滿足此請求數量的站點。不是 28 臺。” 這取決于他們做什么，他們緩存了什么，可以從請求中緩存多少。 它們顯示多少個局部分量？ 網站信息是否完全動態？ 問題列表可以繼續。 除此之外，我們將平均負載保持在較低水平，并且我們有足夠的服務器來滿足計劃的增長。 除此之外，當您建立網站時，您還必須做出商業決策。 不像您選擇有關網站編程理論的最佳書籍。 在我們的例子中，我們使用框架和 ORM。 這使我們發展很快。 您也必須考慮到這一點。 我了解到，在不了解其他公司背后的背景的情況下很難談論它們。 關于對數據庫和登錄號的并發查詢，您是對的，我在編號上犯了一個錯誤。 我向讀者道歉，因為他們提供了誤導性的信息。 另一方面，我希望您和該站點的其他讀者能夠理解使用隊列服務器可以完成的工作。 如果您已經知道了這一點，并且不需要向我學習，那么對您會更好。 我希望這對至少一名開發人員有用。 50 個 Memcached 節點并不意味著有 50 個專用計算機。 @保羅 p： 我們有一個“誰在線”服務器來跟蹤在線用戶。 它使用超時將其標記為已注銷。 我們使用幾個 Memcached 節點，因為根據要緩存的內容，我們有專門的存儲桶。 例如，我們有視圖緩存，用于緩存模板。 函數緩存，用于將查詢緩存到數據庫。 然后，一個 Memcached 專門將查詢緩存到一個表等。這樣，一個 memcached 的使用不會影響其他表。 @理查德： http://graphite.wikidot.com/ 嗨，阿爾瓦羅 我想向您介紹一個更好的流服務器： [erlyvideo](http://erlyvideo.org) ，值得測試，在您的情況下它將處理多少用戶（對我來說，它可以從一臺計算機上支持 1800 個連接）。 如果需要，請寫 [[受電子郵件保護]](/cdn-cgi/l/email-protection) 。 >我們希望按用戶 ID 對數據進行分區，因為網站上的大多數信息都以用戶本身為中心，例如圖像，視頻，消息等。 哼...這很有趣...會不會創建太多分區？ 我對 Mysql 不太熟悉，但是我正在研究的那個 MySQL 建議我們不要創建超過 2000 個分區。 但是，在用戶 ID 上進行分區將意味著幾個 100K +分區。 @Alvaro： 因此，如果他們甚至不使用 PHP，那么我更正確的是您的腳本太慢，進程太多。 但這不是真正的問題。 我正在談論的站點具有很多動態內容，但是緩存非常聰明，而且它們不使用任何框架或 ORM 包裝器。 這就是我認為您可能損失 90％的性能的地方，這些東西往往是絕對的性能殺手。 當然，您可以在開發時間上獲得一些優勢，但是一旦達到一定的規模，就會希望您沒有走這條路。 為使用更智能查詢和緩存的對象編寫一些類并不難。 您的前端有 2.5k re / s，memcached 可以提供 133 re / s。 這是否意味著您的緩存命中率為 5％？ 而且請不要使用“每分鐘的請求數”，沒有人對規模感興趣。 它主要是“每秒請求數”，突然之間您的數字似乎不再那么大了，因為它只有 60 分之一。 @Abhishek： 他沒有說每個用戶一個分區，而是說了按用戶 ID 劃分的分區。 這并沒有暗示有關分區大小的任何信息。 每個分區可以是 100 個用戶或 100 萬個用戶。 它僅告訴您使用哪個鍵來決定將值存儲在哪個分區中。 同樣，這與 MySQL 本身無關。 你在做什么？ 還有 2000 個分區？ 是，對.. 有趣。 您使用任何類型的虛擬化/云服務還是全部物理硬件？ 任何 CDN？ 什么操作系統/發行版？ 阿爾瓦羅 很棒的帖子。 我認為閱讀和查看如何解決許多問題很有趣。 關于石墨也不錯的技巧。 此致 尼克拉斯 嗨，阿爾瓦羅。 您說過您正在使用 memcached 來緩存諸如用戶個人資料之類的視圖組件。 您能否說明有關如何使這些視圖緩存無效的更多詳細信息？ 我了解您在更改數據時編寫了自己的代碼來使“數據緩存”無效。 但是對于視圖緩存，有很多數據，任何數據更改都將使該視圖緩存無效。 你是怎樣做的？ 我的第一感覺：太多的 PHP 服務器。 我認為在這種情況下，Symfony 對于他們來說 PHP 框架太慢了。 從我的經驗中得知，Symfony 吃了很多 CPU。 我真的認為他們應該用更具擴展性和輕量級的 PHP 框架取代 Symfony @Max Lapshin 感謝您對 Erlyvideo 的提示，幾個月前我們也對此進行了調查。 我們尚未決定。 @Maxim R 我們使用 EC2 進行視頻傳輸，其他系統則托管在我們的物理服務器中。 服務器正在運行 SLES10。 @尼爾·H 我們對鍵進行“命名空間”，因此可以立即使相關的鍵集失效。 但這取決于網站的哪一部分。 因此，在這里很難解釋所有這一切。 參見此處，了解許多常見模式：http://code.google.com/p/memcached/wiki/FAQ @pcdinh 如果您是 http://twitter.com/pcdinh，那么我可以告訴您，我們不使用 16 核 Dell / HP 之類的計算機。 我們使用具有 8 核的 6G Ram 的舊刀片服務器。 除此之外，我們將這些機器的平均負載保持得非常低。 然后，關于 symfony 或任何 PHP 框架，盡管它們不是比普通的 PHP 代碼或更輕量級的框架最快的解決方案，但速度并不是選擇框架時唯一考慮的問題。 symfony 擁有強大的支持，強大的社區和大量文檔。 這意味著我們可以輕松雇用已經知道我們所使用技術的人員。 那么，如果我們使用超快速的自定義框架，然后編寫它的“黑客”離開了公司，會發生什么呢？ 誰來維護他的代碼？ 從理論上講，您關于遷移到另一個框架的建議聽起來不錯，但是您知道將站點代碼移植到另一個框架可能需要花費幾個月的時間嗎？ 我們還必須支付開發人員的薪水，而在大多數情況下，這些薪水都比其中一臺刀片服務器貴。 因此，正如我在之前的回答中所說，公司會做出業務決策，而不僅僅是因為速度快而選擇了這種框架。 因此，請不要將服務器數量歸咎于 symfony，因為雖然 yes 比普通的 PHP 代碼重，但這不是我們使用那么多服務器的原因。 如果不是，那為什么要使用 PHP？C 的速度要快得多。 Alvaro，我絕不會質疑您的基礎架構，因為您比這里的其他任何人都了解它，尤其是其中一些“扶手椅系統架構師”。 :) 但是該語句 > 我們還必須支付開發人員的薪水，而在大多數情況下，這些薪水都比其中一臺刀片服務器貴。 can lead you into a corner. you can throw money at hardware only for so long until your investment start to produce diminishing returns and your infrastructure becomes too unwieldy and then it'll be that much harder to do any meaningful code changes. 保持服務器負載“ *非常*低”又有什么意義呢？ 如果服務器在可接受的時間內返回數??據，負載是多少（故障或嚴重超載除外）有關系嗎？ 聽起來您所有的服務器都在內存緩存池中。 我很好奇，PHP 服務器具有更大的 APC 緩存大小而不是將其用于內存緩存會更好嗎？ @馬克西姆 R. 感謝您的見解。 我同意你的看法。 不是說您去硬件上花錢，應該有一個平衡點。 我們也會在可能的情況下嘗試改進代碼。 e .：每當我們向站點功能添加功能時，我們都會嘗試提高性能，重構代碼等，因為我們需要在腐爛之前對其進行維護。 我們正在開發一種用于 SQL 查詢的輕量級解決方案，根據我們的基準測試，該解決方案將減輕站點的大量負載，因為我們可以刪除我們使用的 ORM，這是很沉重的。 我們的網站在不斷發展，我們正在像每個人一樣從錯誤中學習。 關于平均負載語句，我說過，因為對于某些評論者來說，我們有 28 臺完全過載的計算機。 除此之外，我們擁有這些機器是因為我們正在計劃未來的增長，如果一切都按計劃進行，那么到將來我們的意思是迫在眉睫。 關于 APC 與 Memcache。 我們必須考慮更多。 有時我們討論的與您剛才所說的相同。 同時，一些經驗豐富的 PHP 開發人員告訴我，APC 在擁有大量 RAM 時不能很好地工作。 我沒有與此相關的經驗可以發表意見。 另外，APC 緩存不共享，如果這也是一個問題，我們必須考慮。 我們也將一些計算緩存到 APC 中。 阿爾瓦羅 感謝**很棒的文章**！ 我對您的 nginx 和 memcached 有一個問題。 您寫道，許多請求甚至都沒有達到 PHP，因為 Nginx 從 memcached 獲取了緩存的內容-您能再描述一下嗎？ 您是否緩存 HTML 頁面？ 問候， @阿爾瓦羅 Erlyvideo 發展非常迅速。 幾個月前，您可以看到它的前一代，什么也做不了。 因此，如果您有興趣，最好通過電子郵件進行交流。 +1 感謝您的精彩文章！ Alvaro，我認為您應該嘗試 Erlyvideo-它在 Erlang 中很爛，而且發展非常迅速。 我認為，erlyvideo 的作者 Max Lapshin（привет，Макс:)可以提供支持并實現所需的所有功能。 Alvaro，您嘗試過 Facebook 的 HipHopPHP 編譯器嗎？ > 我發現最有趣的是他們如何成功地將一些舊的和一些新的 不，他們沒有成功地將新舊融合在一起。 poppen.de 以運行緩慢而聞名。 它幾乎從來沒有真正快過，而且每隔幾（6-8）周就會額外減速至少幾小時，通常是 1-2 周。 當前的緩慢周期自大約 6 周開始，至今仍未結束。 poppen.de 的性能給 a * s 帶來了痛苦。.遠非成功... > 我們有 2 個前端 Nginx 服務器 Alvaro, are these 2 servers in a master/master setup? Which is the solution to make them highly available/load balanced? Regards