【架构师从入门到进阶】第三章：系统整体优化思路——第一节：整体优化思路

【架构师从入门到进阶】第三章系统整体优化思路——第一节整体优化思路大事化小前置处理后置处理加快处理本篇文章我们来看一下整体优化思路。这里面我整理了四个优化的思路大事化小前置处理后置处理加快处理什么意思呢一一给大家解释。首先我这里面给大家抛出一个问题平时我们所说的亿级流量的系统是如何做的是靠我们写代码吗大家觉得亿级流量靠写代码能实现吗你代码写的再精妙精妙到天上去了全世界就你的代码最精妙能实现亿级流量吗当然实现不了。因为你的代码再厉害也得在机器上跑你的机器就算再厉害厉害到天上了全世界最顶尖的机器了把代码布到你这台最顶尖的机器上能扛得住亿级流量吗举一个例子。双11的活动在十年前那一瞬间的流量都能拖垮一个中型城市的网络带宽。你把你的代码写的足够精妙部署在一台特别高配置的服务器上然后你服务器总得放在一个城市里吧你想想那一瞬间的流量把城市的网络都拖垮了你的服务器还能提供服务吗你的服务器就算再厉害服务也是提供不出去的因为网络出口卡了。所以说我们写代码是一方面写代码只是在我总结的这四句话里的最后一个方案里面写代码绝对不能算是亿级流量系统最核心的要素。所以说扛得住亿级流量的系统都是通过整体架构的设计来实现的并不是通过某个局部的优化就能实现的。我们需要从哪些方面去优化呢就是从用户使用我们系统开始到给用户响应我们都需要做优化。大事化小什么叫大事化小。首先如果有一亿的流量一亿个请求过来要请求我们的系统而我们的系统只能扛得住一个100万的并发。一亿个能分成多少个100万是不是100个100万那么我们用100个系统来承担是不是就把这么大的一个流量拆分成一个一个小的流量这不是就能扛得住了吗当然这只是很简单的说了一下这个例子包括我们后面的负载均衡、分库分表、分区读写、分片、集群等等这些都是大事化小。前置处理什么叫前置处理呢比如说我这有1000个请求但是我的服务端呢只能处理100个请求。那么我这个业务有一个很特殊的点这个特殊的点是什么呢就是这只有这100个请求是写剩下的900个是查询并且查的数据都非常简单。那么为了扛得住我们是不是可以多布一个系统我们先拿五个系统把它接住然后现在我们扛得住了500个并发。但是此时还有500个并发我们的系统是扛不住的。首先我们的系统原来都是去访问db的都要去db里经过多次的sql语句的查询才得出一个结果响应给这。但是我们发现我们的sql语句就是我们刚才所说的900个查询只查很简单的一个数据。那么我们是不是可以把这些要查询的数据放在缓存当中放在缓存当中这样的话十分之九的请求都能从缓存里得到响应是不是就不需要走复杂的SQL查询了是不是就提升了系统的整体性能了这样的处理方式是不是把底层的sql的操作前置到了缓存这就叫前置处理。后置处理什么叫后置处理比如说有1000个请求服务端只能处理800个那多出来的200个呢没有地方处理也没有服务器去部署也没有服务器去扩容那怎么办呢这个服务器把超出来的200个请求放到消息队列当中以后再慢慢处理先把这800个应付过去这200个没有处理是不是它的处理进行了后置等着流量的这个波峰过去之后可能一天也就出现这么一次剩下的都是20个请求。那么把这多出来的200个放到队列这里以后慢慢的去处理每次都是20个每次都是20个系统就能反应过来了。所以这个就是说把当时要处理的不处理把它放到队列里后续慢慢处理这个叫后置处理。加快处理把该前置处理的前置处理了该后置处理的后置处理了那么。确实到我这必须得处理我躲不掉了那么我加快处理。我怎么加快处理呢这才是我们所说的代码优化。能多线程就用多线程能在代码里合并的就合并能利用内存的就利用内存能利用CPU的就利用CPU。所以说当做到加快处理的时候我们就想尽一切的办法去优化我们的代码或者说调整我们业务逻辑。把代码重新写一下重新优化一下这个提升的空间也是有的。好这就是我们总结的四个思路大事化小前置处理后置处理加快处理。好本篇文章我们讲解到这里。