现在做物联网三年了,总是有客户或者领导问你们的服务器能承受多少终端设备?支持多少并发?这个问题让我很难回答。 首先很多人不懂什么是并发,却总是在谈并发。第一年的时候,有个人让对服务器做压力测试,可是我们当时是测试阶段,租用的云服务器是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亿用户都没有问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据