大型网站架构考虑的问题,高并发网络架构

　　随着互联网的广泛应用，海量数据的存储和访问成为系统设计的瓶颈。对于一个大规模的互联网应用来说，每天数百万甚至上亿的PV无疑对数据库造成了相当高的负载。这给系统的稳定性和可扩展性带来了很大的问题。

　　一、负载均衡技术

　　负载均衡集群由一组独立的计算机系统组成，这些计算机系统通过常规网络或专用网络连接，并通过路由器连接。各个节点相互协作，分担负载，平衡压力。对于客户端来说，整个集群可以看作一个独立的超高性能的服务器。

　　1.实施原则

　　要实现数据库的负载均衡技术，必须有一个能控制数据库连接的控制终端。这里切断了数据库和程序的直接联系，所有程序都访问这个中间层，然后中间层访问数据库。这样就可以有针对性地控制对某个数据库的访问，然后就可以根据数据库当前的负载采取有效的平衡策略来调整每次连接哪个数据库。

　　2.实现多个数据库的数据同步。

　　对于负载均衡，最重要的是所有服务器的数据实时同步。这对于集群是必要的，因为如果数据不是实时的和不同步的，那么用户从一个服务器读取的数据与从另一个服务器读取的数据是不同的，这是不允许的。因此，必须实现数据库的数据同步。这样就可以拥有多种资源，在查询时达到平衡。比较常见的方法是对SQL Server集群使用莫比乌斯(注意：这是一个第三方工具，智能且操作简单，类似于ICX数据库路由等。可以理解为类似于Oracle RAC。当然，购买第三方工具和解决方案需要一定的经济成本)。SQL Server集群的莫比乌斯采用核心程序驻留在每台机器的数据库中的方法。这个核心程序叫做SQL Server中间件的莫比乌斯，主要功能是监控数据库中数据的变化，并将变化的数据同步到其他数据库中。数据同步完成后，客户端会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；此外，同步过程在事务环境中完成，保证了多个数据在任何时候的一致性。由于莫比乌斯中间件主机在数据库方面的创新，中间件不仅可以知道数据的变化，还可以知道引起数据变化的SQL语句。根据SQL语句的类型，智能地采用不同的数据同步策略，使数据同步的代价最小化。

　　如果数据数量少，数据内容不大，就直接同步数据。

　　数据块很少，但是有大数据类型，比如文本、二进制数据等。所以数据应该先压缩再同步，这样可以减少对网络带宽的占用和传输时间。

　　有很多数据。这时中间件会得到引起数据变化的SQL语句，然后对SQL语句进行分析，分析其执行计划和执行成本，选择是同步数据还是同步SQL语句到其他数据库。这种情况在调整表结构或批量更改数据时非常有用。

　　3.优点和缺点

　　(1)可扩展性强：当系统需要更高的数据库处理速度时，可以简单地通过添加数据库服务器进行扩展。

　　(2)可维护性：当一个节点出现故障时，系统会自动检测故障，并调用故障节点的应用，保证数据库的持续工作。

　　(3)安全性：由于数据会在多个服务器上同步，可以实现数据集的冗余，通过多个数据保证安全性。此外，还成功地将数据库放到了内网中，更好地保护了数据库的安全性。

　　(4)易用性：完全透明，集群暴露为IP。

　　(1)不能根据Web服务器的处理能力来分配负载。

　　(2)负载均衡器(控制端)故障会导致整个数据库系统瘫痪。

　　第二，数据库读写分离

　　1.实现原理：读写分离简单来说就是把对数据库的读写操作分离出来，分别对应不同的数据库服务器，可以有效减轻数据库和io的压力。主数据库提供写操作，而从数据库提供读操作。其实在很多系统中，主要是读操作。主数据库写的时候，数据要同步到从数据库，这样才能有效保证数据库的完整性。

　　(ebay读写比260: 1，易贝读写比分开)

　　(微软数据库分发版)

