實時餘額更新的大批量交易的最佳實踐

Question

我目前擁有一個處理大量交易的MySQL數據庫。爲了簡單起見，這是一個實時進行的操作（點擊和其他事件）的數據流。結構是這樣的，用戶屬於子分支機構和分支機構屬於分支機構。

我需要保持點擊的平衡。爲了簡單起見，假設我需要將用戶，子關聯公司和關聯公司的點擊餘額增加1（實際上有更多的處理取決於事件）。目前我很簡單地做到這一點 - 一旦我收到事件，我會在PHP中進行順序查詢 - 我讀取用戶的餘額，遞增1並存儲新值，然後我讀取子子公司的餘額，增量和寫入等等。

用戶的餘額對我來說是最重要的指標，所以我想盡可能保持實時。其他關於sub-aff和affiliate等級的指標並不重要，但它們越接近實時越好，但是我認爲5分鐘的延遲可能沒問題。

隨着項目的發展，它已經成爲一個瓶頸，我現在正在尋找替代品 - 如何重新設計天平的計算。我想確保新設計能夠每天處理5000萬個事件。對我來說，不要丟失一個事件也很重要，而且我實際上將每個更改週期都包裝在SQL事務中的點擊餘額上。

有些事情我考慮：

1 - 創建一個cron作業，將更新的子子公司和附屬水平不實時餘額，假設每5分鐘。

2 - 使用存儲過程將數字計算和平衡更新移動到數據庫本身。我正在考慮添加一個單獨的數據庫，也許Postgress會更適合這份工作？我試圖看看是否有嚴重的性能改善，但互聯網似乎在話題上存在分歧。

3 - 將這個特定的數據流移動到類似hadoop和parquet（或Apache Kudu？）之類的東西，並在需要時添加更多的服務器。

4 - 分割現有的數據庫，基本上爲每個分支機構添加一個單獨的數據庫服務器。

這種類型的任務是否存在一些最佳實踐/技術或者我可以做的一些明顯的事情？任何幫助真的很感激！

Answer 1

我對高速攝取的建議是here。在你的情況下，我會在它描述的乒乓表中收集原始信息，然後讓其他任務總結表來做計數器的質量UPDATEs。當交通突然爆發時，它變得更加高效，從而不會被擊倒。

點擊餘額（和「Like counts」）應該在與所有關聯數據分開的表中。這有助於避免干擾系統中的其他活動。如果您擁有的數據多於buffer_pool中緩存的數據，則可能會提高餘額的緩存能力。

請注意，我的設計不包括cron作業（除了可能作爲「保持活動」）。它處理一個表格，翻轉表格，然後循環回到處理 - 儘可能快。

Answer 2

如果我是你，我會實施Redis內存存儲，並在那裏增加你的指標。它非常快速和可靠。你也可以從這個數據庫中讀取。也創建cron作業，這將把這些數據保存到MySQL DB中。

Answer 3

您的網絡層是否正在進行數字運算，因爲它收到&處理HTTP請求？如果是這樣，你首先要做的就是將其移動到工作隊列中，並異步處理這些事件。我相信你在第3項中暗示了這一點。

解決方法有很多，選擇一個範圍是這個答案的範圍，但一些包來考慮：

• 的Gearman/PHP
• Sidekiq /紅寶石
• 亞馬遜SQS
• 的RabbitMQ
• NSQ

...等...

就存儲而言，它取決於你想要達到的目標，快速讀取，快速寫入，大容量讀取，分片/分佈，高可用性......每個點向您提供不同方向的答案

Answer 4

這聽起來像是一個很好的候選人Clustrix這是一個替代MySQL的下降。他們做類似分片的事情，但不是將數據放在單獨的數據庫中，而是將其拆分並在同一數據庫集羣中的節點上覆制。他們稱之爲切片，而數據庫自動爲你做。對開發者來說它是透明的。其上有一個good performance paper，它顯示了它是如何完成的，但缺點是它是一個橫向擴展的OTLP數據庫，它恰巧能夠吸收瘋狂的實時數據分析處理。