排行榜獎勵發放

一般來說排行榜獎勵都通過郵件來發放，要不就是對於在線用戶直接發給用戶自身，對於離線用戶發到用戶的離線郵箱，用戶上線可以通過郵件取到。這樣做簡單直接，易於處理，也不容易出錯，但是在用戶很多的時候可能需要同一時間發送很多封郵件，給數據庫造成很大壓力。當然也可以通過分時發送來減輕同一時刻給數據庫帶來的壓力，但這就要考慮到如果在沒有全部分發完成的時候服務器出現問題的情況，總之難以從根本上解決問題。

爲了減輕數據庫的壓力，同時防止數據的意外丟失，就需要一次性的把獎勵發給所有用戶或者存檔到數據庫中，按照這種需求自然會想到另外一種方案，就是把排行榜中所有的用戶標識和名次打包存入到數據的一條或數條記錄中，然後等到用戶上線時再把記錄中的獎勵發給用戶。數據庫設計大概是這樣的：

+----------+------------------+------+-----+---------+----------------+
| Field    | Type             | Null | Key | Default | Extra          |
+----------+------------------+------+-----+---------+----------------+
| ranktype | int(10) unsigned | NO   |     | NULL    |                |
| id       | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| time     | int(10) unsigned | NO   |     | NULL    |                |
| rewards  | blob             | YES  |     | NULL    |                |
+----------+------------------+------+-----+---------+----------------+

ranktype(排行榜類型)，reward存儲多個用戶標識(一般爲id)和用戶名次，id(獎勵id，唯一標識記錄並且自增長)，time(獎勵發放時間)

如果名次太多也可以分爲多列或者多行來存儲，儘量維持在幾條，方便對數據庫進行一次性插入。當服務器啓動時把表中的所有數據讀取到內存，在內存中構建用戶到獎勵的映射，用戶上線時通過這個映射把獎勵再發給用戶，這樣就達到了分時發放獎勵的效果。

仔細分析會發現這樣做也有一點風險，就是如果把獎勵放給用戶了，但是由於某種原因這條數據庫記錄修改沒保存到數據庫，這樣就會造成獎勵的多次發放。或者先保存修改之後再發放獎勵，這樣也會可能產生有用戶沒有收到獎勵的情形。所以爲了保險，應該在用戶自己的數據中存儲一條數據來記錄該用戶目前已經領到哪天的排行榜獎勵了，這樣如果發生了多次發放獎勵的情況可以根據用戶自身的數據來判斷出來，防止了此類情況的發生。由於id字段是自增長的，所以只需要在發放獎勵時把最新(最大)的id記錄到用戶身上，並且拿獎勵id與用戶原有獎勵id進行比較，如果小於等於用戶原有獎勵id就表明是重複獎勵，這時不給予發放。