最近在做关于公司的一个社区的项目，在其中用到了一些业务模式，对这些模式的应用做一个简单的总结。
这是一个类似滴滴的抢单模式的项目， 对于抢单模式的实现做一个小小的总结。
主要用到了三个表,问题表q,问题流转表q_flow,答案表a。
q表
| question_id | user_id | status | time_out |
| 5 | 100393 | 0 | 2018-02-02 |
其中对q表的字段介绍，user_id标识是否需要分配给指定的回答者，status有两个状态，0：未分配状态，1:已分配状态
还有一个字段time_out用来记录超时时间。如果需要指定给人抢单，则多出一个字段assign_user_id。
q_flow表
| question_id | question_user_id | answer_user_id | flow_stasus |
| 5 | 100393 | 10001 | 0 |
| 5 | 100393 | 10002 | 0 |
| 5 | 100393 | 10003 | 0 |
表q_flow也有几个字段，对这几个字段的值说明一下，question_id为问题ID，question_user_id为提问用户ID，answer_user_id为流转用户ID，flow_status有几种状态，0:待抢答，1：已被抢答，2:已抢未答，3:放弃，4:超时，9:已回答
a表的字段
| answer_id | question_id | question_user_id | answer_user_id | content |
| 1 | 5 | 100393 | 10002 | 哈哈哈哈 |
抢单的简要流程为：
1.提单，用户向系统提交问题，系统将用户的问题设置为待抢答状态，q表的status状态为0，q_flow表中没有记录
2.发单，系统通过指定的分配策略，将用户提交的问题分发给若干个回答者，每个回答者在flow_status中对应一条记录，这时候
每条记录的flow_status的状态都为0
3.抢单，回答者(假定为10002)点击抢单操作触发抢单，抢单后q表中国的status状态置为1，q_flow表中对应抢单者10002的那条记录的flow_status状态置为2(已抢未答)，其他的同一批次的10001,10003记录的flow_status的状态置为1(已被抢答)，同一批次中只能有一条记录的状态为2
4.回答，回答者10002抢单以后可以有三种操作：放弃，回答，一直等待到超时
正常为回答，抢单者回答以后，其对应的10002的记录的flow_status的状态置为9，同时答案表中插入一条记录。