系统架构概念及思想2

Nginx的优劣势：
　　在功能上Nginx不如Apache；
　　在响应用户方面Nginx是绝对的老大。
　　因此，Nginx在实际应用中通常用作反向代理，如下图：
　　Apache：作为动态内容的提供者，与MySQL通信。
　　注：对于动态脚本，一台有2颗CPU，4G内存的Server上，由于脚本逻辑不同，一般来说此Server平均每秒响应1000个都是相当不错了。
Nginx：作为静态内容的提供者，如：CSS，jpg，png等，来提高响应用户的速度。
　　注：静态图片（5-10K)的图片，Nginx在响应时,每秒可响应5000~10000个请求，这时响应用户的瓶颈可能就不是Server了,而可能是你的带宽和磁盘速度。
FTP：通常用于论坛中用户上传数据使用；所以通常需要将FTP做成支持FTP上传，并且是HTTP下载。

　　这些最终对于用户来说，他看到的仅仅是一个网页。Nginx作为前端的反向代理其优势在与它本身就是一个Web服务器，并且它可以对http协议进行解析，故对于 动态的脚本，静态的图片，css样式表等都是可以理解的，所以使用Web服务器做为反向代理，它是完全可以实现地址重写，URL Rewrite(URL重写)和 资源的重定向等各种操作。因此使用它作为前端是最好不过的了。

　　

下图结构的设计思想是：
如果站点的访问量非常大,当然下图所能设计的模型是不能适应并发5万的网络的。【并发5万:即每秒5万个并发请求，那么一天是86400秒，每2秒一个响应,则一天就是21.6亿次访问】
　　》在提供动态内网的Web Server的前端增加两台缓存服务器，这样就可以缓存动态网页为静态网页，这样就有效降低后端Web Server的压力。
　　》MySQL-Proxy 作为读写分离来实现MySQL的高效处理性能。若需要高可用也可将他做成2台。
　　》还有MySQL服务器在不使用链接线程池的情况，一台MySQL Server不论是使用MyISAM 或 Innodb每秒接收1000个读写请求都是非常吃力的。因为,数据连接与Web连接是无法比较的,一个数据连接可能一次发送的数据量会非常大；比如：查询一个有100万行数据的表，一个SELECT * FROM ... 它返回的数据量你可以想象下，有多大。所以，为了分担每台MySQL Server的压力，在读服务器前要加上一个负载均衡器这样就可以大大的分担单台Server的压力。
　　》Memcache：有些数据可能不会经常性更新，那么就可以将这些MySQL查询结果缓存到Memcache中，用来提高响应速度。比如：淘宝的店家他们会上传自己的商品信息，但一般情况下，他们的网店一旦创建好，大部分数据基本是不会在改变的。像这些数据就可以缓存到Memcache中。Memcache是不能高可用，因为Memcache不支持级联间通信，并且缓存数据也不能共享。若Memcache坏了，就直接在换一台即可，然后，将每个Webserver指向新的Memcache重新来生成缓存。
　　》XCache：从PHP4.0以后,PHP都必须先编译为OPT文件后，才能执行，那么它将对WebServer性能造成影响，因此需要安装Xcache作为PHP的模块，来缓存PHP编译后的结果。

　　

  　　假设是第一次启动这个系统，当一个用户发来请求,Nignx将请求交给缓存服务器，缓存服务器发现没有需要的缓存数据，接着它向后端的原始Web Server请求数据，Web Server 发现用户请求的是一个动态内容,向MySQL-Proxy发送查询，MySQL-Proxy发现这是一个读的查询，因此将查询发送给负载均衡器，由负载均衡器负责将请求转发给后端的MySQL Server，并将最终的查询结果返回给MySQL-Proxy，MySQL-Proxy再把数据提交给Web Server，Webserver在向用户响应前，先将查询的MySQL的结果缓存到Memcache中，方便后续快速查询，接着Web Server将数据返回给缓存服务器，缓存服务器将返回的结果页面缓存一份后，响应用户请求。


