​​​​​​​系统架构演变

1、一代架构图

一台机器上即部署了应用程序又部署了数据库，db会影响应用的性能，应用程序也会影响db性能，两者相互干扰

                 

2、二代架构图

一个应用程序，一个db，两台机器分开

        

3、三代架构图

   随着网络的发展，用户量也越来越大，此时继续沿用二代架构图会导致，server服务器扛不住，于是衍生出三代架构图，如下。

   ngnix接受用户请求后，ngnix并不自己处理，而是把请求分发给后面的server让server去处理。用户请求时看到的是nginx的IP，nginx主要用来解决用户量大，请求大的问题。nginix后面的server是个集群，每个tomcat服务器都是一台机器。

    

4、四代架构图

随着用户并发量越来越大，根据流量漏斗原理知道，db的并发量也越来越大，db压力也越来越大。db也开始出现性能问题，为了解决数据库方面问题，衍生出如下的架构图。相对于3代架构图，差别在于增加：数据库读写分离、数据库主从。

读写分离：用来解决数据库查询压力，因为对于数据库来说读操作一般比写操作要多。主库负责写，从库负责读。数据库读写分离后，有可能出现延迟，导致主从数据不一致。

数据库主从：主从数据同步，主要通过二进制文件来实现。主库追加写数据库文件到二进制文件，从库从二进制文件追加读数据，从而实现数据同步。（二进制文件一般放在主库上，当然放其他机器上没可以）

主从变换：主库挂了后，其他另一台机器会立马变成主库。

   

附：流量漏斗

越往上层请求量越大，越往下层请求量越少，从上层到下层的请求量会越来越少

                  

5、五代架构图

数据库读写分离解决不了大数据量的问题，只能解决大并发问题。数据量太大，如有10亿，要查询出其中的某一条，必须要先把这10亿条数据取到内存再查，此时内存放不下，就会导致宕机。为解决此问题，引入数据库拆库分表。

拆库原理：

 

7、最新架构图

为方便统一管理，引入服务化，如下图所示。

  缓存：应用启用缓存后，查数据时会先去redis里查，若redis没有再去mysql中查，mysql中查完后再返回redis，redis返回应用程序。因此缓存命中率不高的话，反倒降低查询效率，开启缓存要注意保证缓存的高命中率。

更多内容欢迎关注微信公众号查看