CDN是什么?使用CDN有什么优势?

一、CDN的基本原理和基础架构 CDN是将源站内容分发至最接近用户的节点,使用户可就近取得所需内容,提高用户访问的响应速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题,适用于站点加速、点播、直播等场景。 (本章节部分内容摘引自:1.2 CDN的基本工作过程 – 51CTO.COM) 最简单的CDN网络由一个DNS服务器和几台缓存服务器组成: 当用户点击网站页面上的内容URL,经过本地DNS系统解析,DNS系统会最终将域名的解析权交给CNAME指向的CDN专用DNS服务器。 CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回用户。 用户向CDN的全局负载均衡设备发起内容URL访问请求。 CDN全局负载均衡设备根据用户IP地址,以及用户请求的内容URL,选择一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求。 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务,选择的依据包括:根据用户IP地址,判断哪一台服务器距用户最近;根据用户所请求的URL中携带的内容名称,判断哪一台服务器上有用户所需内容;查询各个服务器当前的负载情况,判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后,区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址。 全局负载均衡设备把服务器的IP地址返回给用户。 用户向缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容,而区域均衡设备依然将它分配给了用户,那么这台服务器就要向它的上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地。 CDN关键组件 LVS做四层均衡负载 DR模式 双LVS做Active-Active互备 负载均衡算法采用wrr Tengine做七层负载均衡…

Continue Reading →

nginx实现资源动静分离

一、为什么要采用动静分离架构? 1、动静不分离架构 VS 动静分离架构 传统动静不分离的产品架构(随着访问量在增长,性能会成为瓶颈)  实现动分离的产品架构(灵活的架构支持海量的用户访问)  2、适用场景 静态文件访问量大,服务器负载高,I/O问题导致用户访问卡顿。 静态文件数量大,服务器存储空间不够。 静态文件用户访问量大,且分布在各地。 移动更新包在某个时间段需要高速下载,且并发下载量高。 3、架构描述 OSS作为海量文件存储源,静态图片、视频文件、下载包、app更新包等均放在OSS上。OSS作为CDN的源站,通过CDN加速分发,用户通过CDN节点就近获得文件。 4、架构优势 降低Web服务器负载,静态文件访问负载全部通过CDN。 存储费用最低。OSS的存储费用仅为ECS磁盘费用的50%。 海量存储空间,无需考虑存储架构升级。 流量费用低,相比直接通过OSS访问,除极少额外增加的回源流量外,主要流量使用CDN流量,单价最低只需0.26GB,远远低于OSS直接访问的外网流量单价。 CDN需要域名与DNS提供支持,若无则采用nginx的动静分离即可,具体看《CDN是什么?使用CDN有什么优势?》。 二、nginx实现动静分离…

Continue Reading →

nginx限制上传文件大小

1、错误描述 Failed to load resource: the server responded with a status of 413 (Request Entity Too Large) 2、错误原因 上传文件时,利用localhost访问系统,不会出现这个问题;用域名访问这个系统时,出现这个问题是因为由于Nginx反向代理服务器client_max_body_size默认值为1MB,而上传文件大于1MB,所以就出现这个错误。 3、解决办法…

Continue Reading →

Nginx配置文件详解中文版

#定义Nginx运行的用户和用户组,系统中必须有此用户,可以是nologin user www www; #nginx进程,一般设置为和cpu核数一样 worker_processes 8; #cpu亲和力配置,让不同的进程使用不同的cpu 默认情况下可能多个进程跑在一个CPU上或某一核上,导致Nginx进程使用硬件资源不均匀, 此次优化是尽可能地分配不同的Nginx进程给不同的CPU处理 两颗CPU参数配置 worker_processes 2; worker_cpu_affinity 0101 1010; 四颗CPU参数配置 worker_processes 4; worker_cpu_affinity…

Continue Reading →

Nginx upstream的5种权重分配方式分享

1、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 2、weight 指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 例如: upstream backend { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; } 3、ip_hash 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 例如: upstream backend…

Continue Reading →

Redis+Tomcat+Nginx集群实现Session共享

一、Session共享使用tomcat-cluster-redis-session-manager插件实现 插件地址见:https://github.com/ran-jit/tomcat-cluster-redis-session-manager 该插件支持Tomcat7、Tomcat8、Tomcat9 二、tomcat-cluster-redis-session-manager详解 1、解压后的文件如下: conf目录下有一个redis-data-cache.properties :Redis的配置文件 #– Redis data-cache configuration #- redis hosts ex: 127.0.0.1:6379, 127.0.0.2:6379, 127.0.0.2:6380, …. redis.hosts=127.0.0.1:6379…

Continue Reading →

Nginx+Tomcat资源定向与负债均衡

一、前言 反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。 反向代理方式实际上就是一台负责转发的代理服务器(Nginx),貌似充当了真正服务器的功能,但实际上并不是,代理服务器只是充当了转发的作用,并且从真正的服务器(Tomcat)那里取得返回的数据。这样说,其实nginx完成的就是这样的工作。我们让nginx监听一个端口,譬如80端口,但实际上我们转发给在8080端口的tomcat,由它来处理真正的请求,当请求完成后,tomcat返回,但数据此时没直接返回,而是直接给nginx,由nginx进行返回,这里,我们会以为是nginx进行了处理,但实际上进行处理的是tomcat。 实际上我们配置了Nginx反向代理后,系统的物理结构可能是下面这样子的,当我们访问一个域名/IP地址时,实际访问的是我们配置的Nginx服务器,Nginx服务器的真实身份只是代理,它代理了许多不同的真正服务器(如下图中的Tomcat,Resin,IIS等)。 虽然配置反向代理比较麻烦,但是它的作用性还是很大滴。一方面是为了安全性考虑,另一方面是提供应用的访问性能。说到上面的方式,也许很多人又会想起来,这样可以把静态文件交由nginx来进行处理。对,很多用到nginx的地方都是作为静态伺服器,这样可以方便缓存那些静态文件,比如CSS,JS,html,htm等文件。 二、基础教程 1、前期环境准备 准备两个解压版tomcat,同时启动两个tomcat。 nginx官网下载解压版nginx。 创建一个简单的web项目。为了直观的区分访问的哪个tomcat,在页面写上标记8081、8082。 分别部署到对应的tomcat下。如图:​​​​ ​ 2、配置nginx 进入nginx-1.10.1\conf路径,修改配置文件nginx.conf。 1、配置服务器组,在http{}节点之间添加upstream配置。(注意不要写localhost,不然访问速度会很慢) upstream nginxDemo { server 127.0.0.1:8081;…

Continue Reading →