1、一代架构图
在一台计算机上部署APP应用程序和数据库，数据库影响APP应用程序的性能，APP应用程序也影响数据库的性能，并相互干扰
2、二代架构图
一个APP应用程序、一个数据库和两台机器分开
3、三代架构图
随着网络的发展，用户数量也在增加。 此时，如果继续继承第二代体系结构图，则无法承担服务器服务，并导致第三代体系结构图，如下所示：
ngnix接受用户请求后，ngnix将请求分发给后续服务器，让服务器处理，而不是自己处理。 用户请求时看到的是nginx的IP，nginx主要用于解决用户数量多、请求大的问题。 nginix后面的服务器是群集，每个tomcat服务器都是一台计算机。
4、四代架构图
根据流量漏斗的原理，随着用户并发量的增大，数据库的并发量也会增大，数据库压力也会增大。 数据库也开始出现性能问题，为了解决数据库方面的问题，派生了以下体系结构图： 相对于三代模式映射，区别在于数据库读写分离、数据库主从增长。
读写隔离：用于解决数据库查询的压力。 这是因为对数据库来说，读取操作比写入操作多。 主库负责写作，负责从库中阅读。 读写分离后，可能会发生延迟，主从站的数据可能不一致。
主从机：主从机的数据同步主要通过二进制文件实现。 主库通过将数据库文件追加写入二进制文件，并从库中从二进制文件中追加读取数据，实现数据同步。 (二进制文件通常放在主库中，但当然不能放在其他计算机上。)
主从转换：当主库锁定时，其他计算机将立即成为主库。
附：流量漏斗
越往上层请求量越大，越往下层请求量越少，从上层到下层的请求量会越来越少
5、五代架构图
读写分离不能解决大数据量的问题，只能解决大规模的同时问题。 如果数据量太大，有10亿的话，要想调查其中一个，就必须先把那10亿的数据拿到内存中再调查。 此时，内存放不下的话会停机。 为了解决这个问题，引入数据库分割表。
库分解原理：
7、最新架构图
为了便于批量管理而导入服务化后，如下图所示。
缓存：如果APP启用了缓存，则在检查数据时首先在redis中进行检查。 如果redis未在mysql中检查，则在mysql中检查后返回redis，redis返回APP。 因此，如果缓存命中率不高，反而要降低查询效率，打开缓存时要注意提高缓存命中率。
更多内容请关注微信公众号