　　2.实现方法：在MS Sql server中，通过发布定义实现数据库复制，实现读写分离。复制是将一组数据从一个数据源复制到多个数据源的技术，它是将一个数据发布到多个存储站点的有效方法。使用复制技术，用户可以将数据副本发布到多台服务器上。复制技术可以保证分布在不同地方的数据自动同步更新，从而保证数据的一致性。SQL SERVER复制技术有三种类型：快照复制、事务复制和合并复制。SQL SERVER主要使用发布和订阅来处理复制。数据所在的服务器就是发布服务器，负责发布数据。发布服务器将要发布的数据的所有更改复制到分发服务器，分发服务器包含一个分发数据库，它可以接收数据的所有更改，保存这些更改，然后分发给订阅者。

　　3.优点和缺点

　　(1)数据实时性差：数据没有实时同步到自读服务器。数据写入主服务器后，只有在下次同步后才能查询。

　　(2)数据量大时同步效率差：当单个表的数据量过大时，由于索引和磁盘IO等问题，插入和更新的性能会很差。

　　(3)同时连接多个(至少两个)数据库：连接至少两个数据数据库，实际的读写操作在程序代码中完成，容易造成混乱。

　　(4)读具有高性能、高可靠性和可扩展性：只读服务器，因为没有写操作，会大大减少磁盘IO等性能问题，大大提高效率；只读服务器可以采用负载均衡，主数据库发布到多个只读服务器，实现读操作的可伸缩性。

　　三。数据库/数据表拆分(分布式)

　　通过一定的特定条件，将存储在同一个数据库中的数据分布到多个数据库中实现分布式存储，并通过路由规则访问特定的数据库，使得每次访问面对的不是单台服务器，而是N台服务器，减轻了单机的负载压力。提示：在sqlserver 2005之后，您可以友好地支持“表分区”。

　　纵向拆分：按功能模块拆分，如订单数据库、商品数据库、用户数据库.这样，多个数据库的表结构是不同的。

　　横向(水平)拆分：同一个表的数据被分区保存在不同的数据库中，这些数据库中的表具有相同的结构。

　　(垂直拆分)

　　(水平分割)

　　1.实现原理：使用垂直拆分主要看应用类型是否适合这种拆分方式。例如，系统可以分为订单系统、商品管理系统和用户管理系统。业务系统比较清晰，垂直拆分可以起到很好的分散数据库压力的作用。业务模块不清晰、耦合度高(表关联)的系统不适合这种拆分方式。但是垂直分裂并不能完全解决所有压力问题，比如

　　有500W的订单表，订单库压力还是很大的。例如，如果我们需要向这个表中插入一条新数据，数据库将在插入后重新索引这个表。索引500W行数据的系统开销不容忽视。反过来，如果我们把这张桌子分成100张桌子呢？从table_001到table _ 100，500W行数据，每个子表只有500，000行数据。此时，当我们将数据插入到只有5000w行数据的表中时，索引的时间会减少一个数量级，大大提高了DB的运行效率和DB的并发性。这种分裂是水平分裂。

　　2.实现方法：垂直拆分。拆分方法实现起来相对简单。您可以根据表名访问不同的数据库。水平拆分有很多规则。下面总结一下前辈们的观点。

　　(1)顺序拆分：如果可以根据订单日期按年份划分产品，就把它们放在2003年的db1，2004年的db2，以此类推。当然也可以按照主键标准拆分。

　　优点：部分迁移

　　缺点：数据分布不均匀。可能2003年有100W的订单，2008年有500W的订单。

　　(2)hash modulo:hash user_id(或者如果user_id是数值的话直接用user _ id的值)，然后用一个特定的numDB1r .比如一个数据库在应用中需要分成四个数据库，我们就用数字4对user_id的哈希值取模，也就是user_id%4。这样，每个操作就有四种可能。当结果为2时，对应DB2；当结果为3时，对应DB3；当结果为0时，它对应于DB4，因此数据均匀分布在四个DB4中。

　　优点：数据分布均匀

　　缺点：数据迁移麻烦；无法根据机器性能分配数据。

　　(3)将数据库配置保存在认证库中。

