支撑百万连接的系统应该如何设计其高并发架构？

首先要结合具体的业务场景，不根据业务就云设计就是在耍流氓。

业务场景

首先你要确定你所架构的系统服务于什么业务。假如我们现在是一个小创业公司，注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。但是你要考虑到后面注册用户数达到了2000万！每天活跃用户数100万！每天单表新增数据量达到50万条！高峰期每秒请求量达到1万。

静态资源

大宽带、CDN、缓存（页面缓存、对象缓存），WEB服务器缓存等N级分布式缓存，Redis、Memcached缓存集群。

动态资源

计算：多组服务器，负载均衡等技术控制流量。

存储：存储这里就比较麻烦，按照KV存储简单的资源，然后在计算部分进行整合。真的没办法做KV的，采用跨库索引来做。单机存储数量要合理，不能太多。还有就是事务性的问题，解决方案就是BASE思想或者采用日志方式。

纵向拆分、水平扩展

系统按照模块功能纵向拆分，再水平扩展，抽象服务层利用各种中间件完善，优化JVM应用服务器。

消息中间件

用mq解决稳定性。将耗时比较长或者耗费资源的请求排队，异步处理，减轻服务器压力增加稳定性

数据库

关系型、非关系型数据库上最牛比SSD硬盘，分库分表，读写分离，读的流量多时还要增加从库提高IO性能。每秒1万请求到5台数据库上，每台数据库就承载每秒2000的请求，相应的压力也就会减少。

SQL语句避免跨表查询，优化好存储过程，此时注意存储过程利用好了是把利剑，利用不好就成为了累赘。

负载均衡

负载均衡由多种实现方式，一种是在硬件上的，常用软件由F5、NetScaler、Radware和Array等商用的，但是价格较昂贵。另外一种就是软件的，常见的软件有LVS、Nginx、Apache等,它们是基于Linux系统并且开源的负载均衡策略。

简单架构图

结语

系统架构中需要注意的点太多，具体业务也不尽相同。实现方案也有多种，此处只提供一个思路。

1、这个题目问得不那么准确，你必须要精准计算出每秒查询时间（QPS）和事务时间（TPS），好比你感冒了，你说要配什么药，医生只能凭经验，你如果去抽象化验，知道是病毒还是细菌感染，数量是多少后，才能进一步诊断和配置服务器硬件。

2、接下来，你要了解常用发中间件和数据库的极限并发量。比如redis一般是11w左右（纯粹内存读写）、mysql每秒写8w左右，读10来万（单表，多表就不一定，得看SQL的写法），一般单表的存储极限是5千万左右，如果超出范围，那么配置再好也是慢。总的说来，要精确配置服务器，你需要尽可能地评估最复杂的业务每秒并发时间，同时要考虑最复杂的情况，比如数据库的数据规模、代码在最高并发下，所耗费的时间，同时对网络I/O也要有一个预估，知道带宽的大小，总之，需要具体问题具体分析。

3、如果以上情况不考虑，就是想知道一个简单粗暴的大概结果，一般8核、16G、256SSD，同时跑DB和web服务器的话，足够支持1w的并发量，而且还有很大的冗余。如果火力全开，满血跑，大概跑个8-10w都是有可能的。边压测，边优化，如果恰好旁边有高手，榨干每一个环节，你的并发量超出你的想象

1、提供HTML静态访问

web界面上最快的访问速度是什么？当然是最原始的HTML文件访问,对于其他语言 比如 jsp ,asp,php等等,他们首先要通过服务器解析成html之后在返回给访问者，如果我们能提供全部是htm来的页面，那么就能大大的降低服务器和数据库资源的利用和提高网站的并发，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。当然实现这种方式大家比较了解的就是信息发布系统CMS,信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

在后续的文章中我们会单独的使用jsp + servlet实现一个简单的信息发布系统

2、使用独立的服务器

为什么要把单独设置一个服务器？对于Web服务器来说，消耗的服务器资源是最多的，如果能把所有的资源放到一个单独的服务器中进行处理的话，可以降低提供页面访问请求的服务器系统压力，从而能进一步的提高web程序的并发所以在有条件的情况下最好能把放置到一个单独的服务器中

3、配置多台数据库服务器，多个数据库集群

集群（Cluster）技术是使用特定的连接方式，将价格相对较低的硬件设备结合起来，同时也能提供高性能相当的任务处理能力。

