大型网站架构

大型网站架构：

分布式（分压）和高并发（数据完整性和高可用）

还有服务器集群（负载均衡）

分布式（消息队列通讯：阿里MQ）

高并发（队列或者文件锁，数据库锁）

完整性（事务）

-------------------------------------

MYSQL大访问量：

读写分离、垂直拆分，水平拆分

---------------------------------------------

说得很好

大型网站技术架构：http://www.thinkphp.cn/code/2510.html

-----------------------------------------------------

$fp = fopen("lock.txt", "w+");

    if(flock($fp,LOCK_EX | LOCK_NB)) {

    //todo ....

    flock($fp,LOCK_UN);

    } else {

    echo "系统繁忙，请稍后再试";

    }

    fclose($fp);

   

    //--------------------------

    //Redis Sadd 命令将一个或多个成员元素加入到集合中，已经存在于集合的成员元素将被忽略。

    $rt = sadd('product_lock_key',"1");

    if($rt == false){

    //加不进去说明已经有人进入下单流程

    }

    //---------------------------

    //抢购库存

    $num = 10;   //系统库存量

    $user_id =  Session::get('user_id');//当前抢购用户id

    $len = Redis::llen('order:1');  //检查库存，order:1 定义为健名

    if($len >= $num)//判断队列长度

    　　return '已经抢光了哦';

   

    $result = Redis::lpush('order:1',$user_id);  //把抢到的用户存入到列表中

    if($result)

    　　return '恭喜您!抢到了哦';

    //if判断被绕过，导致存入队列的用户ID超出库存，要解决“超抢/超卖”的问题，核心在于保证检查库存时的操作是依次执行的，再形象的说就是把“多线程”转成“单线程”。

    //即使有很多用户同时到达，也是一个个检查并给与抢购资格，一旦库存抢尽，后面的用户就无法继续了。

   

   

   

    //准备工作，库存放入队列，只秒杀抢购开始前进行一次准备---------总结：尽量用lpop控制库存，较少if判断队列长度数量比较导致的并发。

    $num=10; //库存

    //检查库存,goods_store:1 定义为健名

    $len = Redis::llen('goods_store:1'); //被抢购的数量，0

    $count = $num-$len; //实际库存-被抢购的库存 = 剩余可用库存,10-0

   

    for($i=0;$i<$count;$i++)//10

    　　Redis::lpush('goods_store:1',1);//往goods_store列表中,未抢购之前这里应该是默认滴push10个库存数了

   

        //echo Redis::llen('goods_store:1');//未抢购之前这里就是10了

   

    //循环执行抢购开始

    $user_id =  Session::get('user_id');//当前抢购用户id

   

    $count=Redis::lpop('goods_store:1');//lpop是移除并返回列表的第一个元素。

    if(!$count)//如果没剩余库存了

    return '已经抢光了哦';

   

    $result = Redis::lpush('order:1',$user_id);

    if($result)

    　　return '恭喜您!抢到了哦';

   

    DB::table('goods')->decrement('num', 1);//减少num库存字段

    //尽量将数据库的交互往后推，之前先过滤掉并发

--------------------------------------------------------------

附：

大型网站技术架构，分布式集群示例！
网站都是从小网站一步一步发展为大型网站的，而这之中的挑战主要来自于庞大的用户、安全环境恶劣、高并发的访问和海量的数据，任何简单的业务处理，一旦需要处理数以 P 计的数据和面对数以亿计的用户时，问题就会变的很棘手
下面我们就来说说这个演变过程：
初始阶段
大型网站都是由小型网站演变而来的，网站架构也一样
小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，就像这样：

小型网站架构
应用程序、数据库、文件等所有资源都在一台服务器上，通常使用 Linux PHP MySQL Apache 就可以完成整个项目部署，然后再买个域名，租一个廉价的服务器就可以开始我们的网站之旅了
应用服务与数据服务分离
随着业务的发展，逐渐的一台服务器已经不能满足需求，这时我们可以将 应用与数据分离
分离之后我们使用到三台服务器：应用服务器、文件服务器和数据库服务器，如下所示：