下图结构的设计思想是：
　　》异步消息同步的平台，又称作队列管理器：它主要用来管理大量请求的缓冲队列的，假如你的服务器群最初设计时，每台Server最大可响应500个请求，假若，突然并发量上升，这时我们可以使用队列管理器来解决这个问题，当有大量并发请求时，队列管理器会检查当前服务器的空闲状态，若为忙碌则将请求缓冲在自己的队列中，并每次一个一个的将用户请求分散转给满负荷的Server,让Server进行响应。这样就可以避免大量的并发导致Server拒绝服务。队列管理器有：rabbitmq ， zeromq，它也可简单理解为一个链接池。当然若不是采用异步系统方式，依然可以使用Cache Server来代替队列管理器。

　　》 PHP集群：所谓PHP集群实际上就是不使用Apache了,直接安装FastCGI来充当PHP服务器,仅仅提供处理PHP请求的能力。当然，它也是需要Xcache的。
　　　　注意: 只有在将动态内容和静态内容分开的情况下，才可以使用PHP集群。在下面这个图中，就是将静态的内容单独独立出去。故采用PHP集群。

　　》静态内容Server： 这里将静态内容服务器增加了很多台,主要是因为，图片的体积太大,假如：像淘宝这里网站，一张图片几K大小，那么一年会有多少图片将占多少空间，10年哪？假如淘宝10年来存的图片总容量为10T，那么你可以想象下，在一个10T的图片库中找一个图片是多么不轻松！！所以，可以再cache Server中缓存经常被访问的图片，就可以明显提高性能了。
　　【注意：二八法则也是考虑的因素，100个商铺，最多20%是活跃的，80%是非活跃的】

　　

下图为CDN网络概况：
　　CDN网络最为关键的两项技术：
　　》智能DNS：将用户的请求直接发送到距离用户最近的缓存服务器上。
　　》内容路由：当一个缓存服务器上没有用户请求的数据时，应该先到哪里去取数据。一般会先到各个缓存服务器上找，都没有在到原始服务器上找。
　　》 NoSQL：主要为了解决像淘宝五一，十一这种抢购行为而被采用，因为后台的MySQL很难直接完成这么庞大的读写并发。而这时NoSQL就派上大用了,因为，NoSQL是运行在内存中的非关系型数据库，它们的效率是非常高的。假如就说抢购,我们完全可以使用NoSQL来实现快速响应小事务,如：一个商品卖出个数的快速计数并快速响应页面，快速动态更新剩余个数等等。
　　redis：它工作在内存中，可以将自身数据同步到持久设备(磁盘)上，并且可将数据直接交给MySQL.它通常用于程序计数器，如微博中每天只要有人发一个评论或一条微博消息，则相应的计数值都会被修改，并显示。
　　mongodb：对众多事务，并且是写操作的应用来说，使用monogdb是一个不错的选择。

　　　　

更完善的系统架构：

　　1》在实际的环境中，我们不可能让每台服务器自己保存自己的日志，因为这是非常不便于集中管理的。假如将所有Server的日志集中管理那么像如此大的系统，每天产生的日志量可能就会达到100G以上。并且我们还希望可以对这些日志进行分析，并快速得到结果。那么就必须使用到分布式系统Hadoop了。它就是为了方便管理日志，分析日志，挖掘数据，就产生下下面这整套系统。而Hadoop是完成数据分析最为核心的分布式系统。但它的缺点是，不能实时分析数据，它是一种异步数据分析系统。因此，对于实时性的数据分析它就无能为力了。Hadoop是开源界根据google发表的关于分布式系统的论文而开发出来的，在Google内部已经开发出了自己的实时的分布式系统，在开源界实时性的分布式系统也正在开发中。目前尚不明确。

　这种分布式监控系统有什么用？
　　就比如：五一抢购，若采用这种系统，我们可以实时分析出到目前为止，那个商户的交易额最高，那个商户的商品最热销，那个商户的的人气最高等等....
2》在下面这个系统结构中：
　　我会还需要考虑到，若下面的Server都是物理机，那么其故障迁移，故障处理，及故障恢复都将变的非常困难。这时，我们就需要借助云来实现方便我们管理，我们可以将物理机都做成高可用，接着，我们将I/O需求不大业务都迁移到虚拟机上，这样我们就可以实现快速故障处理。并且让我们的系统更加模块化，所谓模块化：即将我们的前端Web Server做到一个虚拟机集群中，并让他成为一个云模块。我们的MySQL集群也一样，对外都只提供连接接口即可，至于后端如何实现就不要管了。当然我们的hadoop是不能放到虚拟机中的，毕竟虚拟机的I/O能力是很弱的，而hadoop需要非常大的I/O性能。