新的一年已经拉开了序幕，有的忙着离职、有的忙着请求加薪，有的忙着春运，有人忙着相亲。。
对于绝大多数人来说，新的一年就是新的开始，新的开始也就是雄心壮志立flag的之时，只求不恍惚间到年尾，然后再把去年的flag，copy一次。
千里之行，始于足下。所以，我的雄心壮志，也从这简简单单的知识分享开始。
说到知识分享，就不能不提去年年底大火的直播答题app，不过，随着时间的推移，貌似热度已渐减。作为一个不算资深的程序猿，当别人为了冲关成功而欣喜，为了失败而失落时，我觉得程序猿们应该有透过现象看本质的想法与能力，正如，不以物喜，不以己悲。
废话不多少，好文刚出锅，大家趁热食用。
01
本次我分享的是小程序版好友对战答题的实现思路与具体方法，由于篇幅问题，我将分成多个小段进行分享。首先我们先来分析下需求流程。
首先，用户进入小程序。有两个选择，一，发起挑战；二.围观对战，选择围观对战则随机进入一个正在对战的房间，成为围观观众。选择发起挑战，则服务端生成一个房间号，然后触发分享操作，携带生成的房间号，由用户选择分享给好友或者微信群。
微信用户通过分享的卡片进入小程序后，可选择参战或者围观，如果已经选择参战了，则其他用户自动成为围观用户。此时，发起方的页面状态由等待好友响应变为等待开始。在发起方单击开始之前，参战的用户可选择退出参战，此时，任意一个围观用户则可以选择参战。
答题正式开始时，每道题有10s的时间回答。答错，或者超时，均认为答题错误，则不加分。答对，则根据答题用时，(11-所用秒数)*10的公式进行加分，每题满分100（留了1s时间，用户客户端和服务端之间的通讯耗时，以及客户端渲染题目所需要的时间），最后一题双倍分数。
02
下面说下程序的实现逻辑：
程序分为两部分，小程序端和服务端。为了满足答题的及时性以及用户体验，小程序与服务端间的通讯使用WebSocket。小程序端负责用户交互，展示返回的数据。
服务端负责处理用户创建房间、进入房间、围观、发弹幕的操作。
服务端的逻辑功能包括：处理围观用户的请求，围观用户的请求分为两种，随机围观和指定房间号围观，服务端根据用户请求数据中是否包含房间号进行判断，如果不含，则随机进入正在进行中的对战房间进行围观。
处理围观用户发弹幕请求。用户在答题过程中，围观用户可进行交流评论，然后以弹幕的形式实时显示在界面中。
处理用户发起挑战的请求。用户发起挑战，则生成一个房间号，存储在数据库，并返回给请求用户。
处理应战用户请求。用户点击应战按钮后，设置当前房间状态为配对成功，其他用户则不能再发起此房间的挑战。
处理放弃挑战请求。与应战操作逻辑相反。
处理房主点击开始请求。房主点击开始后，服务端随机从数据库中抽取有效的题目。并每隔11s（考虑到客户端与服务端之间的通讯耗时和客户端页面渲染耗时），推送新的题目，直到答题完毕。
处理用户提交答案请求。用户提交答案时，从数据库（或缓存）中匹配答案，正确时，则根据耗时，计算本轮分数，另外，需要将答题结果推送给围观用户。错误时，则将正确答案推送给答题者。
处理用户超时未答。当服务端在11秒内未收到提交的答题请求，则自动判断答题超时，将正确答案推送给超时用户。
03
数据库中，跟题目相关的表有两个，一个是题库表，一个是每个对战房间的题目表。表结构如下：
题库表：
列名
类型
说明
Id
int
主键，唯一标识
CreateTime
DateTime
题目的创建时间
Title
Nvarchar
标题
Options
Nvarchar
答案选项
Status
int
是否可用，默认1，可用。0为不可用
Level
int
难易程度，值越大越难
试卷表：
列名
类型
说明
Id
int
主键，唯一标识
Title
Nvarchar
标题
Options
Nvarchar
答案选项
Answer
int
答案的序号。从1开始。
Level
int
难易程度，值越大越难
HomeId
int
房间号
SubjectId
int
题库编号