　　就是建立一个DB，单独存储user_id和DB的映射关系。每次访问数据库，都要先查询数据库，获取具体的DB信息，然后才能进行所需的查询操作。

　　优点：灵活性强，一对一关系

　　缺点：每次查询前都要多查询一次，会造成一定的性能损失。

　　今天，我的网站架构超载了。服务器的利用率经常达到100%。主要原因是数据库占用了大量的CPU资源。这样的系统根本跟不上网站的发展。

　　所以针对我们网站，我考虑了一些网站流量导流的方法。

　　1.看了别人的文章，大部分都说现在网站的瓶颈在于数据库。所以，我们把第一个放在这里。我们设计的网站要求用户数达到1亿。(目前淘宝用户近2000万，腾讯用户近10亿，活跃用户超过1亿)。当然我们的设计需要更多的考虑，所以定位在淘宝和腾讯的用户数量之间。

　　用户名列表建立了一个单独的数据库，这样可以随时将数据库分离出来建立单独的服务器。当用户登录时，数据库必须从1亿条记录中搜索数据。即使使用主索引，也需要将近1秒的时间(在SQLSERVER中，用like搜索200000个数据大约需要2秒，

　　这里是通过精确匹配和主索引并集进行搜索)。因此，我们需要将用户表分成多个表。按照26个字母的顺序，有一个以中文开头的用户名列表和一个以数字开头的用户名列表。这样，就有28张桌子。平均一个表有300万个数据，最大的一个表估计有1000万个左右的数据。然后，以用户名为主索引，SQLSERVER数据库应该可以应付。

　　除了建立单独的用户表数据库外，还需要准备100万左右的商品数据和大城市500万的帖子(目前杭州网论坛主题帖超过30万，回复帖600万)。所以现在的商品数据都存储在独立的数据库里，论坛的帖子也存储在独立的数据库里。商品数据分城市，论坛帖子也分城市，主题一表，回复一帖。

　　店铺数量(淘宝目前约有60万家活跃店铺)。我们的网站应该是非发布商店，所以我们需要更多的表来存储这些数据。目前无法确定，大概是1000万家店。在保险期间，还独立建立一个数据库，

　　然后，您可以与其他小型数据库共享一台服务器。

　　店铺对应的店铺分类和友情链接要单独设置，因为数量至少要达到店铺数量的10倍，数据库要按照用户名划分。

　　一般网站设置，以及城市列表，版主信息等。可以生成静态内容，建立单独的数据库。城市商品分类需要一个单独的数据库。根据城市表格。

　　其他内容相同。至此，数据库的瓶颈问题从理论上得到解决。

　　2.尽可能多地生成静态HTML页面。

　　生成首页HTML页面，城市首页HTML页面，所有商品页面HTML页面，帖子首页HTML页面(前10篇)。如果一个主题发布超过1页，可以点击“更多”查看。这可以节省服务器资源。页面生成时，服务器会占用大量的CPU资源。所以这个功能要单独放在一个独立的服务器上，在这个服务器上建立一个缓存队列数据库。用户提交表单时，会将数据保存在缓存队列数据库中，等待服务器的处理。

　　这些内容由服务器按时间顺序处理(主索引)。将生成的HTML产品页面放在一个文件夹中(可以随时添加服务器)，上传并处理图片，将图片存储在另一个文件夹中(图片消耗IIS资源最多，所以以后一定要添加图片服务器)。处理后的内容存储在主数据库中，处理后的记录从缓存队列数据库中删除。这个块是CPU的很大一部分，所以准备好移除主WEB服务器。

　　3.使用缓存。有些网页，像首页，可以学习百度首页，24小时缓存。

　　4.分别读写数据库。使用两个完全相同的数据库，一个用于写，一个用于读，每隔一段时间把写数据库新增的数据复制到读数据库，减少数据库的重合。听说很多网站都采用这种方式。

　　5.在北方，教育网等专网充当镜像服务器；

　　6.使用负载平衡技术。特殊服务提供商提供解决方案。