分析如何支撑高并发?
花了2个小时思考和码字,觉得错误的,可以摒弃;觉得正确的,可以采纳;觉得还有更好的,希望能给出建议。
首先我们要理解什么是“高并发”这个概念,“支撑”的概念主要是目的目标。很多小伙伴面试可能问到这个问题,一上来就说方法,用redis缓存,数据库优化,主从复制,分库分表,还有什么微服务...,相信讲完,面试官可能说“哦~”完了。只讲结果,没去分析原因,人家很肯定知道你在背答案。这也能理解,我们平时很难有机会碰到高并发的项目。只要我们思考过,分析过,一定有所收获。
什么是“高并发”,我们可以从事物都是具有两面性的特性出发。有高,就有低;有并发,也有没并发。 低的时候我们的系统是如何的?高的时候我们的系统是如何的?如果低和高一样的,那肯定完完了。“高并发”就是保证我们的系统高可用性,如同正常(无并发)访问我们的站点一样,提供优质可用服务。
分析“高并发”,我们就要知道目前离高并发的差距是什么?刚才提到优质可用服务,提到高可用系统。在高可用系统的同时,可以能带来很多问题,增加管理的复杂性。所以画出系统图来分析。
箭头 + :A 增强 B增强
箭头 - :A 增强 B减弱
所以高并发不是凭空来的,是我们的优质服务产生的,服务好带来的流量大,这就要求我们保证我们系统高可用性,这样才能带来更多流量。但是什么事情都有个上限,高可用可能带来更多的设备机器设施,增加了我们的管理上的复杂性等问题。但是这些都是保证高可用性支撑高并发要解决的问题和优化的地方。
管理方面涉及东西太多了,本身项目管理的范围就已经够大了。这里不展开了。我们从高可用系统来分析下怎么解决高并发问题。
我这里从4个维度来展开,把它们有效的组合在一起形成了架构,如图:
看到这张图,大家可以集中注意力,怎么组合搭配,想想大流量网站是如何搭配组合的?在组合有效的基础上再进行作出方案。如果已经有组合的情况下(LNMP)我们可以去画图思考如何做好优化和执行方案。同时在业务的持续演进的时候保证系统的是否能支撑高并发以及系统高可用性。这里只是从整体去观察分析。具体怎么实现,在社区里面有很多同学给出了答案,没有最好的,确实是可行的。
推荐阅读:
你的系统如何支撑高并发?
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: