标签：负载 缓存 架构 演变 网站 数据库 server 均衡 服务器
大型网站架构是高并发服务器的典型实例，通过这个实例更好的理解服务器架构设计。
Step1 Web Server 与数据库分离
刚开始访问量少，web 服务器可以和数据库部署在同一台机器之上。这里的web server 是包含Http server + App server 。这个架构简单，但是存在的问题是Web server 和数据库相互影响，任何一个出现瓶颈都会影响网站整体访问速度，因此为了提高访问速度，可以把这两个分离开来，让他们部署在独立的机器之上。
这里web server 还可以做动静资源分离。
这两种架构都比较简单，都不满足服务器的高可用性目标，因为只存在单点，任何一点出现故障整个网站都不能访问了。
web动静资源分离
浏览器的资源请求分为动态资源请求和静态资源请求。静态资源请求是指HTML页面请求、javascript资源请求、CSS样式资源请求、img图片资源请求；动态资源请求是指.jsp、.php 动态页面请求。因此可以把Web Server分成Http server和App Server, Http server 主要处理静态请求，App Server 主要处理动态请求。主流的Http Server有Nginx、Apache。App server 主要有JBoss、Tomcat。（Apache和Nginx 也可以处理php）
Step2 缓存处理
随着网站访问量的提高，这时候网站访问速度也变慢了，这时候我们可以做缓存处理。
1、浏览器加缓存，减少对网站的访问
2、Front Page Cache 前端静态页面缓存，减少对web server 的请求。
3、对于动态页面中相对静态的部分也可以做ESI页面片段缓存（Edge Side Includes）。
4、还可以对数据库做本地数据缓存，减少对数据库的查询
缓存的处理，可以进一步提高网站的访问速度。
Step3 Web Server 集群+读写分离
网站的访问量进一步增加，网站的性能又出现了问题。这时候我们可以增加Web Server，由于增加了Web Server ，需要增加一个负载均衡Load Balance。这时候数据库成为了瓶颈，那么就把数据库的读与写分离开来。
读写分离
一般网站的读操作比写操作频繁，可以读的服务器比写的服务器多分配几个。写的服务器具有replication机制，用来同步数据。应用服务器读操作访问读服务器，写操作访问写的服务器，写服务器更新操作后，要同步到读服务器。
这样数据库也做到了负载均衡，读的操作均衡到读库，写的操作均衡到写库。这样也能提高网站的访问速度。
负载均衡
负载均衡分成三个方面，前端负载均衡、应用服务器负载均衡、数据库负载均衡
1、前端负载均衡
（1）DNS负载均衡：在DNS服务器中，可以为多个不同的地址配置同一个名字，对于不同的客户机访问同一个名字，得到不同的地址。
（2）反向代理：使用代理服务器将请求发给内部服务器，让代理服务器将请求均匀转发给多台内部web服务器之一，从而达到负载均衡的目的。标准代理方式是客户使用代理访问多个外部web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。
（3）、基于NAT的负载均衡技术。外部访问网站的时候进入一个NAT 服务器，NAT内部通过地址映射，映射到内部服务器，和反向代理类似的。
（4）、LVS 开源软件搭建负载均衡。
（5）、F5 硬件负载均衡。
2、应用服务器负载均衡
添加一层任务服务器，任务服务器监控应用服务器，选择一个负载小的分配任务，还有一种是应用服务器处理完任务主动去任务服务器获取任务
3、数据库负载均衡
读写分离
Step4 CDN、分布式缓存、分库分表
1、CDN 内容分发网络，在各个运营商各个地区增加内容分发网络，这样不同的地区访问网站速度得到了提升，不同的运营商接入都能得到提升
2、增加分布式缓存。每个应用服务器中的缓存数据之间不共享，分布式缓存所以的服务器之间都是共享的。
3、数据库分库分表。由于数据库的数据量比较大，在并发量大的时候会出现锁竞争，那我们把数据库分到更多的数据库之上，避免锁竞争。分库之后呢，表还大，那么可以进一步分表，最大程度避免锁竞争，提高访问速度。
分布式缓存
目前主流分布式缓存方案：memcached、membase、redis等，基本上当前的NoSQL方案都可以用来做分布式缓存方案。
分库
把一个数据库上的三个表，分配成三个数据库。这样每个数据库上的压力就减小了，也可以减少这些数据库之间的锁竞争，访问数据时候的锁竞争
分表
每个数据库中的表很大，可以进一步分表
Step5 多数据中心+分布式存储与计算
增加了 基于分布式文件系统计算架构建立数据中心
这一层面，为什么要增加这一层面呢？主要原因在于目前大部分网站对数据一致性要求不高，对数据一致性要求不高的数据没必要存放在关系型数据库当中，关系型数据库对一致性要求比较高，对事务处理、大表Join 都是服务器性能杀手,目前大型的数据库数据量是很大的PB级别的。我们可以把关系型数据库对一致性要求不是很高的数据分离出来，不要存在关系型数据库中，为它减肥，放到数据中心。数据中心用nosql 反sql这些技术来实现，这些数据是基于Key/Value 来存储的，这些数据对一致性要求低，并发性高，访问nosql的数据可以得到更大的并发。而且关系型数据库是商用软件的话价格很高昂，如果关系型数据库配的服务器性能也很高昂，价格比较高，nosql 可以放在廉价的机器之上。总而言之nosql 可以用来处理一致性要求不是很高的数据。
技术点 DFS、Key-Value DB、Map/Reduce
DFS 分布式文件系统，如：Lustre\HDFS\GFS\TFS\FreeNas等。
数据中心使用nosql 构建，nosql中的数据又存在DFS当中，为什么要有分布式文件系统呢？举个例子，比方说淘宝网站，淘宝商品有很多的图片，这些图片可能很小，这些图片如果放在操作系统的文件系统之上，磁盘上面，用操作系统的文件系统来管理，操作系统上面每个快的大小都比较小，如果存图片，那么磁头会来回的转动，效率就会比较低。这时候我们可以基于自己的文件系统来存储，每个快增大，将文件存到快当中，相关性比较大的图片存在一个快，相当于一个大的文件，我们在查找的时候先找到大块，那么效率就大大提升了。这样不像操作系统文件散落在磁盘上面，而是变成了这些快，当然这些快不仅存储了图片，还存储了图片是怎么存储的信息，查找的时候就不是找的文件了，而是一快数据，通过hash 算法就可以快速找到文件，就不至于磁头来回转动。
Key-value DB : 也作为NoSql 解决方案，如：BigTable\Tair\Hbase\HyperTable等。
Map/Reduce 算法（计算框架），基本上现有NoSQL 数据库中都支持此算法。
这个三个技术是谷歌的核心技术
提供完整解决方案：
Google（GFS｜BigTable | Map/Reduce） 技术没开发，当时开放了论文
Apache Hadoop (HDFS | HBase | Map/Reduce ) 根据Google的论文实现。
Map/Reduce:
比方说要统计若干个文件中单词的计数，这几个文件可能分布在不同的机器之上，这几个文件可能很大，没办法一次性加载到内存当中。一台机器统计很慢，需要多台机器统计，这就是分布式计算。比如一台机器把文件A 每个单词出现的次数存到map当中key-value 数据库中，然后统一合并叫Reduce，这个就是分布式计算。
这就是一个大型网站的架构图。
应用服务器也不是扁平的，也可能有好几层。
标签：负载,缓存,架构,演变,网站,数据库,server,均衡,服务器 来源： https://blog.csdn.net/sinat_28697845/article/details/122712853
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。