从前端走向幕后：如何构建大型高并发网站架构？（获奖名单已公布-2014-9-12）

forgaoqiang

首先是为什么大多数企业更倾向于在Linux搭建Web服务器，其实从博客园迁移到 阿里云的IIS后遇到的各种困难就能明白，很多大型的站点自身有很强的技术实力，而且对并发、系统要求很高，IIS就会出现一些问题，但是又没有源码，无法具体分析问题，就算找到问题也无法直接修改，因此有技术实力的厂家更倾向于开放的Linux和Apache/Ngnix也没有什么奇怪的了。


1.我们常用的系统架构有三种，第一种是linux+Apache+PHP+MySQL、第二种是Linux+Apache+Java（WebSphere）+Oracle、第三种是Windows Server+IIS+C#/ASP.NET+数据库，请举例说明这三种架构对应的网站有哪些？
①第一种经典的LAMP模式，应该是目前采用最多的系统架构（当然A很有可能是Nginx的N），据我所知百度贴吧这样的亿万级别帖子量的系统也是这个架构的，比较适合UCG这样的应用，这种应用场景往往变化较大，经常发生改动，数据库MySQL就比较适合。
②LAJO（姑且这么叫吧）这个比较适合企业内部业务系统使用，比如一些电商、内部办公系统，CRM、ERP、SCM等等。
③Windows下面的架构，这个比较奇葩，据我所知，Dell的官方站点就是用这个开发的，还有Vmware的云API也是使用这个开发的，所以比较有意思。

2.或许在平时，我们感觉不到数据库的死锁问题，但是当成千上万人同时访问网站，在高并发的情况下发生的概率会非常高，因此很多网站在数据库集群和高并发方面下足了功夫。而目前主流的数据库有MySQL和Oracle，如何利用数据库服务器在主从服务器之间保持同步，从而分散数据库压力？
一旦数据库访问过多，就很容易发生数据库出现死锁进而导致数据库锁死不能对外提供服务，分散数据库压力可以从多个方面实现：
①读写分离，主从复制，应对一般流量的情况
②表拆解、分区，一旦性能跟不上或者表结构或数据过于庞大，进行拆分
③分布式数据库，保持数据库之间的同步，必要时采用内存数据表等高性能方式


3.目前全球超过70%以上的互联网流量是通过CDN网络分发，各大视频网站也相继涉足云**领域。如何根据自身场景去设计一个CDN架构，或者如何选择以一个适合自己CDN服务提供商？在选型过程中需要考虑哪些重要因素？
CDN是大型网站分发静态资源（比如JS、CSS、图片等媒体资源）必须的服务。考虑CDN的时候就要考虑CDN厂家的节点分布情况、价格费用以及技术支持情况。


4.大型网站一般都使用缓存服务器群，并使用多层缓存。业内最常用的有Squid、memcahe、e-Accelerator，请谈谈您对它们的理解。
大型网站多采用缓存服务器集群，原因很简单，大部分的用户请求都无需计算和数据库查询，特别是电商等领域，配合CDN效果显著。业内采用反向代理实现数据的缓存，比较常用的有LVS、Memcache、redis、e-accelerator等，Squid视乎不再那么常用。它们能够将用户请求的内容缓存下来，有些使用磁盘作为缓存用、有些直接使用内存，配合HTTP中的头部字段，减少对后端系统的压力。

下面是个人读书《大型网站技术构架》中关于网站扩展性的读书笔记：

1. 网站的伸缩性结构
   
2. 
   
3. 1、网站的伸缩性设计可以分成两类
   
4. ①根据功能进行物理分离实现伸缩
   
5. 使用新增服务器处理某些特定服务，可以在纵向分离（将业务处理流程上的不同部分分离部署），横向分离（不同的业务模块分离部署，横向分离粒度可以很小，甚至一个关键页面部署一个独立服务）
   
6. ②单一功能通过集群实现伸缩
   
7. 相同服务部署在多台服务器构成一个集群整体对外提供服务
   
8. 
   
9. 2、应用服务器集群的伸缩性设计
   
10. ①HTTP重定向
    
11. 这种情况下HTTP 302响应码并不常用，性能差且有可能被搜索引擎判断为作弊
    
12. ②DNS域名解析负载均衡
    
13. 通过DNS将请求转发到最近的服务器上
    
14. ③反向代理负载均衡
    
15. 反向代理服务器转发请求在HTTP协议层面，因此也叫做 应用层负载均衡
    
16. ④IP负载均衡
    
17. 负载均衡器接受请求后自己根据负载均衡算法计算后得到真实的Web服务器地址后修改目标IP地址，在内核进程中完成数据分发，比反向代理的负载均衡性能好很多
    
18. ⑤数据链路层负载均衡
    
19. 在通讯协议的数据链路层修改MAC地址进行负载均衡，这种传输方式也叫做 三角传输模式 ，是大型网站常采用的技术。在Linux平台上最好的数据链路层均衡开源产品是LVS（Linux Virtual Server）。
    
20. 
    
21. 3、负载均衡算法
    
22. ①RR（Round Robin）
    
23. 轮询，请求一次分发到每台应用服务器，每台服务器处理的请求数相同
    
24. ②WRR（Weighted Round Robin）
    
25. 根军硬件性能，在轮询的基础上，按照配置权重将请求分配
    
26. ③随机（Random）
    
