前不久陪朋友参加了一场教师面试，进入面试现场时，每个人都要扫描二维码进行排队。当时扫码的人挺多的，不一会，服务器就卡主了，一堆人就开始焦急起来，因为提交报名的马上就要截止。好在过了几分钟，又可以进行排队了。等这件事平息之后，就在思考了一下，其实这次的报名的并发不是很高，并发量在100内，但是偏偏这么点并发就可以使得服务器卡主，这个教师报名排队系统的开发可能需要思考下了。

      笔者不才，也曾开发过一个排队的功能。这个并发要远远高于前面的预约面试。这里阐述下我的实现思路，欢迎大家吐槽。

      首先，数据库设计，这里肯定有一个报名信息表，存储当前报名的开始时间、结束时间、报名标题等等。

报名信息表大概如下：

报名记录表大概如下：

      表设计很简单，报名记录表记录每一次报名的报名人和报名序号。一般这种不允许重复的数据，会在报名id、user_mobile、order三个字段上加上唯一索引，保证数据绝对不重复。

排序问题

      比较棘手的是这个排序问题，现在一般的项目都是集群部署，在确认当前人的序号时，存在并发问题。也就是存在多个人都争夺一个序号的问题。采用redis的incr命令可以更加友好的解决这一问题。

incr命令是原子增加1，并且将增加后的值返回。操作如下：

      通过这一命令在报名开始的时候设置值为0，然后每一个人报名时，都通过incr命令获取当前排名。

去重问题

      一般情况下，每个手机号在同一个报名场景中只允许报名一次。因此去重也是一个比较麻烦的问题。如果每次都去查询数据库有没有报名记录的话，也是一个很造嫌弃的操作。

      通过redis的bitmap数据结构可以更简单高效的实现数据的去重。也许会有人使用set或者hash。虽然HashSet和HashMap也同样能实现用户的去重和统计，但是如果使用HashSet和HashMap存储的话，每一个数据比如用户ID都要存成int，占4字节即32bit。而一个用户ID在Bitmap中只占一个bit，内存节省了32倍。

      通过此数据结构，不光可以去重，也可以处理黑名单。通过如此思路，实现起报名排队的功能速度会快很多。       思路大概是这样，欢迎大家吐槽哈。