文档介绍：高并发高负载数据库架构策略在WEB网站的规模从小到大不断扩展的过程中,数据库的访问压力也不断的增加,数据库的架构也需要动态扩展,在数据库的扩展过程基本上包含如下几步,每一个扩展都可以比上一步骤的部署方式的性能得到数量级的提升。WEB应用和数据库部署在同一台服务器上一般的小规模的网站采用这种方式,用户量、数据量、并发访问量都比较小,否则单台服务器无法承受,并且在遇到性能瓶颈的时候升级硬件所需要的费用非常高昂,在访问量增加的时候,应用程序和数据库都来抢占有限的系统资源,很快就又会遇到性能问题。WEB应用和数据库部署在各自独立的服务器上web应用和数据库分开部署,WEB应用服务器和数据库服务器各司其职,在系统访问量增加的时候可以分别升级应用服务器和数据库服务器,这种部署方式是一般小规模网站的典型部署方式。在将应用程序进行性能优化并且使用数据库对象缓存策略的情况下,可以承载较大的访问量,比如2000用户,200个并发,百万级别的数据量。数据库服务器采用集群方式部署(比如Oracle的一个数据库多个实例的情况)数据库集群方式能承担的负载是比较大的,数据库物理介质为一个磁盘阵列,多个数据库实例以虚拟IP方式向外部应用服务器提供数据库连接服务。这种部署方式基本上可以满足绝大多数的常见WEB应用,但是还是不能满足大用户量、高负载、数据库读写访问非常频繁的应用。数据库采用主从部署方式在面向大众用户的博客、论谈、交友、CMS等系统中,有上百万的用户,有上千万的数据量,存在众多的数据库查询操作,也有较多的数据库写操作,并且在多数情况下都是读操作远大于写操作的。在这个时候,假如能将数据库的读写操作分离的话,对于系统来讲是一个很大的提高啦。数据库的主从部署方式就走到我们面前啦。主从复制:几乎所有的主流数据库都支持复制,这是进行数据库简单扩展的基本手段。下面以Mysql为例来说明,它支持主从复制,配置也并不复杂,只需要开启主服务器上的二进制日志以及在主服务器和从服务器上分别进行简单的配置和授权。Mysql的主从复制是一句主服务器的二进制日志文件进行的,主服务器日志中记录的操作会在从服务器上重放,从而实现复制,所以主服务器必须开启二进制日志,自动记录所有对于主数据库的更新操作,从服务器再定时到主服务器取得二进制日志文件进行重放则完成了数据的复制。主从复制也用于自动备份。读写分离:为保证数据库数据的一致性,我们要求所有对于数据库的更新操作都是针对主数据库的,但是读操作是可以针对从数据库来进行。大多数站点的数据库读操作比写操作更加密集,而且查询条件相对复杂,数据库的大部分性能消耗在查询操作上了。主从复制数据是异步完成的,这就导致主从数据库中的数据有一定的延迟,在读写分离的设计中必须要考虑这一点。以博客为例,用户登录后发表了一篇文章,他需要马上看到自己的文章,但是对于其它用户来讲可以允许延迟一段时间(1分钟/5分钟/30分钟),不会造成什么问题。这时对于当前用户就需要读主数据库,对于其他访问量更大的外部用户就可以读从数据库。数据库反向代理:在读写分离的方式使用主从部署方式的数据库的时候,会遇到一个问题,一个主数据库对应多台从服务器,对于写操作是针对主数据库的,数据库个数是唯一的,但是对于从服务器的读操作就需要使用适当的算法来分配请求啦,尤其对于多个从服务器的配置不一样的时候甚至需要读操作按照权重来分配。对于上述问题可以使用数据库方向代理来实现。就像WEB方向代理服务器一样,MYsqlProxy同样可以在SQL语句转发到后端的Mysql服务器之前对它进行修改。数据库垂直分割主从部署数据库中,当写操作占了主数据库的CPU消耗的50%以上的时候,我们再增加从服务器的意义就不是很大了,因为所有的从服务器的写操作也将占到CPU消耗的50%以上,一台从服务器提供出来查询的资源非常有限。数据库就需要重新架构了,我们需要采用数据库垂直分区技术啦。最简单的垂直分区方式是将原来的数据库中独立的业务进行分拆(被分拆出来的部分与其它部分不需要进行Join连接查询操作),比如WEB站点的BLOG和论坛,是相对独立的,与其它的数据的关联性不是很强,这时可以将原来的数据库拆分为一个BLog库,一个论坛库,以及剩余的表所组成的库。这三个库再各自进行主从数据库方式部署,这样整个数据库的压力就分担啦。另外查询扩展性也是采用数据库分区最主要的原因之一。将一个大的数据库分成多个小的数据库可以提高查询的性能,因为每个数据库分区拥有自己的一小部分数据。假设您想扫描1亿条记录,对一个单一分区的数据库来讲,该扫描操作需要数据库管理器独立扫描一亿条记录,如果您将数据库系统做成50个分区,并将这1亿条记录平均分配到这50个分区上,那么每个数据库分区的数据库管理器将只扫描200万记录。数据库水平分割在数据库的垂直分