個人記錄：2018年，工作的第6到7個年頭。
重點研究自己不太擅長的技術：分散式、高併發、大資料量、資料庫優化、高效能、負載均衡等。
刷題是一種態度，是一種好習慣。
我刷題，我驕傲。


題目：遊戲裡 經常有涉及 使用者排行榜（金幣消費排行榜），怎麼設計一個良好的排行榜。
諸如 幾千萬的使用者量， 每個使用者消費金幣的頻率也比較高。  排行榜 從資料採集 到 排行 一整套下來。有什麼樣的設計方案。
問題出處：http://ifeve.com/question/%e6%b8%b8%e6%88%8f%e9%87%8c-%e7%bb%8f%e5%b8%b8%e6%9c%89%e6%b6%89%e5%8f%8a-%e7%94%a8%e6%88%b7%e6%8e%92%e8%a1%8c%e6%a6%9c%ef%bc%88%e9%87%91%e5%b8%81%e6%b6%88%e8%b4%b9%e6%8e%92%e8%a1%8c%e6%a6%9c%ef%bc%89/


個人看法
第1次上線，系統全量統計，取TOP1000。
後續，白天，每小時近實時統計前TOP10000，重新整理TOP1000。理由是，正常的消費，當天的TOP1000，99.9%的概率，存在於前一天的TOP10000。
（如果不放心，當用戶一次消費大於一定金額，比如10000的時候，把此使用者id加入每小時近實時統計）
夜間，全量統計一次。


如果資料量特別大，每週全量統計一次。
採用遞增的統計方式，第1次上線全量統計，後續有消費行為的時候，傳送一個MQ訊息，累加到資料庫。


TOP1000和TOP10000等資料，快取到Redis中。


user amount
1   1000
2   900
3   800


全量統計可能沒有必要：如果按天統計，過去消費記錄，統計之後，幾乎不會再變化。只按天統計，累加也行。


總結：定期全量統計，小時統計+MQ訊息累加+快取。


建議：
上線統計所有，比如，截止到前1天1000消費。
每天，統計當天的，存到資料庫。
每天第1次查詢，取TOP10000快取到Redis，取TOP1000展示。
如果TOP10000，有消費MQ，實時累加，快取到Redis。
每天，夜間繼續統計前一天的。


是否有必要統計所有天數的，核對資料，看情況。


網友看法
hellocrest
對於資料量較大，並且易變的資料，可以將資料放入快取中。通過快取來實現排行榜功能，同時，還要保證快取與db中的資料一致。


夢朝思夕
我建議，可以分地區，這樣一個地區內的資料先排序好，這樣就可以減少排序時間，再將排序的地區，進行top K演算法，獲取先N個。