谈谈图书馆座位管理系统今日崩溃

谈谈图书馆座位管理系统今日崩溃:

1.前天约的第二天位置，今天8:30之前要签到，否则会关闭。这就导致了8:30之前的网络拥塞（有人害怕违约要取消再预约，有人在当“老六”捡漏）。再加上今天早上大一考四级，交通拥堵，潜在违约的人更多（包括我）。于是预约系统在短时间（周期为几秒，每个人都在疯狂刷新）内承受上千并发量（对于一个学校的系统来说不少了）。

2.经过30分钟的观察，发现预约系统在面对高并发的情况下并不能很好地应对，在不能保证高性能的前提下还出现了一些较为离谱的错误:

• 数据不一致性：我自己明明已经违约，在8：41终于刷到一个座位的时候竟然显示该用户在该时间段已有预约。结果去“我的预约”里面看了，发现之前的座位还是违约了。
• 一些闸机不能很好地记录用户的签到状态，也就是说在入口闸机处刷卡会准入，但是准入的信息并没有更新到数据库中。我在8点50左右预约了一个4A的位置，位置上坐了个考研老哥在复习，他应该是不知道自己违约了。果不其然，在交涉之后，他说明明已经签过到了，但座位还是关闭了（我的座位状态是使用中）。

猜测有以下原因：

• 准入和数据同步采用异步策略，也就是说只要闸机系统发送了请求包，闸机就会开门，不论请求包是否到达目的地。

• 闸机发送所在的系统发送的网络包在传输到数据库服务器的过程中发生丢失。

• 请求包过多，在调度的时候一些请求包因为时间过长没有被处理而被舍弃。

• 请求包到达了数据库服务器，但是在服务器端发生了丢失/变更，这种情况可能是因为数据库在提交事务的过程中出现了错误，导致事务回滚。

• 最离谱的一个错误：座位的轮回

前面提到了我在4A“请走”了一个考研老哥（那个时候我的座位状态是使用中）。过了几分钟，正当我打开电脑的时候，一个女生走过来：“同学，这是你约的位置吗？”，我顿时一激灵，看了系统，座位状态显示已使用（合着我在掏书的时候还能分身去出口签个离）。于是只能灰溜溜地收拾东西，道个歉跑路。想了想，可能有两个原因：

• 超卖：一个座位同时给两个人预约到了，即在数据库端出现了幻读。
• 权限：谁把我的座位释放掉了…

3.总结：学校的一些系统确实不行，有的系统可以用拉跨形容。如果将来有能力，一定完善这个系统，这样我就不用坐在一楼的免预约座位上冻得人模狗样（：））