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

实际在真正拆分的时候需要考虑具体的业务特点,比如像京东主站这种类型的网站,在用户在访问的时候除了加载基本信息以外,还有商品图片信息、价格信息、库存信息、购物车信息以及订单信息发票信息等,以及下单完成以后对应的分拣配送等配套的物流服务,这些都是可以拆成单独的服务,拆分以后各个服务各司其职也能做更好的优化.

服务拆分这件事情,打个不是特别恰当的比方,就好比上学时都是学习,但是分了很多的科目,高考的时候要看总分,有些同学会有偏科的现象,有些科成绩好有些科成绩差一点,因为分很多科目所以很容易知道自己哪科是比较强的、哪科是比较弱的,为了保证总体分数最优,一般在弱的科目上都需要多花点精力努力提高一下分数,不然总体分数不会太高.服务拆分也是同样的道理,拆分以后可以很容易知道哪个服务是整体服务的瓶颈,针对瓶颈服务再进行重点优化比等就可以比较容易的提升整体服务的能力.

3、适当增长服务链路,尽量缩短访问链路,降低单次访问的资源消耗

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

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

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

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

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

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

4、小结

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

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

1、多线程/线程池方式

图3 版本一

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

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

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

?图4 版本二

图5 版本三

（编辑：网站开发网_马鞍山站长网）

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