memetao / mcg Goto Github PK

将mysql中的部分数据移到redis上

不包括选课撮合逻辑，撮合逻辑应该独立成插件的形式。

在仓库的wiki页面整理出选课的业务逻辑，不必完全跟学校真实情况一样，但是开发过程必须按着这个逻辑，统一开发。

尽快和后端确定请求参数，如：
获取首页信息、提交选课结果等。

数据库有两个表:

1. 学生课程表
2. 课程剩余人数表
   （详细表结构字段见 database/v0.2.sql)

通过之前的测试我们发现，数据库的瓶颈在“更新”这两个表上，导致系统的选课性能卡在1000/S。现在希望通过“分库”的**将系统的选课性能提高到3000/S。具体操作为：

按照二级学院分库，比如信息、量新、人文等每一个学院一个数据库，每个数据库都拥有上述的两张表，保存着自己学院的学生课程信息、自己学院发布的选修课剩余信息。当有某个选课请求到达，比如A学生选择B学院发布的一门选修课C，涉及的主要操作是：

1. 找到A学生的课程表所在的数据库，将C课程插入到A学生的课程表中。
2. 找到C课程所在的数据库，将剩余人数--

这个任务要负责的内容是：散列sql请求到相应的数据库上。
要求完成时间：6.10前。

此前画的选课系统时序图有许多纰漏，需要重新画一张，作为系统设计的依据。

每个人都可以试着设计前端页面，画画草稿都行，可以作为一项长期工作。这个最没有统一标准，以自身感受为主。

现有的登录方案涉及到跨域问题，登录接口连同学校的认证服务，都需要改动

根据选课逻辑和系统架构，设计数据库存储结构。

比如获取课程信息、根据课程id查询该学生的课程时间是否冲突等等函数