并发与食堂的关系

现在做物联网三年了，总是有客户或者领导问你们的服务器能承受多少终端设备？支持多少并发？这个问题让我很难回答。

 

首先很多人不懂什么是并发，却总是在谈并发。第一年的时候，有个人让对服务器做压力测试，可是我们当时是测试阶段，租用的云服务器是1核2G的，我说有什么可测试的，我们是要测试云服务商，还是测试自己的软件呢？我也问了其他的朋友，他们说能支持多少设备和业务有关。还有一次和一个其他专业的教授讨论，我说和内存有关，他说内存无限的情况呢？我就想起了阿凡提，天上的星星有几颗，我们就能支持多少物联网设备,他还不相信。我说内存无限就排队啊，只有用户能等，再多的请求处理一小时不够就一天，总之能处理完。

 

现在经过三年的实践，我也对并发渐渐有了一些理解，我觉得不能离开硬件资源去谈并发，尤其是内存。我们一般关注的是并发请求，对于Web服务一般都是不保持连接的，一应一答，所以我们一般关注QPS与TPS。物联网有两种一种是不需要控制的可以用HTTP或者UDP，也可以只关注QPS，另外一种是需要控制的，终端和服务器建立的是长连接，我们应该关注最大的长连接数，都是和内存紧密相关的，无论是同步多线程模型还是异步单线程模型，增加一个连接必然增加内存消耗，除此之外，TPS也很重要。 互联网以及物联网服务端应该具有水平扩展的能力，一个服务器处理不了，十个服务器行不行，一百个行不行。或者说是，一个人写的什么服务算法多么厉害，把原来100台服务器做的事，50台就完成了，这样才体现了他的算法多么好。我也成功把外包公司的代码与架构，改进成了在负载均衡下能够水平扩展的架构，我给别人说就是nginx说自己能支持10万长连接，我们依赖nginx也能支持10万长连接，后端服务器我们现在只有2台，随着业务扩展可以再买，这样最起码我遇到别人的问题可以应答如流，而且能够自圆其说，但是我还是觉得很难让没有实践过的人明白这个道理。

 

终于有一天在食堂排队的时候，我想到了，并发请求用食堂的例子解释是非常生动的。食堂就像是我们整个系统(服务器集群)，有好几个打饭窗口（服务器），每个窗口有2~4名打饭员工（CPU核心），每个队列最多排到墙边然后再绕几圈就站不下了（内存有限）。假设600员工12点下班吃饭涌入食堂（并发请求），员工自发的寻找窗口排队（随机的负载均衡），很明显，一个打饭的服务员只能服务一个人（并行处理数），打饭很快，一个人打完就走了，就可以第二个人打饭（并发）。正常情况是所有人有序打饭，下午13点前所有人都吃完了，也就是我们常说的食堂支持1个小时600人就餐，（并发数，可以计算平均每秒的TPS与QPS)。有一种情况是，人太多了，有的人下午13点上班的时候还吃不上饭，说明食堂设计不够（并发数太小）。夸张的情况是，如果瞬时人特别多，把食堂门挤爆了（负载均衡挂了），人太多了把地面压塌了（服务挂了），领导发话食堂暂停营业（停机或者重启）。当然了，这不太可能发生，因为有的人看到排队特别长，准备过会儿才来，或者去外边饭馆吃（用户无法忍受点击了取消），这也是我们不想看到的，所以食堂领导可能会安排一个人在那里维护秩序，看到队列人太多了就对外边的员工说，说现在人太多了，你们再停10分钟来吧（503错误）。如果想满足更多的员工吃上饭，首先是选用干活利索的员工，不要用算数不好的，手脚哆嗦的（提高CPU性能），合理安排菜的顺序减少连个员工胳膊打架（优化算法，减少死锁），然后一个窗口能多加员工的加一个（云服务器升级CPU），把一些桌子挪走让员工排队（云服务器升级内存）。但这样毕竟提升有限，因为人再左右开工也快不到哪里去，窗口站3个人已经很拥挤了（单机提升能力有限，且越来越昂贵），所以我们要多开窗口（水平扩展加服务器），让更多的窗口打饭，甚至是开一个新食堂（增加一个新的集群，在域名那一级别调度，或者用CDN）。这样我们就能很好的理解并发这件事了，也对自己的系统有了信心，只要你有钱，全地球60亿用户都没有问题。