27. 简单实用，均衡好，可以采用加权随机算法
    
28. ④Least Connections
    
29. 最少连接，记录每个服务器当前处理的请求数，分发到请求数最少的服务器上。
    
30. ⑤源地址散列（Source Hashing）
    
31. 根据源IP进行Hash算法，可以实现会话粘滞
    
32. 
    
33. 4、分布式缓存集群的伸缩性设计
    
34. 分布式缓存服务器集群中不同的服务器缓存的数据也不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。
    
35. 
    
36. 5、Memcached的模型
    
37. 程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端由一组API，Memcached服务器路由算法、Memcached服务器集群列表及通讯模块构成。
    
38. 对于服务器集群的管理，路由算法至关重要。和负载均衡算法一样，决定着究竟该访问集群中的哪一台服务器。
    
39. ①简单路由算法
    
40. 余数Hash，用服务器数目除以缓存数据KEY的Hash值，余数为服务器列表下标编号。本身均衡性很好，但是扩容的时候就会出现缓存不命中，余数的时候分配到了并没缓存的服务器上。随着服务器集群规模的增大，这个比例成线性上升。当100台的时候加入一台新的服务器的时候，不能命中率高达 99%(N/(N+1))。当大部分被缓存了的数据因为服务器扩容而不能正确读取时，这些数据的压力就落到了数据库的身上。
    
41. 解决方法就是在访问量较少的时候扩容缓存服务器集群，这时候对数据库的负载冲级最小。
    
42. 
    
43. ②分布式缓存一致性Hash算法
    
44. 通过一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射。
    
45. 算法过程：
    
46. 先构造一个长度为0~2^32的整数环（这个环称作一致性Hash环），根据节点名称的Hash值（分布范围同样为0~2^32）将缓存服务器节点放置在这个Hash环上。根据需要缓存的数据的KEY计算得到Hash值（范围仍然是0~2^32），然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找。
    
47. 
    
48. 这样的话，新添加的服务器只影响整个环中的一小段，原来的KEY大部分还能继续计算到原来的节点上。具体应用中，这个长度为2^32的一致性Hash环通常使用二叉树实现，Hash查找过程实际上是在二叉树中查找不小于查找树的最小数值。
    
49. 
    
50. 这样有个问题，新加入的节点因为占用了换上的一小段距离，导致原来的节点占用更长的距离，会处理更多的负载，这不是很合理。解决方式是使用虚拟化技术：新加入物理服务器节点时，将一组虚拟节点加入环中，如果虚拟节点的数目足够多，这样就可以更加均匀的分布在环上，更好的承担压力，经验算法是一个服务器虚拟150个节点。
    
51. 
    
52. 6、数据存储服务器的伸缩性设计
    
53. 市场上的关系数据都支持数据复制功能，使用这个功能可以对数据进行简单的伸缩。业务分割模式可以用在数据库，不同业务数据表部署在不同的数据库集群上，这就是：数据分库。
    
54. 即使进行了分库和主从复制，对于一些数据量巨大的表，还需要进行分片，将一个表拆分分别存储在多个数据库中。数据分片的分布式关系数据库主要有开源的Amoeba。
    
55. 
    
56. Cobar数据库根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行，由于Cobar路由后只能在单一数据库实例上处理查询请求，因此无法执行跨库的JOIN操作，更不能执行跨库的事务处理。
    
57. 
    
58. NoSQL数据库产品都放弃了关系数据库量大重要基础：以关系代数为基础的结构化查询语言（SQL）和事务一致性（ACID）。而强化其他一些大型网站更关注的特性：高可用性和可伸缩性。
    
59. 
    
60. 
    
61. 随需应变：网站的可扩展结构
    
62. 
    
63. 1、国内某大型企业经常对同行的产品进行微创新，然后退出自己的产品，系统扩展性实际可以在设计层面的 开闭原则（对扩展开放，对修改关闭）。
    
64. 
    
65. 2、度量一个开发框架、设计模式、编程语言优劣的重要尺度就是衡量它是不是让软件开发过程和软件产品更加低耦合。
    
66. 
    
67. 3、事件驱动架构
    
68. 事件驱动架构（Event Driven Architecture）：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助时间消息的通讯完成模块间合作，典型的EDA结构就是操作系统中常见的生产者消费模式，最常用的是分布式消息队列。
    
69. 
    
70. 4、分布式消息队列
    
71. 队列是一种先进先出的数据结构，分布式消息队列可以看作将这种数据结构部署到独立的服务器上，应用程序可以通过远程访问接口使用分布式消息队列，进行消息存取操作，进而实现分布式的异步调用
    
72. 
    
73. 5、分布式服务框架设计
    
74. 大型网站需要的是更简单高效的分布式服务框架架构建其SOA（Service Oriented Architecture）。服务消费者程序通过服务器接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较少侵入：应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。
    
75. 
    
76. 6、可扩展的数据结构
    
77. 无需修改表结构就可以新增字段，许多NoSQL数据库采用ColumnFamily（列族）设计，最早是在Google的Bigtable中使用，这是一种面向列族的稀疏矩阵存储格式。
    
78. 
    
79. 7、开放平台建设网站生态圈
    
80. 根据长尾效应，这些增值服务的数量越是庞大，种类越是繁多，盈利也就越多。同样，一个网站自己那个女够开发增值服务也是有限的。

复制代码