简介：
1. 这个项目是青少年速算实时竞赛的应用，涵盖了赛程配置、自动题目生成、选手报名、实时比赛等功能。
2. 比赛组委会可以在系统设定比赛项目规则，如得分规则、题目生成难度等，系统根据用户设定的规则自动生成题目，用户可以预览题目，并且在生成题目的基础上进行微调 。
3. 选手通过报名端进行分组报名，可以在app中进行训练，比在比赛当天使用APP进行实时比赛，可以后台进行比赛进程的管理以及比赛选手状况监控，和比赛结束后提供数据统计服务。
4. 我在项目中担任开发组长的职责，负责搭建项目基础框架，以及核心的比赛监控模块的实现。

技术难点：
1. 这个项目比赛核心的攻克关有两个，一个是题目生成模块，需要根据用户参数配置，生成与之符合的速算题目，其次是能够与选手端APP和后台管理端PC实时交互和数据状态同步的中控台模块。
2. 题目生成模块在逻辑上其实没有什么难度，无非就是根据需求生成对应的题目，难点主要在于怎么把代码分层次编排，便于后期维护以及降低bug排查难度。这里我主要使用工厂模式，根据不同的情况返回题目实例。
3. 比赛监控通讯模块是比较复杂的模块，要求PC端能监控APP选手端的状态，PC端能够发布命令到APP，并且比赛在不同的阶段有不同的行为和操作。
3.1. 使用了事件监控机制。监控台的一切操作皆定义为事件，因为同一个操作有可能触发点在完全不同的地方，使用事件监控机制有效降低了不同类之间的耦合关系。
3.2. 比赛阶段管理使用了状态机（Statemachine）。状态机使得状态之间的转移、事件的触发，这些复杂机制的编排变得容易，并且便于维护。状态机在不同的阶段会发布不同的事件，同一个事件，事件监听者可以根据状态机（也就是比赛阶段）的当前状态作出不同的反应，实现了状态中心化管理。
3.3. PC端和APP端通讯使用的是websocket和stomp的实时通讯协议。中控台的数据为websocket主动发送，并非前端主动请求，这样后端可以根据比赛阶段的不同向前端发送对应的数据，让前端根据比赛阶段渲染不同的页面。比赛监控台可以向APP端发布命令也是通过websocket向APP端发送消息来实现的。
3.4. 使用了Spring的ApplicationContext的父子继承功能。因为有可能在比赛有可能会同时进行，为了实现数据隔离，ApplicationContext的父子继承功能，这样既可以利用Spring容器装配和自动配置类的便利性，同时类的处理上能够只考虑当前比赛的环境，使用相对简单清晰的代码来编写业务功能，而不需要担心数据污染的问题。
3.5. 适配Redis内存模式。在功能开发完成后，使用了装饰者模式为比赛监控台提供了Redis支持，使得系统能够以集群模式部署。就是原本读写数据的方式是读取本地内存，通过装饰者模式让类数据读写方式变成了读写Redis。