越是大型高并发的应用，数据库的压力就会越大，如果数据库操作很频繁，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群。

数据库集群就是使用多个数据库服务器分担请求的压力，达到快速响应的目的

4、使用缓存

所谓的缓存就是把数据咱是放置到内存中，前台在请求的时候直接从内存中读取数据，而不需要去查询数据库或者读取文件等，这样就能做到最快的响应。网站架构和网站开发中的缓存是非常重要的。

目前有很多开源的缓冲实现方案，APC，File，SQLite，Memcache等等各种类库实现着不同的缓存方式，只有通过了解他们的实现方式，根据具体应用具体选择，才会使缓存系统发挥出最大的性能。

对于java开发来说，大名顶顶的 分布式缓存系统Memcache 可能是最好的选择，他提供一个基于Socket的访问方式，使得该缓存系统支持远程读写访问。尽管这个缓存的内容可能是存在内存中，也可能是存在文件内。

本文主要介绍tomcat 、apache、 nginx的定义、区别及优缺点。

1 Apache

Apache HTTP服务器是一个模块化的服务器，可以运行在几乎所有广泛使用的计算机平台上。其属于应用服务器。Apache支持支持模块多，性能稳定，Apache本身是静态解析，适合静态HTML、等，但可以通过扩展脚本、模块等支持动态页面等。

（Apche可以支持PHPcgiperl,但是要使用Java的话，你需要Tomcat在Apache后台支撑，将Java请求由Apache转发给Tomcat处理。） 缺点：配置相对复杂，自身不支持动态页面。

2 Tomcat：

Tomcat是应用（Java）服务器，它只是一个Servlet(JSP也翻译成Servlet)容器，可以认为是Apache的扩展，但是可以独立于Apache运行。

3 Nginx

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx，它的发音为“engine X”，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器。

1 Apache与Tomcat的比较

相同点：

 两者都是Apache组织开发的  两者都有HTTP服务的功能  两者都是免费的 不同点：

 Apache是专门用了提供HTTP服务的，以及相关配置的（例如虚拟主机、URL转发等等），而Tomcat是Apache组织在符合Java EE的JSP、Servlet标准下开发的一个JSP服务器

 Apache是一个Web服务器环境程序,启用他可以作为Web服务器使用,不过只支持静态网页如(ASP,PHP,CGI,JSP)等动态网页的就不行。如果要在Apache环境下运行JSP的话就需要一个解释器来执行JSP网页,而这个JSP解释器就是Tomcat。

 Apache:侧重于HTTPServer ，Tomcat:侧重于Servlet引擎，如果以Standalone方式运行，功能上与Apache等效，支持JSP，但对静态网页不太理想；

 Apache是Web服务器，Tomcat是应用（Java）服务器，它只是一个Servlet(JSP也翻译成Servlet)容器，可以认为是Apache的扩展，但是可以独立于Apache运行。

实际使用中Apache与Tomcat常常是整合使用：

 如果客户端请求的是静态页面，则只需要Apache服务器响应请求。  如果客户端请求动态页面，则是Tomcat服务器响应请求。  因为JSP是服务器端解释代码的，这样整合就可以减少Tomcat的服务开销。

可以理解Tomcat为Apache的一种扩展。

2 Nginx与Apache比较

1) nginx相对于apache的优点

 轻量级，同样起web 服务，比apache占用更少的内存及资源  抗并发，nginx 处理请求是异步非阻塞的，而apache 则是 阻塞型 的，在高并发下nginx 能保持低资源低消耗高性能  高度模块化的设计，编写模块相对简单  提供负载均衡

 社区活跃，各种高性能模块出品迅速

2) apache 相对于nginx 的优点

 apache的 rewrite 比nginx 的强大 ；

 支持动态页面；

 支持的模块多，基本涵盖所有应用；

 性能稳定，而nginx相对bug较多。

3) 两者优缺点比较

 Nginx 配置简洁, Apache 复杂 ；

 Nginx 静态处理性能比 Apache 高 3倍以上 ；

 Apache 对 PHP 支持比较简单，Nginx 需要配合其他后端用；  Apache 的组件比 Nginx 多 ；

 apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程；

 nginx处理静态文件好,耗费内存少；

 动态请求由apache去做，nginx只适合静态和反向；

 Nginx适合做前端服务器，负载性能很好；

 Nginx本身就是一个反向代理服务器 ，且支持负载均衡

