架构师面试（四十九）：直播问答系统架构

问题：

今天聊一个简单业务场景下【业务架构】的设计问题。

先来看业务背景：【直播问答】是2018年各大互联网平台兴起的一种吸引流量的运营活动，它是在视频直播的基础上增加了答题的玩法，具体怎么玩呢？

直播开始，主持人会先进行暖场，然后主持人开始出题；每一场直播下来，总共是有12道题目；每一次系统只下发一道题到用户的手机APP上；而用户的答题时间只有10s，只有按时提交答案并且答对的情况下，才能继续作答，否则只能观看直播了。每一道题，在作答时间结束20秒左右（这个时间由主持人把控）之后，会由系统下发答案和统计数据（包括多少人答对，多少人答错，多少人选择了A、多少人选择C......），12道题全部答对即可平分本场奖金。

整个流程很简单，为了帮助大家更好地把控整个过程，见下图。

【视频推流】是视频直播；【题目下发、题目作答、答案及统计数据下发】是针对一道题目的三次交互过程，12道题目需要有12次循环过程；12道题目完成之后，最后才会【支付奖金】。

今天的问题是：在有500万用户同时在线和答题的情况下，这个【直播问答系统】的架构应该如何设计？如果你是该系统的架构师，你会考虑哪些核心问题呢？

解析：

作为一名架构师，要对一个复杂系统做架构设计，首先要做的是对系统进行 “分解”，也就是解耦复杂性；解耦之后，面对一个简单的子系统时，设计其架构就非常容易了，同时要考虑的核心问题也就一目了然。

通过上面对【直播问答系统】流程的分析，我们可以将其拆分为三个独立的子系统：

1. 直播子系统：实现从服务端到客户端的视频推流；

2. 答题子系统：实现 “两个下发” 和 “一个作答” ， 两个下发是 题目下发和答案及统计数据的下发，一个作答是客户端题目作答；

3. 支付子系统：对12道题目全部答对的用户，实现对其奖金支付。

【直播子系统】【答题子系统】【支付子系统】是三个从功能和职责上完全独立的子系统；【直播子系统】是基础设施，【答题子系统】实现客户端与服务端的交互，【支付子系统】是直播完成后系统的一个异步化行为。我们将注意力再分别放在这三个子系统的实现上，整体的设计难度就大大降低了。

再考虑【在有500万用户同时在线和答题的情况下......】这个点，突出该系统需要具备高并发的能力，并且在500万用户的情况下，答题接口仍然需要具备很高的性能；总结一句就是：实现高并发和高性能的系统架构。

要实现高并发高性能的系统，惯用的思路就是 【减压】，通过各种方式减轻压力，降低负载；比如：横向扩展机器，通过多个机器节点的共同计算，降低每一个机器节点的压力；减少IO操作，包括磁盘IO和网络IO，提高每一个请求处理的效率。

分析到这里，我们结合着问题再总结一下。

问题是：在有500万用户同时在线和答题的情况下，这个【直播问答系统】的架构应该如何设计？

解决思路是：【解耦】和【减压】，通过分解复杂系统，降低其复杂性，通过减压，实现系统的高并发和高性能。

按这样的思路分析完成后，该【直播问答系统】的整体架构设计见下图。

首先客户端 APP 与后端系统采用了多通道的的通信方式：

1. 直播通道：直播通道用于视频推流；直播通道的实现可以通过集成第三方来快速实现，比如集成腾讯云直播；

2. 下发通道：下发通道用于服务端下发题目和下发答案及统计数据到客户端，这是一个服务端 push 行为，所以一般基于长连接协议进行实现；有 IM 系统研发经验的同学对此应该理解更深；在系统架构中，由【题目服务】将下发的数据分发给 【Entry】集群，然后【Entry】集群基于下发通道将数据 push 到所有的客户端；

3. 上传通道：上传通道用于客户端用户进行题目作答，这是一个数据上传的行为，为了降低服务端压力，采用短连接协议进行实现；在系统架构中，客户端提交题目答案，最终由【答题服务】进行业务处理。               

【直播通道】由 “直播子系统” 进行实现；【下发通道】和【上传通道】由 “答题子系统” 进行实现。

整个系统为什么要采用多通道的设计方式呢？还是回归到【解耦】和【减压】的设计思路上，通过多通道拆分了不同的功能，实现了不同功能的解耦，同时降低了通信通道的压力；“答题子系统” 中的【题目服务】只是在人工的触发下实现数据的分发，没有任何负载上的压力，【答题服务】要在10秒内接受500万次的答案提交请求，压力较大，所以通过拆分【题目服务】和【答题服务】，实现【下发通道】和【上传通道】的分离是非常有必要的。                            

最后 “支付子系统” 由 【后台服务】进行异步化实现，这一环节没有负载压力，只要保证逻辑准确即可。                                                     

在该系统架构中，【Redis】用来实现每道题目作答情况的统计，比如：题目1有300万人选择了A选项，有150万人选择了B选项，有50万人选择了C选项；【MySQL】用来持久化存储12道题目和答案，以及每位用户的作答情况等。

系统架构分析到这里，不难发现：【答题服务】是功能逻辑最复杂和压力负载最大的服务，也是作为架构师需要考虑的核心问题所在；【直播问答系统】需要考虑哪些核心问题呢？

1. 判题逻辑如何实现？

【答题服务】怎样对用户提交的答案进行快速判断呢？要知道，用户有10秒的作答时间，通常提交作答集中在4~9这5秒内，即5秒时间内有500万用户的答案进行提交，【答题服务】必须快速做出判决。

2. 淘汰用户如何识别？

已经作答错误的用户，不能继续进行答题，怎样标识和快速识别出已经淘汰掉的用户呢？

3. 如何防止用户作弊？

“上有政策，下有对策”，黑客的作弊手段是层出不穷的；比如，题目3比较难，用户超时没有作答，在题目4下发后，用户提交了答案，【答题服务】怎么识别这种跳题行为呢？再比如，当用户已经答错一道题目，但该客户端还在继续作答，【答题服务】如何识别这种行为呢？还有一种情况，因为每道题目都有A、B、C三个选项，用户对每道题目都分别提交三个答案，【答题服务】应该如何处理呢？

4. 怎样快速统计数据？

每一道题目下发到客户端后，随着用户提交作答，【答题服务】需要快速统计出每道题目的作答情况：多少人答对，多少人答错，多少人选择了A，多少人选择了B，多少人选择了C。

这四个问题就是【直播问答系统】的架构师需要重点考虑的核心问题！（每个问题如何解决，我们后续分析。）

祝大家阖家团圆，中秋快乐！