前阵子端午公司弄了个抽奖活动，然后我负责api的开发，需求如下：
- 前两天登录抽奖次数为1，第三天抽奖次数为3，每天抽奖次数清0；
- 抽到游戏礼包要返回礼包码；
- 抽奖时判断用户能否抽奖，包括注册天数大于1天，在活动时间内，抽奖次数不为0；
需求还是比较简单的，判断注册时间和活动时间都比较简单，讲讲怎样判断登录天数。
我是用当前登录时间-首次登录时间判断，但这样处理不了中间断登录的状况，项目赶着上，我直接根据日期判断，简单粗暴但如果活动持续时间比较长就不现实。结束项目后再想想其实可以用当前登录时间-上一次的登录时间来判断，>24小时就加1，否则就不操作，也不怕中间断掉的情况。
抽奖次数根据登录天数来判断，抽过奖的用户也会缓存已抽奖的次数，两者结合就能获取到用户剩余的抽奖次数。
抽奖涉及高并发，主要是奖品剩余1时，有多个用户同时点击。在抽中奖品减库存时加判断条件数量不为0，同时对抽奖使用事务，减库存不成功后就回滚。对抽奖动作加锁，在抽奖进行时不允许再抽，用redis可实现，可以避免连续点击多次或者使用多台设备同时点击而多次抽奖的情况。每次抽奖成功都incr抽奖次数，次数的缓存我是用time+user_id来做唯一标识。
虽然看似简单，但在开发过程还是踩了不少坑，技术水平是一个原因，还有粗心，害惨了我。在储存礼包码时卡壳了，抽奖后有返回礼包码，但数据库里礼包码都是空，检查半天代码哪里出问题，最后发现是数据表设计出问题，礼包码是字符串，我类型设成整型。
收获的东西也很多。首先是对访问安全的认识，不能相信客户端传过来的数据，访问数据都是可以伪造的，获取数据后一定要验证。也不能依赖客户端传的数据来做判断，要在服务端重新获取。然后是事务的使用，事务的原子性可以保证数据的一次完整提交，在修改数据库失败后能回滚，所以应该是在修改数据库的地方例如update,insert,delete后使用。
还有很多东西不懂，要学学redis和事务的更多使用。主要是第一次独立做项目，成就感还是满满的。
这篇博文也给了我挺多帮助：http://www.cnblogs.com/taijun/p/4040823.html#commentform 纪录一下。