3 总结

 Nginx优点：负载均衡、反向代理、处理静态文件优势。nginx处理静态请求的速度高于apache；

 Apache优点：相对于Tomcat服务器来说处理静态文件是它的优势，速度快。Apache是静态解析，适合静态HTML、等。

 Tomcat：动态解析容器，处理动态请求，是编译JSP\Servlet的容器，Nginx有动态分离机制，静态请求直接就可以通过Nginx处理，动态请求才转发请求到后台交由Tomcat进行处理。

Apache在处理动态有优势，Nginx并发性比较好，CPU内存占用低，如果rewrite频繁，那还是Apache较适合。

真的的日常工作中，一般的项目还是用nginx+tomcat来做会多一点。

有多高？这个有很大区别

你去搜索一下 “F5” 负载均衡，从硬件角度解决

50~500/秒 的并发一般的服务器+tomcat 都可以承受。

所以很难理解你的 web 要给多少人用呀？假设10万人集中在10分钟内一起操作，也就是每分钟1万，也就 200/秒 都不到。就算正太分布，也就 需要700/秒，服务器稍好，弄个weblogic，或者websphere 就搞定了呀

11 负载均衡介绍

111 负载均衡的妙用

112 为什么要用lvs

那为什么要用lvs呢？

ü 简单一句话，当并发超过了Nginx上限，就可以使用LVS了。

ü 日1000-2000W PV或并发请求1万以下都可以考虑用Nginx。

ü 大型门户网站，电商网站需要用到LVS。

12 LVS介绍

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以在UNIX/LINUX平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立，是 中国国内最早出现的自由软件项目之一 。

121 相关参考资料

LVS官网： http://wwwlinuxvirtualserverorg/indexhtml

相关中文资料

122 LVS内核模块ip_vs介绍

ü LVS无需安装

ü 安装的是管理工具，第一种叫ipvsadm，第二种叫keepalive

ü ipvsadm是通过命令行管理，而keepalive读取配置文件管理

ü 后面我们会用Shell脚本实现keepalive的功能

13 LVS集群搭建

131 集群环境说明

主机说明

web环境说明

web服务器的搭建参照：

Tomcat：

http://wwwcnblogscom/clsn/p/7904611html

Nginx：

http://wwwcnblogscom/clsn/p/7750615html

132 安装ipvsadm管理工具

安装管理工具

查看当前LVS状态，顺便激活LVS内核模块。

查看系统的LVS模块。

133 LVS集群搭建

命令集 ：

检查结果 ：

ipvsadm参数说明： (更多参照 man ipvsadm)

134 在web浏览器配置操作

命令集 ：

至此LVS集群配置完毕 ！

135 进行访问测试

浏览器访问：

命令行测试：

抓包查看结果：

arp解析查看：

14 负载均衡（LVS）相关名词

术语说明：

141 LVS集群的工作模式--DR直接路由模式

DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。

DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上，即必须在同一局域网环境。

DR直接路由模式说明：

a)通过在调度器LB上修改数据包的目的MAC地址实现转发。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。

b)请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高，比Nginx代理模式强于此处。

c)因DR模式是通过MAC地址的改写机制实现转发的，因此，所有RS节点和调度器LB只能在同一个局域网中。需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。

d)强调一下：RS节点的默认网关不需要是调度器LB的DIP，而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况)，理论上讲，只要RS可以出网即可，不需要必须配置外网IP，但走自己的网关，那网关就成为瓶颈了。

e)由于DR模式的调度器仅进行了目的MAC地址的改写，因此，调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层（MAC），NAT模式则工作在三层网络层（IP）和四层传输层（端口）。

f)当前，调度器LB支持几乎所有UNIX、Linux系统，但不支持windows系统。真实服务器RS节点可以是windows系统。

g)总之，DR模式效率很高，但是配置也较麻烦。因此，访问量不是特别大的公司可以用haproxy/Nginx取代之。这符合运维的原则：简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用haproxy/Nginx(LVS的NAT模式)

h)直接对外的访问业务，例如web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，存储系统RS节点，最好只用内部IP地址。

DR的实现原理和数据包的改变

