架构随业务而生，业务重于架构。架构是对高并发、大数据、大流量网站的优化措施，网站规模小但一味的追求架构只是逐末舍本，业务一定是一个网站最核心的支持
在网站架构端提升性能的第一手段是缓存，由近逐远可粗略分为：
- 本地缓存，用户端/浏览器端的缓存
- CDN缓存，将一些热点数据、静态文件存放于网络提供商端，这是网络请求经过的的第个关卡
- 反向代理服务器缓存，存在于网络机房一侧，除了请求转发、负载均衡、安全保护功能，反向代理服务器的缓存机制也能很大程度上减轻应用服务器的压力
- 分布式缓存集群，对于一些大型网站，使用一些大内存的服务器作为专门的缓存服务器集群是很有必要的
- 应用服务器的缓存，在应用部署的服务器直接消耗服务器的内存进行对数据的缓存，但是会出现缓存数据占用内存而导致应用服务器处理业务能力下降等适得其反的状况
盲目的缓存数据不但不会对网站的性能得到提升，反而会拖慢网站的速度，需要缓存的数据应该具备以下特点：
热点数据。一般来说，一个网站被访问数据遵循二八法则，即大部分的数据访问集中在小部署的数据上，也就是80%的业务访问集中在20%的数据上 ，那么对于这20%的数据可以称之为热点数据，但并不是说这所有的20%数据都易存放于缓存
频繁修改的数据不易使用缓存。数据的读写比例在2：1以上的话我们就可以称这个数据为非频繁修改的数据，可以将其写入缓存
缓存的数据是用户能忍受小段时间脏读的数据。
也就是说用户看到这个数据修与否都无大碍，不会有什么实质的损失，比如卖家修改了一个久久都未修改的商品的属性，买家需要一小段时间才能看到，这不会对买家或者卖家造成损失，但如果修改的是价格，那么情况就有所不同。
这种延迟需要被重视，虽然有一些数据更新后立即刷新缓存的技术，但这也会带来更多的系统开销和事务一致性的问题
数据库的读写分离
将数据库分为主从数据库，主数据库负责接收“写入”请求，并使用一定的机制将“主”数据库中的数据同步到“从”数据库，当用户的“读”请求到达的时候直接由“从“数据库执行。
更进一步，可以使用消息队列将用户的”写入“请求列队，”主“服务器负责去消费这些请求，最大程度上减轻数据库的压力
异步操作
异步操作也是提升响应速度、缓解服务器压力的一种手段。
具体可以使用消息队列，应用服务器将写入请求发送到消息队列以后立即返回，相比较传统的直接对数据库进行写入操作而言效率的提升可想而知。
但是异步操作的数据必须是用户能够接受小段时间脏读的数据。
在代码端提升网站的性能：
使用多线程，多线程是在代码端提升网站性能的第一手段
谨慎使用锁机制，不恰当的锁使用会拖慢网站的速度
在cookie中存放的数据除非是迫不得已，否则不放数据
服务降级/关闭
在网站流量到达高峰的时候，可以采用服务降级/关闭的方法，从而腾出更多的资源来保证核心业务的可用性
集群：集群内的所有服务器都有相同的应用，使用负载均衡将请求分发，尽可能使得单台服务器不会超载
分布式：分布式解决的是单台服务器已经装不下一个文件、应用、系统，或者承受不住其带来的压力（对内存的读写、对CPU的调度等），那样使用分布式将其分开置于分布式集群之中，分开储存、分开计算。
- 为了抵御一些自然的不可抗拒力量，有些大型的网站还会在全世界范围内进行数据的备份
- MPPS（MultiPort Single Server，单服务器多端口）分布式部署方案，将多个服务部署在单台服务器的不同端口上，使得一个集群可以提供多个服务，但是这样难以评估每台服务器的负载，使得负载均衡不能发挥最大的作用
- 首页不应该访问数据库，最好是静态的