我們有一個電子商務系統，有超過100萬的用戶，訂單表中總共有400到500萬條記錄。我們使用codeigniter框架作為后端，Mysql作為資料庫。
由于用戶和購買的數量過多，我們使用cron jobs來更新訂單細節和每小時的推薦獎勵積分，以使事情順利進行。
現在我們有一個情況，就是這些資料更新超過了一個小時，下一批更新在完成前一批更新之前就已經到達，從而導致了系統的僵局和失敗。
我想知道不同的可能的架構和資料庫擴展方案，以及擺脫這種情況的建議。我們只使用單片機架構來運行這個應用程式。
uj5u.com熱心網友回復：
不要使用cron。 有一個單一的行程，當它完成后重新開始。 如果一個行程持續了一個多小時，下一個行程就會晚點開始。 (檢查
PROCESSLIST是很笨拙和容易出錯的。 相反，這種持續運行的方法需要一個 "keep-alive "cronjob。不要
UPDATE數百萬行。 相反，找到一種方法，將所需的資訊放在一個單獨的表中，讓用戶加入其中。 據推測，這個額外的表將只有1行（如果每個人都被同一個游戲所控制）或少量的行（如果只有少量的模式需要處理）。確實打開了慢速日志，并為
long_query_time設定了一個小值（可能是 "1.0"，可能更低）。 使用pt-query-digest來總結它以找到 "最差 "的查詢。 然后，我們可以幫助你使它們花費更少的時間，從而幫助平息你繁忙的系統和改善 "用戶體驗"。請使用批處理的
INSERT。 (一個有100行的INSERT的運行速度大約是100個單行INSERT的10倍)。 批量處理UPDATEs是很棘手的，但是可以用IODKU來完成。請使用100-1000行的批次。 (考慮到可能發生的各種情況，這在某種程度上是最理想的。
謹慎地使用事務。 在每個步驟中檢查錯誤（包括死鎖）。
請告訴我們你在每小時的更新中正在做什么。 我們也許能夠提供比那本15年前的書更有針對性的建議。
請意識到你的規模已經超過了典型的第三方軟體包的能力。 也就是說，你將不得不學習 SQL 的細節。
uj5u.com熱心網友回復：
我在這里有一些想法給你--與一些問題混在一起。
假設你能做的事情是有限的（即你不能重新架構你的方式），并且資料庫不能被進一步調整：
- 使資料庫成為 "一個 "的概念。
- 使要處理的記錄串列盡可能的小
。
i.e. 該作業是否必須運行所有記錄？ 這4-5百萬條記錄--它們都是活躍的訂單，或者這就是你在所有時間內的總數量？ 顯然，只需處理最低限度的記錄即可。
- 分割和并行處理
你提到了 "批次"，但從未解釋這意味著什么--你能詳細說明一下嗎？
你能讓多個cron job的實體同時運行，每個實體覆寫不同的記錄段嗎？
- 多記錄操作
對更新進行編程的簡單（懶惰）方法是在一個回圈中進行，該回圈將迭代每條記錄并單獨處理，但關系型資料庫可以一次對多條記錄進行更新。 我很確定有一個合適的術語，但我記不起來了。 你是在單獨處理每條記錄還是在進行多記錄更新？
cron job是如何查詢資料庫的？ 你是否手工制作了最有效的查詢，或者你使用了一些ORM/框架來為你做事情？
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/328409.html
標籤：