慕容愁 慕容愁
关注数: 3 粉丝数: 185 发帖数: 9,132 关注贴吧数: 96
给喷子们分析分析你们为什么那么自信却还没抢到盒子 那些抢不到七夕盒子的这次总算有理由闹事了,什么服务器延迟1秒了,什么购买异常了等等。。。等等。。。 我要告诉你们,购买异常,这是服务器后台代码的正常流程。 虽然我是做web开发的,属于浏览器——服务器架构,但是浏览器——服务器架构 本质上也是客户端——服务器架构,所以下面我来给你们分析分析。 服务器在1秒内甚至更短的时间内,收到了上万条甚至十几万条的购买请求,这些请求几乎是同时发出的,所以在这些请求发出的时候,服务器上盒子数量还是有的,就算没有,也没时间通知客户端。所以这些请求都能够成功发出。 在服务器收到这些请求以后,对于每个请求启动一个线程处理,然后进入购买事务 (事务具有一致性,一个事务里的所有代码要么全部执行成功,要么全部不成功,假如有一步异常,前面执行过的代码全部回滚) 首先扣除通宝,然后判断盒子存货量是否充足,如果充足,就给客户端返回购买成功的结果,也就是盒子到包里了,事务成功结束。如果盒子存货量不足,流程进入异常代码块,给客户端返回异常信息,并且事务回滚(就是前面扣除通宝的操作会回滚),还有注意这里给客户端的提示信息是程序员自己写的,我可以写服务器异常,也可以给你提示其它的很友好的信息,所以如果这次你们觉得不爽,或许下次他们就给你们写个非常友好的提示:“”非常抱歉,盒子已经售罄,下次请早“” 那么为什么上万条请求同时到达服务器,有的就能买到,有的就买不到呢,这个就看运气了,线程的处理机制是抢占性的(抢占CPU资源),是有随机性的,谁抢到谁执行。因为CPU资源有限,不可能同时处理几万甚至十几万个线程,哪个线程先抢到就能快其它线程一步,抢先执行那条判断盒子是否还有余量的代码,而这条代码为了避免上万条请求同时通过判断,肯定是做了线程同步的,就是同一时间只能一个线程来执行这条代码,所以这就得看运气了,哪个线程先抢到就可以顺利进入下面的流程,而那些后抢到的线程只能遗憾的进入异常处理流程了。 当然我这里说的只是一个大概的流程,具体的细节肯定比这要复杂的多,还有各种安全机制的考虑,优化呀,分布式呀等等等等,但是说到底,这些都是计算机系统的硬件机制和软件机制所决定的,手速快的,网络没问题的,还没抢到的也只能怪你们自己的运气了,程序员也没办法给你们背锅。 总而言之,就算你手速网速非常牛X,也不要盲目自信,在超大量人同时抢购的时候,最后能否抢到除了自己这边做到极致外,还要看运气。
首页 1 2 3 4 5 6 下一页