# 使用 HAProxy，PHP，Redis 和 MySQL 處理 10 億個請求的簡便方法來構建成長型啟動架構 > 原文： [http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html](http://highscalability.com/blog/2014/8/11/the-easy-way-of-building-a-growing-startup-architecture-usin.html)  此案例研究是 [Antoni Orfin](http://labs.octivi.com/author/aorfin/) 的來賓帖子， [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 的聯合創始人兼軟件架構師。 在文章中，我將向您展示我們基于 HAProxy，PHP，Redis 和 MySQL 開發非常簡單的架構的方式，該架構每周無縫處理大約 10 億個請求。 還應注意進一步擴展該模式和指出不常見模式的可能方法，這些方法特定于該項目。 ## 統計： * 服務器： * 3 個應用程序節點 * 2 個 MySQL + 1 個備份 * 2 個 Redis * 應用程序： * 應用程序每周處理 1,000,000,000 個請求 * 單個 Symfony2 實例高達 700 req / s（平均工作日-550 req / s） * 平均響應時間-30 毫秒 * 清漆-超過 12,000 req / s（在壓力測試過程中達到） * 數據存儲區： * Redis-160,000,000 條記錄，100 GB 數據（我們的主要數據存儲！）， * MySQL-300,000,000 條記錄-300 GB（第三緩存層） ## 平臺： ##  * 監控： * 伊辛加 * 已收集 * Application: * 帶有 Keepalived 的 HAProxy * 清漆 * 帶有 Symfony2 框架的 PHP（PHP-FPM） * Data store: * 具有 HAProxy 負載平衡的 MySQL（主-主） * Redis（主從） # 背景 大約一年前，我們的朋友帶著一個苛刻的問題來到我們的辦公室。 他們經營著一家快速成長的電子商務初創公司，當時他們想擴展到國際市場。 由于它們仍然是一家初創型公司，因此建議的解決方案必須具有成本效益，以免在下一臺服務器上用完錢。 舊版系統是使用標準 LAMP 堆棧構建的，他們已經擁有強大的 PHP 開發人員團隊。 引入新技術必須很聰明，以免使體系結構過于復雜，并讓他們與現有人員進一步維護平臺。 系統架構必須以可擴展的方式設計，以實現其擴展到下一個市場的計劃。 所以我們來檢查他們的基礎設施...   以前的系統是單片設計的。 在后臺有一些單獨的基于 PHP 的 Web 應用程序（該創業公司有許多所謂的前端網站）。 他們中的大多數使用單個數據庫，他們共享一些處理業務邏輯的通用代碼。 此類應用程序的進一步維護可能是一場噩夢。 由于必須重復某些代碼，因此在一個網站中進行更改將導致業務邏輯不一致-他們始終必須在所有 Web 應用程序中進行相同的更改。 從項目管理的角度來看，這也是一個問題-誰負責跨多個代碼庫分布的那部分代碼？ 根據這些觀察，我們的第一步是將核心業務關鍵功能提取到單獨的服務中（這是本文的范圍）。 這是**面向服務的體系結構**的模式。 考慮“關注點分離”原則，但要考慮整個系統。 該服務保持一種特定的高級業務功能的邏輯。 舉一個真實的例子-服務可以是搜索引擎，銷售系統等。 前端網站正在通過 **REST API** 與服務進行通信。 響應基于 **JSON** 格式。 我們選擇它是為了簡單起見，而不是像 SOAP 那樣對開發人員來說是苛刻的（沒人喜歡解析 XML…;-)） 提取的服務無法處理身份驗證和會話管理之類的事情。 必須在更高層次上處理這些事情。 前端網站對此負責，因為只有他們才能識別其用戶。 這樣，我們使服務變得更簡單-在進一步擴展問題和編寫代碼方面。 沒什么不好的，因為它需要處理不同類型的思考任務。 ## 好處： -完全獨立的開發團隊可以輕松開發單獨的子系統（Service）。 開發人員不要互相干擾。 -**它不處理用戶身份驗證**和會話，因此這個常見的擴展問題消失了。 -**業務邏輯保存在一個地方**-跨不同前端網站的功能不再多余。 -**易于使服務公開訪問**。 ## 缺點： -**為系統管理員**做的更多工作-服務位于其自己的基礎結構中，需要管理員額外注意。 -**保持向后兼容**-在一年的維護之后，API 方法發生了無數變化。 事實是，它們一定不能破壞向后兼容性，因為這會導致對每個前端網站的代碼進行更改-以及一次部署所有網站的繁瑣工作……一年之后，所有方法仍與 文檔的第一版。 # 應用層  與請求流一起，第一層是應用程序。 HAProxy 負載平衡器，Varnish 和 Symfony2 Web 應用程序位于此處。 來自前端網站的請求首先到達 HAProxy，然后將其分發到應用程序節點。 ## 應用程序節點配置 * Xeon [[受電子郵件保護]](/cdn-cgi/l/email-protection) ，64GB RAM，SATA * 漆 * 阿帕奇 2 * PHP 5.4.X 作為 PHP-FPM 運行，具有 APC 字節碼緩存 我們有三個這樣的應用服務器。 雙活模式下的 **N + 1 冗余-“備份”服務器正在積極處理請求。** 在每個節點上保留**單獨的 Varnish 可以降低緩存命中率，但是這樣我們在這里沒有 SPOF（單點故障）。 我們這樣做是為了保持可用性而不是性能（在我們的案例中這不是問題）。** 已選擇 Apache2，因為舊版前端網站服務器也使用了 Apache2。 避免混合使用多種技術，使管理員更易于維護系統。 ## Symfony2 應用 該應用程序本身建立在 Symfony2 之上。 這是一個 PHP 全棧框架，提供了許多有用的組件，可加快開發過程。 由于通常將 REST 服務基于復雜框架的決定對于某人來說聽起來很奇怪，所以讓我澄清一下背后的原因： * **訪問 PHP / Symfony 開發人員**-客戶的 IT 團隊由 PHP 開發人員組成。 引入新技術（例如 Node.js）將導致需要雇用能夠進一步維護系統的新開發人員。 * **干凈的項目結構**-Symfony2 并不強加完整的項目結構，但具有非常明智的默認結構。 向新開發人員介紹該項目很簡單，因為他們對代碼很熟悉。 * **現成的組件**-遵循 DRY 概念...沒有人想要重新發明輪子，所以我們沒有。 我們廣泛使用 Symfony2 控制臺組件，它是一個不錯的框架，可用于制作 CLI 命令，用于分析應用程序的工具（調試工具欄），記錄器等。 在選擇使用它之前，我們已經對**進行了性能測試**，以確保它能夠處理計劃的流量。 我們已經開發了概念證明，并對其進行了 JMeter 的測試。 結果令人印象深刻-700 req / s，響應時間高達 50ms。 它使我們確認，可以將這種復雜的框架用于此類項目。 ## 應用程序配置文件&監視 我們正在使用 Symfony2 工具來監視應用程序。 有一個很好的事件探查器組件，我們可以用來收集特定方法的執行時間，尤其是與第三方網絡服務進行通信的方法。 這樣，我們可以發現潛在的弱點和應用程序中最耗時的部分。 詳細日志記錄也是必須的。 為此，我們使用了 PHP Monolog 庫，該庫使我們能夠創建格式良好的日志行，開發人員和系統管理員完全可以理解。 必須始終記住要添加盡可能多的細節，我們發現越詳細越好。 我們使用不同的日志級別： * **調試**-即將發生的事情-例如 在調用外部 Web 服務之前請求信息； 剛剛發生的事情-API 調用的響應 * **錯誤**-出了點問題，但請求流沒有停止（例如，來自第三方 API 的錯誤響應）。 * **嚴重**-糟糕…應用程序剛剛崩潰了：-) 因此，在生產環境中，您可以看到諸如 Error 之類的痕跡，并且在其下-Critical。 在開發/測試環境中，還記錄了調試信息。 我們還將**日志分為單獨的文件**（在 Monolog 庫中，它們稱為“通道”）。 有一個主日志文件，其中記錄了所有應用程序范圍內的錯誤以及來自特定渠道的簡短日志。 我們將通道中的詳細日志保存在它們各自的文件中。 ## 可擴展性 擴展應用程序平臺層并不困難。 HAProxy 的性能**不會長期耗盡**，我們正在考慮的唯一事情就是使它們冗余以避免 SPoF。 因此，當前模式只是添加下一個應用程序節點。 # 資料層 我們正在使用 Redis 和 MySQL 來存儲所有數據。 **MySQL** 主要用作**第三層緩存**層，而 **Redis 是我們的主要數據存儲區**。 ## 雷迪斯 在設計系統時，我們正在考慮選擇合適的數據庫來滿足計劃的需求： * 保留大量數據（約 250,000,000 條記錄）時不會失去性能 * 通常基于特定資源 ID 的簡單 GET（無需查找或復雜的 SELECT） * 可以在單個請求中檢索大量資源以最小化延遲 經過調查，我們決定使用 Redis。 * 我們執行的所有操作的復雜度為 O（1）或 O（N），其中 N 是要檢索的鍵的數量。 也就是說，鍵空間的大小不會影響性能。 * 我們主要使用 MGET 命令來一次檢索> 100 個鍵。 與在循環中進行多個 GET 相比，這可以省去網絡延遲。 當前，我們有兩臺 Redis 服務器以主從復制模式運行。 它們每個都具有以下配置：Xeon [[受電子郵件保護]](/cdn-cgi/l/email-protection) ，128GB，SSD。 內存限制設置為 100 GB ...并且始終被完全消耗:-)  由于應用程序并沒有窮盡單個 Redis 服務器的性能限制，因此從服務器主要用作備份并保持高可用性。 如果主機崩潰，我們可以輕松地切換應用程序以使用從機。 復制在執行某些維護任務或遷移服務器時也很方便-輕松切換服務器。 您可能想知道我們的 Redis 一直處于 maxmemory 極限的情況。 大多數鍵是持久類型的-大約占鍵空間的 90％。 但是它們的其余部分是純緩存，我們為其設置了到期 TTL。 現在，密鑰空間分為兩部分：一部分已設置 TTL（緩存），第二部分未設置（持久數據）。 由于可以設置“ volatile-lru” maxmemory 策略，因此會不斷自動刪除使用較少的緩存鍵（只有它們已過期）。 這樣，我們就可以**僅保留一個既充當主存儲又充當典型緩存**的 Redis 實例。 使用此模式時，必須始終記住監視“過期”鍵的數量： db.redis1：6379 >信息鍵空間 ＃鍵空間 db0：keys = 16XXXXXXX，expires = 11XXXXXX，avg_ttl = 0 當您發現該數字危險地接近零時，請開始分片或增加內存;-) 我們如何監控它？ 有一個 Icinga 支票，用于監視“到期”數是否達到臨界點。 我們還收集了 Redis 圖，以可視化“丟失鍵”的比率。  一年后，我可以說我們完全加入了 Redis。 從項目一開始，就沒有讓我們感到失望-沒有任何中斷或其他問題。 ## 的 MySQL 除了 Redis，我們還使用傳統的 MySQL 數據庫。 罕見的是，我們通常將其用作第三個緩存層。 我們將最近未使用過的 MySQL 對象存儲在其中，而將它們存儲在 Redis 中會占用過多的內存，因此我們將它們保存在硬盤上。 這里沒有什么花哨的技術，但是我們希望將堆棧保持盡可能簡單，以便于維護。 我們有 2 臺使用 Xeon [[受電子郵件保護]](/cdn-cgi/l/email-protection) ，64GB RAM，SSD 的 MySQL 服務器。 它們上有一個本地的異步主-主復制。 另外，我們保留單個從節點僅用于備份。 ## MySQL 的高可用性 正如您在物理體系結構圖上看到的那樣，在每個 MySQL 框上，HAProxy 也處于保持狀態。 與 MySQL 的連接通過 HAProxy 進行。 在每臺數據庫服務器中安裝 HAProxy 的模式導致保持堆棧的高可用性，并且無需為負載平衡器添加添加下一個服務器。 HAProxy 以主動-被動模式運行（一次僅使用其中之一）。 對它們的可用性的控制是通過保持機制進行的。 在 keepalived 的控制下有一個浮動 IP（VIP）。 它檢查主負載均衡器節點的可用性。 發生故障時，第二個（被動）HAProxy 節點將接管 IP。 ## Scalability 數據庫始終是應用程序中最難的瓶頸。 目前，不需要任何橫向擴展操作-到**為止，我們正在通過將 Redis 和 MySQL 移至更大的框來垂直擴展**。 仍有空間，例如 Redis 在具有 128 GB 內存的服務器上運行-可以將其遷移到 256 GB 的節點上。 當然，這種笨重的盒子在快照或僅運行服務器等操作中也有缺點-啟動 Redis 服務器將花費更長的時間。 放大（垂直）后，橫向擴展。 令人高興的是，我們已經準備好**易于分片的數據**結構： Redis 中有 4 種“大量”記錄。 可以根據數據類型在 4 臺服務器上分片它們。 我們會避免基于散列進行分區，而傾向于**將數據除以記錄類型**。 這樣，我們仍然可以運行始終在一種類型的鍵上執行的 MGET。 在 MySQL 中，表是以這種方式進行結構化的，從而可以輕松地將其中的某些表遷移到不同的服務器上-也基于記錄類型（表）。 在無法進一步按數據類型進行分區之后，我們將進行散列處理：-) # 得到教訓 * **不要共享您的數據庫**-一次，一個前端網站希望將其會話處理切換為 Redis。 所以他們已經連接到我們的了。 這導致 Redis 緩存空間用盡，并拒絕了我們的應用程序來保存下一個緩存鍵。 所有緩存已開始僅存儲在 MySQL 服務器上，這導致大量的開銷。 * **制作詳細的日志**-在日志行中沒有太多信息，您將無法快速調試問題所在。 在一種情況下，由于缺乏單一信息，我們無法找到導致問題的原因，因此不得不等待其他問題的發生（在添加了丟失數據的日志之后）。 * **使用復雜的框架并不會自動意味著“降低網站速度”** -有些人感到驚訝的是，使用全棧框架可以每秒處理如此多的請求。 一切都與智能使用您擁有的工具有關–您甚至可以在 Node.js 中使其運行緩慢：-)選擇一種提供良好開發環境的技術，沒有人愿意為不友好的工具而煩惱（降低 devops 的士氣！）。 ## 誰在應用程序背后 該平臺由波蘭軟件公司 [Octivi](http://octivi.com/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 設計。 我們專注于構建注重高性能和可用性的可擴展架構。 我們還要感謝與 IT 部門在客戶端方面的大力合作！ # 相關文章 * [使用 Symfony2](http://labs.octivi.com/handling-1-billion-requests-a-week-with-symfony2/?utm_source=highscalability.com&utm_medium=referral&utm_campaign=guest-post) 一周處理 10 億個請求-我們整個應用程序的概述 * [將其推向極限-滿足高性能需求的 Symfony2](http://symfony.com/blog/push-it-to-the-limits-symfony2-for-high-performance-needs) -描述了具有 Symfony2 功能的軟件體系結構的詳細信息 標題是； “使用 HAProxy，PHP，Redis 和 MySQL 構建增長的啟動體系結構的簡便方法，每周可處理 10 億個請求” 在文章中描述了 Varnish 的用法。 我認為標題需要更新。 為什么只有一臺 Haproxy 服務器？ 您正在為應用程序節點使用 N + 1，但是前面只有一個負載均衡器嗎？ 如果此關鍵服務器出現故障，將會發生什么？ 那么“平均響應時間-30 毫秒”呢？該統計數據是在清漆前面或沒有清漆的情況下計算的？ 馬丁 誰能回答這些初學者的問題？ 1）由于 Redis 都在內存中，所以我假設持久保存數據以防兩個 Redis 節點都掉下來是 MySQL 的工作嗎？ 2）如果要使該系統更大，更可擴展，是否會引入消息隊列？ 3）您是否具有到兩個 Mysql 實例以及將來的分片 Redis 節點的單獨數據庫連接池？ 1\. Redis 可以將數據持久保存到磁盤。 它只是不能增長到大于 memory_size 2。如果它需要在請求之外做一些事情而不是 3.不知道。 在“ MySQL 的高可用性”中，我不明白您為什么使用 HAProxy，僅 Keepalived 可以解決問題（主動-被動和熱備用）。 有什么原因嗎？ Kakwa：HAProxy 允許以下幾項： 1\. MySQL 處于主動-主動模式，不僅是主動-被動模式（也可以使用 keepalived 和多個浮動 IP） 2\. HAProxy 之后的 MySQL 服務器權重（服務器不支持） （必須具有相同的硬件） 3.使用“ mysql-check”就可以更輕松地切換到維護模式 @Al： 1-Redis 提供可配置的將數據推送到磁盤。 因此，如果 Redis 發生故障，那么它將與 MISS 緩存和 MySQL 的工作相同，是的。 2-我認為是正確的，甚至他們實際上正在使用消息/作業隊列，但在本文中未提及 3-不知道：) 偉大的 AI 問題！ 1）不，Redis 可提供存儲數據的完全持久性。 您可以在兩種模式下進行設置： RDB-在配置的時間范圍內將整個鍵空間轉儲到一個文件中 AOF-將每個“查詢”保存到文件中 我們正在使用 RDB，但是您可以使用兩種模式 與此同時。 2）當然！ 在 Canhnm 之后，的確，我們在 Redis 之上建立了一些隊列，因為它為此類事情提供了專用的數據結構。 我們將消息傳遞用于最耗時的任務。 3）不 嗨，這真的很有趣，謝謝！ 但這只是架構的一部分：提供 JSON 響應的后端服務。 應用程序如何處理該數據并將其提供給最終用戶？ 是否有 JS 框架或另一個 PHP 應用程序層？ 謝謝！ 幾乎找不到您所有的圖像 404 :( 您正在使用哪個 PHP 的 Redis 擴展在 PHP 網站中實現 [redis 緩存？ 我知道兩個擴展：Predis 和 PHPRedis。 以我的經驗，在啟用了 varnish 和 memcached 的同一臺服務器上，事實證明 Predis 真的很容易配置，并且比 PHPRedis 提供更好的性能。](https://www.cloudways.com/blog/redis-cache-with-custom-php/)