一、架构阶段
1、LAMP Linux+Apache+MySQL+PHP
2、应用服务器与数据服务分离
三台服务器有不同的硬件需求
应用服务器：需要处理大量的业务逻辑，需要更快更强大的CPU
数据库服务器：需要快速磁盘检索和数据缓存，需要更快的磁盘和更大的内存
文件服务器：需要存储大量用户上传的文件，需要更大的磁盘
带来的好处：
不同的服务器承担不同的服务角色
3、数据库压力过大导致延迟
解决就是使用缓存
缓存分为：
1）本地缓存
2）远程分布式缓存 redis用的较多，支持【持久化】
缓存加快速度的原理：空间换时间
4、用户逐渐增多，单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器称为网站的瓶颈
V4 应用服务器集群---改善网站的并发处理能力
负载均衡的实现方式有哪些？
5、使用缓存后，大大减轻数据库的读压力
但是一部分读操作（缓存访问不命中，缓存过期）和全部的写操作要访问数据库
造成缓存雪崩
采用数据库读写分离
怎么保持主从一致？
数据访问模块 DAL
6、地域网络环境差别很大，如何保证用户的访问体验，不至于因访问慢而流失用户
V6 反向代理和CDN加速
CDN 内容分发网络
比如西北地区请求网站首页，里面包含各种图片或者js信息
在负载均衡服务器中查询是哪个地区的，然后把各种信息的请求地址变成西北地区的服务器
部署在离用户比较近的地方
缓存静态资源？？
反向代理服务器
缓存静态资源，有资源直接返回，没有继续请求
好处：
1、加快用户访问响应速度
2、减轻后端服务器的负载压力
3、减轻网络带宽的压力
7、单文件服务器、单数据库服务器存不下日益增长的数据
V7 分布式文件系统和分布式数据库系统
分布式文件系统怎么做？
分库分表怎么做？
8、随着业务发展，检索需求会逐渐增大或者越来越复杂
存储字段差异很大，骷髅表
复杂的文本检索 nosql ES 搜索引擎
索引失效
搜索引擎 解决文本搜索问题 ES（elasicseach）** solr lucene
NoSql mongodb ES
9、业务越来越复杂，应用程序无比庞大，迭代周期越来越快，牵一发动全身
业务拆分
消息队列：kafka（分布式）rocketMQ（参考kafka） rabbitMQ activeMQ
10、业务拆分越来越小，应用越来越多。应用间的关系越来越复杂，应用中存在大量相同的业务操作
后端的数据库要被成千上万台应用服务器连接。数据库连接资源不足
分布式服务（服务化）
服务框架 springcloud dubbo
11、一些误区：
（1）一味想通过架构去解决问题
比如可以通过产品方面解决。比如12306高并发，可以采用分时段
（2）一味追求大公司的技术
