# 每天處理 1 億個像素-少量競爭會導致大規模問題 > 原文： [http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html](http://highscalability.com/blog/2013/1/21/processing-100-million-pixels-a-day-small-amounts-of-content.html)  *這是 [Gordon Worley](http://www.linkedin.com/pub/gordon-worley/39/977/257) 的來賓帖子， [Korrelate](http://korrelate.com/) 的軟件工程師在其中將在線購買與離線購買相關聯（查看他們在這里做了什么）。* 幾周前，我們一天早上來到辦公室，發現所有服務器警報都響了。 像素日志處理落后了 8 個小時，并且沒有取得進展。 查看日志后，我們發現有一個大客戶在夜間上線，為我們提供的流量比最初告訴我們的要多 10 倍。 我不會說我們感到驚慌，但辦公室肯定比平時更加??緊張。 但是，在接下來的幾個小時中，由于有遠見和快速的思考，我們得以擴大規模以處理增加的負載并清除積壓的日志，以使日志處理恢復到穩定狀態。 在 Korrelate，我們部署了[跟蹤像素](http://en.wikipedia.org/wiki/Web_bug)（也稱為信標或網絡錯誤），我們的合作伙伴將其用于向我們發送有關其用戶的信息。 這些微小的 Web 對象不包含可見內容，但可以包含透明的 1 乘 1 gif 或 Javascript，并允許我們的合作伙伴在有人看到廣告或采取與廣告相關的操作時通知我們，而無需向我們發送廣告服務器日志。 例如，當我們的一個合作伙伴展示廣告時，他們通過將展示跟蹤像素作為圖像包含在 iframe 中或嵌入以我們的像素為源的腳本標簽來觸發我們的展示跟蹤像素。 他們的廣告會動態生成像素的網址，因此可以在查詢字符串中向我們傳遞有關所展示廣告的信息。 對于選擇接受第三方 cookie 的用戶，我們還可以在用戶上設置和讀取 Korrelate 用戶 ID cookie，以便我們可以跟蹤他們的活動，并在[聚合和匿名化](http://korrelate.com/privacy/)之后使用它，以提供我們的 分析產品。 在早期，甚至在 Korrelate 成為 Korrelate 之前，我們就知道有一天我們需要每天攝取數十億個跟蹤像素。 因此，當我們開始編寫像素對數處理器時，我們進行了架構選擇，使其可以擴展。 最初，日志處理器是用 Java servlet 編寫的，但是事實證明這很難在服務器上進行管理，而且我們都不滿意使用 Java 進行編程。 尋找替代方案，因為當時我們使用 [Pentaho](http://www.pentaho.com/) 分析工具套件來生成有關原始數據的報告，所以我們轉向了[水壺](http://kettle.pentaho.com/)（俗稱 Pentaho 數據集成） 數據。 Kettle 是在 JVM 上運行的提取轉換加載工具，可以充分利用多線程來快速處理大量數據。 它還具有一個稱為 Spoon 的易于使用的 GUI 工具，用于設計 Kettle 程序，該程序需要大量的配置，而編程卻相對較少。 我們非常享受使用 Kettle 創建和部署日志處理的速度。 隨著時間的流逝，我們意識到了水壺的局限性。 通過 Kettle 作業運行大量數據需要大量內存（在我寫這篇文章時，日志處理器需要 8 GB 內存來處理 250,000 條記錄的文件）。 在開發方面，使用 Spoon 易用性的缺點是源文件僅是人類可編輯的 XML，因此我們無法利用 Git 正常工作流來輕松合并并發開發分支，從而迫使我們 就像有人處理日志處理器時源被鎖定一樣。 但是盡管有這些限制，我們仍繼續使用 Kettle，因為它正在工作，我們還有很多其他工作要做，并且我們知道我們可以在需要時擴大規模，即使它會很昂貴。 幾個月前，我們不得不開始同時運行兩個日志處理器，以適應我們的負載。 這是一個很好的體驗，因為它有助于揭示日志處理中的問題區域。 當只有一個日志處理器運行時，我們遇到的唯一性能問題與過程的各個部分有關，需要很長時間才能完成。 例如，我們發現對數據庫中表的更新花費了很長時間，因此我們幾乎將所有存儲像素數據的表都轉換為僅追加，以便快速插入。 某些表不能僅作追加操作，因此要與我們創建的加載表一起使用，日志處理將快速將數據插入到表中，然后稍后再回過頭來將加載表與數據庫中的主表進行同步 比我們執行 upsert 的速度快。 調出第二個日志處理器會使我們面臨新的問題。 盡管由于對僅追加表的非阻塞寫入而使我們能夠快速寫入數據庫，但是需要與加載表同步的少數幾個表引起了足夠的爭用，兩個日志處理器在運行一個日志處理器時幾乎沒有任何收益。 為了解決這個問題，我們將日志處理分為兩部分：僅寫到僅追加表的部分和需要插入堆表的部分。 這樣，我們就可以打開僅追加日志處理器的兩個實例（僅是堆表日志處理器之一），并獲得良好的吞吐量，因為堆表從每個需要插入或更新的日志文件接收的數據相對較少，而追加- 只有表從每個日志文件接收很多數據。 因此，在像素大量涌入的早晨，我們認為我們已經做好了擴大規模的準備。 我們在幾個小時之內啟動了運行其他附加僅日志處理器實例的其他服務器，并開始處理日志（堆表日志處理器自行繼續足夠快地運行以保持運行狀態）。 但是，我們很快發現，日志處理器中仍然存在爭用。 為了跟蹤日志處理的方式，我們將一些基本統計信息寫到了幾個審計表中，這些統計信息涉及日志處理需要多長時間以及處理多少像素。 為了收集這些數據，我們使用了 Kettle 的內置日志記錄功能將信息寫入表格，然后將其合并為對我們有用的摘要形式。 事實證明，Kettle 的編寫方式要求在審計表上請求排他表級鎖以將其寫入。 而且由于在日志處理器實例的每次運行中都會發生數十次，因此對于相同的表，我們有數百個請求彼此等待。 每個請求的清除速度都很快，但是加了一點點延遲，導致日志處理器實例在應在 2 中完成時需要花費 15 分鐘的時間來運行。 我們關閉了 Kettle 的內置日志記錄功能，將其替換為我們自己的一些不需要表級鎖定的代碼，并且日志處理器之間的數據庫爭用消失了。 我們以艱難的方式學到了我們經常聽到的智慧，但顯然還沒有被內在化：**少量爭用可能成為大規模的問題**。 通過從日志處理中完全消除爭用，我們能夠快速啟動十多個日志處理器實例，并使用它們來快速處理積壓的事務，然后將其調節回穩定狀態。 在短短 24 小時內，一切恢復正常，節省了一些額外的硬件和日志處理器。 盡管日志處理器現在可以處理高級別的并發性，但仍需要對其進行重建以處理更多的像素，而無需當前日志處理器的高昂成本。 調出當前日志處理器的新實例意味著添加具有大量 RAM 的服務器（通常大約需要 24 GB，以便我們在每臺服務器上運行兩個日志處理器，以及用于其他進程的額外 RAM），這是很昂貴的。 而且，當前的日志處理器在與數據庫的有限連接上仍然面臨潛在的爭用。 為了解決這個問題，我們需要尋找減少需要向數據庫傳遞數據的進程數量的方法。 我們還希望從 Kettle 轉移到一個使代碼管理更容易的系統。 為此，我們已開始使用 [Storm](http://storm-project.net/) 構建新的日志處理器，該處理器提供了用于創建自定義實時流處理工作流的靈活框架，類似于 [Hadoop](http://hadoop.apache.org/) 提供了靈活框架的方式 用于批處理。 盡管僅 Storm 本身提供的內置功能要比 Kettle 少得多，但也不必這樣做，因為 Storm 工作流可以用任何語言編寫，也可以使用我們想要的任何現有庫。 由于我們的大多數代碼已經在 Ruby 中，因此我們能夠利用現有的代碼庫在 Ruby 中構建 Storm 工作流。 基于其他使用 Storm 的[其他人](https://github.com/nathanmarz/storm/wiki/Powered-By)，我們希望看到我們的 Storm 日志處理器每天可以擴展到數十億像素。