第2章 大型网站及其架构演进过程

2.1 什么是大型网站

大型一般是指三个方面来形容大：

访问量高
数据大
系统架构复杂(因为流量大，所以修改成多个微服务)

2.2 大型网站的架构演进

2.2.1 单机服务：流量很小时：应用程序 + 数据库都在一台机器

2.2.2 数据库压力比较大，latency 扛不住时，应用与数据库分离，成2台机器

2.2.3 机器压力比较大(cpu/io 压力很大导致延迟latency 太大，无法接受)，此时就会通过负载均衡把一台机器扩展成一个集群

2.2.4 解决应用服务器变为集群后的session 问题 

[session 问题就是保持用户登陆状态，只要用户登陆在一段时间内可以自动登陆]；session 数据是存储在web 服务器上的，所以如果同一个用户下次不访问这个机器，那session 机制就失效，导致用户只能重新登陆；所以需要在负载均衡(proxy 机器)上进行流量转发规则；另外一种方式是把session 集中存放到一台机器，然后从这台机器上获取session 【session 设计成数据存在db或者缓冲中】，提供http服务或者client
供其他机器来查询即可

2.2.5 数据库读压力大，读写分离，难点是要保证2个database 数据一致性

2.2.6 DB 数据读取是从磁盘上读取，latency 比较大，尤其是数据库很大时，情况会恶化；

所以这时我们一般加上一层缓存，把频繁访问的数据放到缓存中【缓存一般是kv 格式的数据放到内存中，类似kv 的索引】

2.2.7 弥补关系型数据库的不足，引入分布式存储系统

我们之前讲的数据库是单机数据库，有些情况下单机数据库是不合适的；我们还有其他的存储系统；也就是我们常说的分布式存储系统;
我们常说的分布式存储系统包括：分布式文件系统、分布式kye-value 系统、分布式数据库。

2.2.8 读写分离后，数据库又遇到了瓶颈

这时只能分库分表了，分为2种:

分库：垂直方向：一般按照业务的紧密程度，把数据库分成多个数据( 可以不放在一台机器，也可以放在多台机器；只要修改配置或者数据库的中间件即可)
分表：水平方向：当一张table 里面的数据特别大，导致数据crud 很慢；这时我们就才取按照一定的规则进行分拆table
分拆应用：

刚才我们说的应用都是一个，随着应用的功能越来越多，应用也变得无比强大、复杂；这时需要把应用分拆成多个应用，把一些公共应用做成服务化，就是我们常说的：微服务、服务化、远程调用

2.2.9 初识消息中间件

消息中间件是在分布式系统中完成消息的发送和接收的基础软件；消息中间件最常见的方式就是：生产者和消费者，消息中间件的优点就是异步和解耦