应用服务与数据服务分离
对于这三台服务器要求各不相同：
应用服务器 要处理大量的业务逻辑，所以需要更好更快更强大的 CPU
数据库服务器 需要快速的进行磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存
文件服务器 需要存储用户上传的文件资源，因此需要更大的硬盘存储空间
应用与数据分离后，各个的职责变得更加专一，网站的性能得到进一步的提升，但随着用户的继续增加，我们需要对网站架构进一步优化
使用缓存改善性能
网站的访问一样遵循二八定律：80% 的业务访问集中在 20% 的数据上面
因此我们要对这一小部分的数据进行缓存来减轻数据库的访问压力，以提高整个网站的数据访问速度，改善数据库的读写性能
网站的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存
本地缓存 的访问速度会快一些，但是受应用服务器内存限制，缓存数据量很有限，而且会出现内存争用的情况
远程分布式缓存 可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务
如下所示：


使用缓存后的
使用缓存后，数据访问压力得到了有效的缓解，但单一的应用服务器能够处理的请求连接数有限，在访问的高峰期，应用服务器又会成为网站性能的瓶颈
使用应用服务器集群改善网站并发处理能力
使用集群是网站解决高并发，海量数据问题的常用手段，当你纵向提升到一定程度后，那就该开始横向提升了
当一台服务器的处理能力不足时，与其换一台更强大的服务器，不如增加一台服务器去分担原有的服务器压力。对于大型网站而言，无论多么强大的服务器，都满足不了持续增长的业务需求，更高效的方式就是增加服务器来分担压力
对于网站架构而言，如果增添一台新的服务器可以改善负载压力，那么就可以使用同样的方式来应对源源不断的业务需求，从而实现系统的可伸缩性


应用服务器集群
通过负载均衡调度服务器，可以将用户请求分发到应用服务器集群里的任何一台服务器上，如果有更多的用户，可以增加更多的应用服务器，使应用服务器的负载压力不再成为网站的性能问题
数据库读写分离
在使用了缓存后，大多数的操作不经过数据库访问就能完成，但仍有一部分读操作（缓存访问未命中，缓存过期）和所有的写操作需要访问数据库，在网站的用户量达到一定时，数据库的负载问题就来了
目前大多数的数据库都支持主从热备份，通过配置两台服务器的主从关系，可以将一台数据库服务器的数据更新同步到另一台，网站利用这一功能，实现数据库读写分离，从而进一步改善数据库负载压力


数据库读写分离
应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制把数据同步更新到从数据库，这样当应用服务器进行读操作的时候，就能访问从数据库获取数据
使用反向代理和 CDN 加速网站响应
CDN 和 反向代理 的基本原理都是缓存
CDN 部署在网络供应商的机房，用户在进行请求时，会从距离最近的网络供应商机房获取数据
反向代理 则部署在中心机房，当用户请求到达中心机房后，会首先访问反向代理服务器，如果反向代理服务器中缓存这用户请求的资源，就直接返回给用户


CDN 和 反向代理
使用 CDN 和 反向代理 都是为了尽快返回给用户数据，一方面加快用户访问速度，另一方面也减轻了后端服务器的压力
使用分布式文件系统和分布式数据库系统
随着网站业务的继续发展，这时候就可以像分布式应用服务器一样，对数据库系统和文件系统进行分布式管理
分布式数据库 是网站数据库拆分的最后手段，一般我们可以采取业务分库，根据不同业务的数据库部署在不同的数据库服务器上


文件系统和数据库系统分布式管理
使用 NoSQL 和搜索引擎
这两个方式都是依赖于互联网的技术手段，应用服务器通过一个统一的数据访问模块来访问各种数据，从而减轻应用程序有多个数据源的麻烦


使用搜索引擎和nosql
业务拆分
对于大型网站，我们可以分而治之，把整个网站的业务分为不同的模块，比如大型的交易购物完整可以分为首页、店铺、订单、买家等，分别交给不同的业务团队来负责
同时我们将一个网站根据模块划分拆分成多个应用，每个应用进行单独的部署和维护，应用之间通过超链接建立关系（指向不同的应用地址），最后通过相同的数据存储系统来构成一个互相关联的完整系统


业务拆分
分布式服务
随着业务拆分，整个系统越来越大，应用的整体复杂度呈指数级增加，部署维护越来越困难，并且所有的应用服务器都要与数据库服务连接， 在数万台服务器规模的情况下，这些连接的数目是服务器规模的平方，导致资源不足
这时候就要对相同的业务进行提取，独立部署，把这些可重用的业务和连接数据库等，提取出来作为公共业务服务，而应用系统只需要通过分布式服务访问公共业务服务完成业务操作


分布式
到这里，基本上大多数的技术问题都能得到解决，还有一些实时同步等具体业务问题也都可以通过现有的技术解