京东资深架构师：高性能高并发服务的瓶颈及突破思路

在大型的网站服务方案上,在各种合理拆分以后,数据拆分以及服务拆分支持扩展只是其中的一部分工作,之后还要根据需求看看是否需要引入缓存CDN之类的服务,我把这个叫做增长服务链路,原来直接打到数据库的请求,现在可能变成了先打到缓存再打到数据库,对整个服务链路长度来说是变长的,增长服务链路的原则主要是将越脆弱或者说越容易成为瓶颈的资源(比如数据库)放置在链路的越末端.

在增长完服务链路之后,还要尽量的缩短访问链路,比如可以在CDN层面就返回的就尽量不要继续往下走了,如果可以在缓存层面返回的就不要去访问数据库了,尽可能地让每次的访问链路变短,可以一步解决的事情就一步解决,可以两步解决的事情就不要走第三步,本质上是降低每次访问的资源消耗,尤其是越到链路的末端访问资源的消耗会越大.

比如获取一些产品的图片信息可以在访问链路的最前端使用CDN,将访问尽量挡住,如果CDN上没有命中,就继续往后端访问利用nginx等反向代理将访问打到相应的图片服务器上,而图片服务器本身又可以针对性的做一些访问优化等.

比如像价格等信息比较敏感,如果有更改可能需要立即生效需要直接访问最新的数据,但是如果让访问直接打到数据库中,数据库往往直接就打挂了,所以可以考虑在数据库之前引入redis等缓存服务,将访问打到缓存上,价格服务系统本身保证数据库和缓存的强一致,降低对数据库的访问压力.

在极端情况下,数据量虽然不是特别大,几十台缓存机器就可以抗住,但访问量可能会非常大,可以将所有的数据都放在缓存中,如果缓存有异常甚至都不用去访问数据库直接返回访问失败即可.

因为在访问量非常大的情况下,如果缓存挂了,访问直接打到数据库上,可能瞬间就把数据库打趴下了,所以在特定场景下可以考虑将缓存和数据库切开,服务只访问缓存,缓存失效重新从数据库中加载数据到缓存中再对外服务也是可以的,所以在实践中是可以灵活变通的.

4、小结

如何提升整体服务的性能及并发,一句话概括就是：

前面说的这些情况可以解决大访问量情况下的高并发问题,但是高性能最终还是要依赖单台应用的性能,如果单台应用性能在低访问量情况下性能已经成渣了,那部署再多机器也解决不了问题,所以接下来聊一下单台服务本身如果支持高性能高并发.

1、多线程/线程池方式

图3 版本一

以TCP server为例来展开说明,最简单的一个TCP server代码,版本一示例如图3所示.这种方式纯粹是一个示例,因为这个server启动以后只能接受一条连接,也就是只能跟一个客户端互动,且该连接断开以后,后续就连不上了,也就是这个server只能服务一次.

这个当然是不行的,于是就有了版本二如图4所示,版本二可以一次接受一条连接,并进行一些交互处理,当这条连接全部处理完以后才能继续下一条连接.

这个server相当于是串行的,没有并发可言,所以在版本二的基础上又演化出了版本三如图5所示.

?图4 版本二

图5 版本三

这其实是我们经常会接触到的一种模型,这种模型的特点是每连接每线程,MySQL 5.5以前用的就是这种模型,这种模型的特点是当有大量连接的时候会创建大量的线程,所以往往需要限制连接总数,如果不做限制可能会出现创建了大量的线程,很快就会将内存等资源耗干.

图6 版本四

另一个是当出现了大量的线程的时候,操作系统会有大量的cpu资源花费在线程间的上下文切换上,导致真正给业务提供服务的cpu资源比例反倒很小.同时,考虑到大多数时候即使有很多连接也并不代表所有的连接在同一个时刻都是活跃的,所以版本三又演化出了版本四,如图6所示,版本四的时候是很多的连接共享一个线程池,这些线程池里的线程数是固定的,这样就可以做到线程池里的一个线程同时服务多条连接了,MySQL 5.6之后采用的就是这种方式.

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!