关于大学选课系统高并发问题的简单思考

大学选课系统，设计存在大量问题
在高并发的时候，必然导致选课困难
故优化如下

1.节省网络带宽
2.节省磁盘IO
3.提高CPU利用率

如何节省网络带宽
现有代码，每次http请求返回的都是完整的html报文，非常占用网络带宽
修改为前后端分离，每次返回增量的json报文，可以大幅提升带宽利用率
举个例子，原来是每次交互都要返回20k的html报文，现在只需要返回2K的json，提升了10倍的容量

第二步，通过cloudflare提供的ngx_brotli_module对数据压缩传输，进一步提升带宽利用率
假设学校使用的是6类网线+千兆交换机
那么上行带宽按1000Mbps计算
每次请求占用了2kb流量,那么理论上足以抗住5万的并发
学校学生按15万人算，基本满足需求了【超过15万人学生的大学，就应该拆分！】

如何节省磁盘IO
首先对于热点数据，用redis做缓存，数据都从内存走，而不是直接访问数据库
redis的数据应该保存 【key = 课程的id，value = 还剩多少名额】，服务每次从redis读取和更新名额数据，而不是数据库。
另外，课程id和课程名字，导师名字，学分，等不会改变的数据，应该在服务启动的时候，内存里建好结构化，数据直接在内存里读取，而不是从数据库读取
这样，可以大幅降低对数据库的IO消耗
简单讲，如果是固定的数据，就内存里存好。如果是会变动的数据，就用redis存。尽量减少对数据库的磁盘IO。

第二步，用update代替insert
正常选课代码，应该是学生选好课程以后，往数据库执行insert操作，让数据库记录学生选了什么课程
因为高并发的情况下，insert太多，磁盘io消耗非常大
所以用更省io的update
具体如下
在选课开始前几天，就批量往数据库insert好所有学生的选课记录，不过都是空记录
在选课的时候，只要执行update就可以了！
这可以高效提升数据库的IO，有3倍提升的效果！

最后是对数据库分库分表
我建议，5万的并发下去update数据库压力还是太大了
建议用两个数据库服务器
每个数据库服务器负责2个学年的学生
比如数据库A服务 2020/2019两个年级，
数据库B负责2018/2017 两个学年的学生
这样，每个数据库只需要负责2.5万的并发请求【如果还是扛不住，就一个学年一个数据库，分4个】


如何提高CPU利用率

前后端分离，所以数据都是json
为了提升json的处理效率，使用simdjson
可以在json的处理上，提升10倍的速度



先想到这么多
想到其他的继续优化