任何事务的认识都有局限性,不管是历史上的还是技术上的,比如地心与日心,比如光的波粒二象性。因此,随着认知水平的提升,所处环境的改变等因素,我们对同一事物的理解也是不断发展的。就以本文为例,本文写在几个月以前,当时觉得还比较满意,但今天来看,就觉得应该再补充些东西。
不管网络上还是技术书籍上,关于高并发的内容不胜枚举,当然也有对高并发本质的论述。今天突发奇想要写的肯定也跳不出上述资料,但我并不想将那些资料罗列到一起来聊这个话题,我更想结合经验来聊个人的认识。
当我们查看招聘网上的职位时,几乎所有的职位都有一个共同的关键词--高并发。。。从网络大规模普及后,这个词也就成了程序员的标配。那么,当一个职位描述中出现“高并发”三个字时,用人单位到底想要的是什么呢?这其实要看我们从事的岗位。对于架构人员来说,要做的其实是如何以及更好的应对短时间内大量请求的涌入,而对于程序员来说,就是要保证代码在高并发情况下运行的正确性和鲁棒性。
高并发中的“高”字更多的还是体现在架构的设计方面,而在代码方面,“高”字则体现相对较少。因为支持并发的代码与不支持并发的代码在运行时存在着本质的差别,而高并发代码与并发代码间则没有本质差别,因为“高”字描述的是现象,而非一个确切的标准,即没有任何通用的标准定义:大于某值为高并发,小于则是低并发。代码层面上的高并发应对方案主要是利用线程或协程等技术,在保证正确性的前提下充分利用资源。
曾几何时,当一听到高并发三个字,我就会想到多线程,其实呢,格局小了。这只是在代码级别的一种应对方法而已。应对高并发是个系统工程,需要运用多种综合手段,从产品设计到系统架构再到代码开发,从业务策略到用户体验等等,都会影响到所采取的应对措施。我认为根据业务的不同,应对高并发总体上有两种策略,1.利用一切手段处理全部请求,不管是真处理还是假处理(降级--七伤拳,无论是打人的还是被打的,外表都要装着跟没事儿一样)。比如商业搜索引擎。2.只处理一部分有效请求。比如电商下单,当库存没有了,自然后续的下单请求也就不用处理了(这里之所以具体到下单,是因为电商的商品展示和查询仍像搜索引擎一样需要尽可能的处理全部请求)。
针对上述两种策略,就有了不同的处理方式,通过增加资源来实现第一种策略,当然最好是横向的。这自然就引入了分布式概念。通过各种手段过滤掉绝大多数请求来实现第二种策略。至于为什么是横向增加资源而不是纵向增加资源以及过滤请求的具体方法网上多如牛毛,所以就不在这详述了。
应对高并发和处理高并发是两码事,上述聊的是如何应对,也就是通过各种手段先把请求接进来,就算处理不了也先让发送请求方看不出什么明显的问题,比如在浏览页面时我们宁可看到一个错误提示,也不想看着空白页一直在那加载。应对高并发是为了性能,也可以说是为了用户体验,而处理高并发则是为了正确性,这当然也是用户体验的一部分,而且是最关键的那部分。一个反应迟钝但能给出正确计算结果的计算器,和一个反应灵敏但只能给出错误结果的计算器,你会选哪个?还是先搞笑吧,要是不搞笑那就太搞笑啦。
本文探讨了高并发背后的策略,从架构设计到代码实现,重点讲述了应对高并发的两种主要策略,并强调了性能与正确性的权衡。作者结合经验分享了分布式、降级策略等技术应用实例。
423

被折叠的 条评论
为什么被折叠?