(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP

(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址

(d) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。

(e) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP

(f) 响应报文最终送达至客户端

15 在web端的操作有什么含义？

151 RealServer为什么要在lo接口上配置VIP？

既然要让RS能够处理目标地址为vip的IP包，首先必须要让RS能接收到这个包。

在lo上配置vip能够完成接收包并将结果返回client。

152 在eth0网卡上配置VIP可以吗？

不可以，将VIP设置在eth0网卡上,会影响RS的arp请求,造成整体LVS集群arp缓存表紊乱，以至于整个负载均衡集群都不能正常工作。

153 为什么要抑制ARP响应？

① arp协议说明

为了提高IP转换MAC的效率，系统会将解析结果保存下来，这个结果叫做ARP缓存。

ARP缓存表是把双刃剑

ARP广播进行新的地址解析

测试命令

windows查看arp -a

③arp_announce和arp_ignore详解

lvs在DR模式下需要关闭arp功能

arp_announce

对网络接口上，本地IP地址的发出的，ARP回应，作出相应级别的限制:

确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口

arp_ignore 定义

对目标地定义对目标地址为本地IP的ARP询问不同的应答模式0

抑制RS端arp前的广播情况

抑制RS端arp后广播情况

16 LVS集群的工作模式

DR（Direct Routing）直接路由模式

NAT（Network Address Translation）

TUN（Tunneling）隧道模式

FULLNAT（Full Network Address Translation）

161 LVS集群的工作模式--NAT

通过网络地址转换，调度器LB重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器，真实服务器的响应报文处理之后，返回时必须要通过调度器，经过调度器时报文的源地址被重写，再返回给客户，完成整个负载调度过程。

收费站模式---来去都要经过LB负载均衡器。

NAT方式的实现原理和数据包的改变

(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP

(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP

(d) POSTROUTING链通过选路，将数据包发送给Real Server

(e) Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP

(f) Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP

LVS-NAT模型的特性

l RS应该使用私有地址，RS的网关必须指向DIP

l DIP和RIP必须在同一个网段内

l 请求和响应报文都需要经过Director Server，高负载场景中，Director Server易成为性能瓶颈

l 支持端口映射

l RS可以使用任意操作系统

l 缺陷：对Director Server压力会比较大，请求和响应都需经过director server

162 LVS集群的工作模式--隧道模式TUN

采用NAT技术时，由于请求和响应的报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。

为了解决这个问题，调度器把请求的报文通过IP隧道(相当于ipip或ipsec )转发至真实服务器，而真实服务器将响应处理后直接返回给客户端用户，这样调度器就只处理请求的入站报文。

由于一般网络服务应答数据比请求报文大很多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。

VS/TUN工作流程,它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。

调度器根据各个服务器的负载情况，连接数多少，动态地选择一台服务器，将原请求的报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的真实服务器。

真实服务器收到报文后，先将收到的报文解封获得原来目标地址为VIP地址的报文, 服务器发现VIP地址被配置在本地的IP隧道设备上(此处要人为配置)，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

TUN原理和数据包的改变

(a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP 。

(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP，目标IP为RIP

(d) POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。 此时源IP为DIP，目标IP为RIP

(e) RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。 此时的源IP地址为VIP，目标IP为CIP

(f) 响应报文最终送达至客户端

LVS-Tun模型特性

163 LVS集群的工作模式--FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一个vlan中，导致部署成本过高；TUNNEL模式虽然可以跨vlan，但RealServer上需要部署ipip隧道模块等，网络拓扑上需要连通外网，较复杂，不易运维。

为了解决上述问题，开发出FULLNAT

该模式和NAT模式的区别是：数据包进入时，除了做DNAT，还做SNAT（用户ip->内网ip）

从而实现LVS-RealServer间可以跨vlan通讯，RealServer只需要连接到内网。类比地铁站多个闸机。

17 IPVS调度器实现了如下八种负载调度算法：

a) 轮询（Round Robin）RR

调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

b) 加权轮叫（Weighted Round Robin）WRR

调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。

调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

c) 最少链接（Least Connections） LC

调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。

如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。

d) 加权最少链接（Weighted Least Connections） Wlc

在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

e) 基于局部性的最少链接（Locality-Based Least Connections） Lblc

"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。

该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器。

若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。

f) 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。

它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。

该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器。

若服务器超载，则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。

同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。

g) 目标地址散列（Destination Hashing） Dh

"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

h) 源地址散列（Source Hashing）SH

"源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器。

若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

18 LVS+Keepalived方案实现

181 keepalived功能

1 添加VIP

2 添加LVS配置

3 高可用（VIP漂移）

4 web服务器 健康 检查

