排行榜奖励发放

一般来说排行榜奖励都通过邮件来发放，要不就是对于在线用户直接发给用户自身，对于离线用户发到用户的离线邮箱，用户上线可以通过邮件取到。这样做简单直接，易于处理，也不容易出错，但是在用户很多的时候可能需要同一时间发送很多封邮件，给数据库造成很大压力。当然也可以通过分时发送来减轻同一时刻给数据库带来的压力，但这就要考虑到如果在没有全部分发完成的时候服务器出现问题的情况，总之难以从根本上解决问题。

为了减轻数据库的压力，同时防止数据的意外丢失，就需要一次性的把奖励发给所有用户或者存档到数据库中，按照这种需求自然会想到另外一种方案，就是把排行榜中所有的用户标识和名次打包存入到数据的一条或数条记录中，然后等到用户上线时再把记录中的奖励发给用户。数据库设计大概是这样的：

+----------+------------------+------+-----+---------+----------------+| 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就表明是重复奖励，这时不给予发放。