谢谢各位，有了大概的思路了

不错不错，一直对这方面很感兴趣，谢谢楼主

@pine 哦，总算是理解了，你说 mb_convert_encoding 不是这么用的是什么意思啊？

@lynnworld 试了下，结果如下：
echo mb_convert_encoding('小春子', 'UTF-8', 'GB18030');
echo mb_convert_encoding('灏忔槬瀛', 'GB18030', 'UTF-8');
echo mb_convert_encoding(mb_convert_encoding('小春子', 'UTF-8', 'GB18030'), 'GB18030', 'UTF-8');

运行结果是：
灏忔槬瀛小春��小春��

真是太奇怪了

@cxbig 明白了，谢谢

逼格

@greenmoon55 redis 在里面扮演了什么角色呢？

@sunjiayao 是的。但是是可以发散开来看的，主要想讨论高并发的问题，不止只针对我的问题

@jonemao 按照你的思路，我想了想，其实完全可以在每个用户过来时生成一个随机数，随机数满足一定条件的时候才给他京东券，这从一定程度上回过滤掉大部分的用户请求，哈哈。不过觉得更好的方式是用 redis 的计数器去过滤

@sunshinez1128 能深入讲一下吗？很感兴趣

@realpg 对了，我当时使用的数据库是 mongodb ，不是 mysql ， select for update 是 nosql 数据库没有的吧？

@realpg select for update 是什么意思？我是第一次处理类似这样的情景，没什么经验

@jonemao 你所说的公平级别是什么意思？没听懂哦

@billlee 那像京东等大型电商网站那种量级的网站时，你的这种方案未必可行吧？估计是撑不住的

@billlee 方案不错，我是先 select 再 update ，而你的出发点则是先 update 再进行 select ，可以有效避免我所遇到的问题，关于方案二为什么要将用户 id 和券 id 对应关系存到 redis 里面就是担心出现写数据库超时的问题，如果数据出错了的话，还是可以从 redis 里面拿到数据的，就不必将券还给券池

@Karblue 也许吧，很多时候自学了很多东西，却发现都用不上，等过了一阵子，发现有些地方用的上的时候，又发现自己都忘光了，又得从来，这个比较坑爹

个人感觉公用的类库写测试想对容易，业务代码要写测试就比较难了

@unique 神马帖子，贴下地址，让大伙看看

@sivacohan 你这个说法让人感觉写单元测试和公司倒闭有什么必然的联系似得（笑）