182 在负载器安装Keepalived软件

# 检查软件是否安装

183 修改配置文件

lb03上keepalied配置文件

lb04的Keepalied配置文件

keepalived persistence_timeout参数意义 LVS Persistence 参数的作用

http://blogcsdnnet/nimasike/article/details/53911363

184 启动keepalived服务

185 在web服务器上进行配置

注意：web服务器上的配置为临时生效，可以将其写入rclocal文件，注意文件的执行权限。

使用curl命令进行测试

至此keepalived+lvs配置完毕

19 常见LVS负载均衡高可用解决方案

Ø 开发类似keepalived的脚本，早期的办法，现在不推荐使用。

Ø heartbeat+lvs+ldirectord脚本配置方案，复杂不易控制，不推荐使用

Ø RedHat工具piranha，一个web界面配置LVS。

Ø LVS-DR+keepalived方案，推荐最优方案，简单、易用、高效。

191 lvs排错思路

理论上经验这个东西是学不来的

说一下我的例子

刚入行的时候,基本就是写了一些增删改查甚至session都不太理解

随着入行后,你会遇到各种各样的问题在解决问题的过程中,经验来了

简单说一下所谓大规模高并发访问的web架构吧

其实,对于大规模高并发不外乎两点,第一点是及时相应(尽可能优化io)第二点是数据安全

这两点控制的好,就没问题的所以,我们的架构也就围绕在这两点应运而生

第一点,为了尽可能提高应用的io吞吐量则需要我们把所有耗时的io操作尽可能的优化,比如全局使用很少更改的一些配置,则可以采用nosql来全局共享(注意,这里的全局是指服务器集群如果涉及到了大规模,肯定是多服务器的)在其次可以增加服务器缓存比如2秒钟从上一条的服务器读取配置,存到服务器级别以提高效率还有线程缓存如果业务复杂可能对一个请求需要查询多次数据,不变的,老规矩,放到线程缓存基本也就差不多了

第二点,因为应用不同,要考虑容错率这个部分优化,可以考虑分离业务,把必须要数据安全的业务逻辑提取出来,队列执行或者特殊处理

剩下的就是服务器部署与如何分配,比如多少台web服务器,数据库配置,内存服务器配置等

这只能是在实际项目和工作过程中来区别对待了

hadoop适合处理分布式集群系统，本身是支持高速并发海量数据的写入和读取的。解决大量用户并发访问的方案有很多，给你个千万pv的参考方案：

1）架构中直接引入软件名称的模块，是个人推荐使用的，如Haproxy、Hadoop等；

2）关于全局负载均衡，看成本投入情况，可以使用商业的产品，如F5-GTM，开源方案便是自搭智能DNS；

3）本地负载均衡方案，可以考虑F5-LTM或成熟的开源解决方案LVS；

4）代理层为什么推荐大家使用Haproxy？Haproxy是一个非常优秀的反向代理软件，十分高效、稳定。国内top 10的互联网公司都有在使用；

5）缓存层可以使用Squid或Varnish，个人更倾向Varnish。配置灵活、运行稳定，提供非常便利的管理接口。为啥在缓存层前面加一层代理？优点非常多，列举如下：

根据应用配置URI路由规则，集中热点来提高后端缓存的命中率；

轻松划分网站频道、版块，更好对应用进步组织、规划；

对URI进行一般性安全过滤，抵御注入攻击；

弹性调配硬件资源，应对突发事件产生大流量；

可回收宝贵的公网IP资源；

6）应用层开源技术方案非常多且成熟，在此不详细描述；

7）数据库层主流开源解决方案Mysql是首选，主从复制（一主对多从）是目前比较靠谱的模式；

8）关于Nosql，应用场景不多说，可参考“给部门做的Mongodb技术交流PPT”文章，redis、memcached等作为热点数据存储、数据库缓存都非常理想；

9）内网DNS扮演的角色非常重要，一定要消灭code中出现的内网IP地址，很大程度减少因IP变更、服务器故障而修改源码的情况，同时也便于维护；

10）内网LB适用在内部WEB接口、多台数据库Slave、多台Nosql Slave、公共服务等应用的负载均衡，可以使用LVS、Haproxy来实现，可用性要求不高的应用可行直接使用Localhost DNS轮询；

11）hadoop适合海量数据的存储与处理，如做网站日志分析、用户数据挖掘等；

12）管理集群，平台的核心，运维的阵地；