高并发的解决策略

首先说数据库层面的

1.web应用和数据库部署在不同的服务器上

据库对象缓存策略

2.数据库服务器采用集群方式部署(如oracle的一个数据库多个实例的情况)

数据集群方式,能承担的负载是比较大的,数据库物理介质为一个磁盘阵列,多个数据库实例以虚拟IP方式向外部应用服务器提供数据库连接.

这种部署方式基本可以满足绝大多数常见web应用.

3.数据库采用主从部署: 

面向大众用户的博客/论坛.交友等系统中,有上百万用户,上千万的数据量,存在数据库查询,也有较多的数据库写操作,并且在多少情况读操作大于写操作.这时候考虑:

数据库读写分离,

主从复制:

几乎所有的主流数据库都支持复制,

以mysql为例,配置并不复杂,步骤如下:

1.开启主服务器上的二进制日志[mysql主从复制依据主服务器的二进制日志文件进行的,主服务器日志记录操作会在从服务器上重放,从而实现复制]

2.在主服务器和从服务器上分别进行简单配置

读写分离:

主从复制数据是异步完成,导致主从数据库中数据有一定延迟,读写分离必须考虑这一点.

以博客为例，用户登录后发表了一篇文章，他需要马上看到自己的文章，但是对于其它用户来讲可以允许延迟一段时间（1分钟/5分钟/30分钟），不会造成什么问题。这时对于当前用户就需要读主数据库，对于其他访问量更大的外部用户就可以读从数据库。

从应用层面考虑

策略一  :cache缓存

在web/app层与db层之间加一层cache层

主要目的：

a. 减少数据库读取负担；

b. 提高数据读取速度。而且，cache存取的媒介是内存，

而一台服务器的内存容量一般都是有限制的，不像硬盘容量可以做到TB级别。所以，可以考虑采用分布式的cache层，这样更易于破除内存容量的限制，同时又增加了灵活性。

缓存又分为两种:

1.架构方面的缓存[Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存]

2.网站程序开发方面的缓存

Memcached 介绍

开源的分布式cache系统

原理：

Memcached处理的原子是每一个（key，value）对（以下简称kv对），key会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护

Memcached有两个核心组件组成：服务端（ms）和客户端（mc），

在一个memcached的查询中，mc先通过计算key的hash值来确定key对所处在的ms位置。

当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。

因为这之间没有交互以及多播协议，所以memcached交互带给网络的影响是最小化的

举例说明：考虑以下这个场景，有三个mc分别是X，Y，Z，还有三个ms分别是A，B，C：

设置kv对
X想设置key=”foo”,value=”seattle”
X拿到ms列表，并对key做hash转化，根据hash值确定kv对所存的ms位置
B被选中了
X连接上B，B收到请求，把（key=”foo”,value=”seattle”）存了起来

获取kv对
Z想得到key=”foo”的value
Z用相同的hash算法算出hash值，并确定key=”foo”的值存在B上
Z连接上B，并从B那边得到value=”seattle”
其他任何从X，Y，Z的想得到key=”foo”的值的请求都会发向B

缓存数据库查询
现在memcached最流行的一种使用方式是缓存数据库查询，下面举一个简单例子说明：

App需要得到userid=xxx的用户信息，对应的查询语句类似：

“SELECT * FROM users WHERE userid = xxx”

App先去问cache，有没有“user:userid”（key定义可预先定义约束好）的数据，如果有，返回数据；如果没有，App会从数据库中读取数据，并调用cache的add函数，把数据加入cache中。

当取的数据需要更新，app会调用cache的update函数，来保持数据库与cache的数据同步。

从上面的例子我们也可以发现，一旦数据库的数据发现变化，我们一定要及时更新cache中的数据，来保证app读到的是同步的正确数据。当然我们可以通过定时器方式记录下cache中数据的失效时间，时间一过就会激发事件对cache进行更新，但这之间总会有时间上的延迟，导致app可能从cache读到脏数据

策略二:图片服务器分离:

对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的于是我们有必要将图片与页面进行分离

策略三:负载均衡

软件四层交换:

使用Linux上常用的LVS(Linux Virtual Server)来解决,.提供了基于心跳线heartbeat的实时灾难应对解决方案

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群:这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易 -----------有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

硬件四层交换:

使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。