nginx负载均衡配置

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

≯℡__Kan透↙ 提交于 2019-12-03 23:18:28
http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴,点击访问该目录可获取更多内容。 首先,所谓网站的伸缩性,指 不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中,最重要的技术就是 服务器集群 ,通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩   (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性;   (2)横向分离:将不同的业务模块分离部署,实现系统的伸缩性; 1.2 单一功通过集群规模实现伸缩   使用服务器集群,即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说,集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同,技术实现也有很大的区别。  It is said that 当一头牛拉不动车的时候,不要去寻找一头更强壮的牛,而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿   (1)应用服务器应该被设计成 无状态 的,即应用服务器不存储请求上下文信息;构建集群后

复杂均衡方案

半腔热情 提交于 2019-12-03 21:39:36
二层负载均衡: 通过改写报文的目标MAC地址为上游服务MAC地址。源IP地址和目标IP地址是没有改变的,负载均衡服务器和真实服务器共享同一个VIP,如LVS DR工作模式。 四层负载均衡: 根据端口将报文转发到上游服务器(不同的IP地址+端口),如LVS NAT模式、HaProxy。 七层负载均衡: 根据端口号和应用协议如HTTP协议的主机名、URL,转发报文到上游服务器(不同的IP地址+端口,如Haproxy、Nginx)。 需要reload的方式 consul+consul-template方式, reload是有损耗的。 不需要reload方式(动态实现负载均衡) Tengine的Dyups模块 微博的Upsync OpenResty的balancer_by_lua 微博采用Upsync+consul,又拍云使用开源的slardar(Consul+balancer_by_lua) 动态添加/删除上有吧服务器,需要重启nginx,像HTTP动态负载均衡那样。 nginxu商业版 nginx-strean-upsync-module openResty提供的stream-lua-nginx-model尚未实现balancer_by_lua,暂时无法使用。 扩展: Liunx 三大主流(LVS、Nginx、HAproxy)负载均衡对比 LVS : 1.抗负载能力强,性能高

反向代理负载均衡

回眸只為那壹抹淺笑 提交于 2019-12-03 17:37:05
使用反向代理服务器可以将请求转发给内部的Web服务器,使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术,让代理服务器将请求均匀转发给多台内部Web服务器之一上,从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部Web服务器,而 这种代理方式是多个客户使用它访问内部Web服务器,因此也被称为反向代理模式 。 概念 实现这个反向代理能力并不能算是一个特别复杂的任务,但是在负载均衡中要求特别高的效率,这样实现起来就不是十分简单的了。每针对一次代理,代理服务器就 必须打开两个连接,一个为对外的连接,一个为对内的连接,因此对于连接请求数量非常大的时候,代理服务器的负载也就非常之大了,在最后反向代理服务器会成 为服务的瓶颈。例如,使用Apache的mod_rproxy模块来实现负载均衡功能时,提供的并发连接数量受Apache本身的并发连接数量的限制。一般来讲,可以使用它来对连接数量不是特别大,但每次连接都需要消耗大量处理资源的站点进行负载均衡,例如搜寻。 使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能,具备额外的安全性,外部客户不能直接访问真实的服务器。并且实现起来可以实现较好的负载均衡策略,将负载可以非常均衡的分给内部服务器,不会出现负载集中到某个服务器的偶然现象。

Nginx/LVS/HAProxy优缺点

强颜欢笑 提交于 2019-12-03 17:36:54
PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。 一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案:Web前端采用Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 Nginx的优点是: 1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构

关于高性能负载均衡架构,这些知识点大多数人不知道

北战南征 提交于 2019-12-03 15:59:24
单服务器无论如何优化,无论采用多好的硬件,总会有一个性能天花板,当单服务器的性能无法满足业务需求时,就需要设计高性能集群来提升系统整体的处理性能。 高性能集群的本质很简单,通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点:同样的输入数据和逻辑,无论在哪台服务器上执行,都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分,需要设计合理的任务分配策略,将计算任务分配到多台服务器上执行。 高性能集群的复杂性主要体现在需要增加一个任务分配器,以及为任务选择一个合适的任务分配算法。对于任务分配器,现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性,会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。而实际上任务分配并不只是考虑计算单元的负载均衡,不同的任务分配算法目标是不一样的,有的基于负载考虑,有的基于性能(吞吐量、响应时间)考虑,有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语,这里我也用“负载均衡”来代替“任务分配”,但请你时刻记住,负载均衡不只是为了计算单元的负载达到均衡状态。 负载均衡分类 常见的负载均衡系统包括3种:DNS负载均衡、硬件负载均衡和软件负载均衡。 DNS负载均衡 DNS是最简单也是最常见的负载均衡方式,一般用来实现地理级别的均衡。例如,北方的用户访问北京的机房

漫谈互联网架构

对着背影说爱祢 提交于 2019-12-03 14:07:00
互联网的标准技术架构如下图所示,这张图基本上涵盖了互联网技术公司的大部分技术点,不同的公司只是在具体的技术实现上稍有差异,但不会跳出这个框架的范畴。 存储层技术SQL SQL即我们通常所说的关系数据。前几年NoSQL火了一阵子,很多人都理解为NoSQL是完全抛弃关系数据,全部采用非关系型数据。但经过几年的试验后,大家发现关系数据不可能完全被抛弃,NoSQL不是No SQL,而是Not Only SQL,即NoSQL是SQL的补充。 所以互联网行业也必须依赖关系数据,考虑到Oracle太贵,还需要专人维护,一般情况下互联网行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费,拿来就用;但缺点是性能相比商业数据库要差一些。随着互联网业务的发展,性能要求越来越高,必然要面对一个问题:将数据拆分到多个数据库实例才能满足业务的性能需求(其实Oracle也一样,只是时间早晚的问题)。 数据库拆分满足了性能的要求,但带来了复杂度的问题:数据如何拆分、数据如何组合?这个复杂度的问题解决起来并不容易,如果每个业务都去实现一遍,重复造轮子将导致投入浪费、效率降低,业务开发想快都快不起来。 所以互联网公司流行的做法是业务发展到一定阶段后,就会将这部分功能独立成中间件,例如百度的DBProxy、淘宝的TDDL。不过这部分的技术要求很高,将分库分表做到自动化和平台化

PHP解决网站大数据大流量与高并发

与世无争的帅哥 提交于 2019-12-03 14:03:48
第一,硬件方面 普通的一个p4的服务器每天最多能支持大约10万左右的IP,如果访问量超过10W那么需要专用的服务器才能解决,如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度 有:网络-硬盘读写速度-内存大小-cpu处理速度。 第二,软件方面 第一个要说的就是数据库,首先要有一个很好的架构,查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取,如果条件允许 ,一般MySQL服务器最好安装 在Linux操作系统中 。关于apache和 nginx 在高并发的情况下推荐使用 nginx ,ginx是Apache服务器不错的替代品。nginx内存消耗少 官方测试能够支撑5万并发连接,在实际生产环境中跑 到2~3万并发连接数。 php 方面不需要的模块尽量关闭,使用memcached,Memcached 是一个高性能的分布式内存对象缓存系统,不使用数据库直接从内存当中调数据,这样大大提升了速 度,iiS或Apache启用GZIP压缩优化网站,压缩网站内容大大节省网站流量。 第二,禁止外部的盗链。 外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对 于自身的图片或者文件盗链,好在目前可以简单地通过refer来控制盗链,Apache自 己就可以通过配置来禁止盗链,IIS也有一些第三方的ISAPI可以实现同样的功能。当 然

Nginx服务器之负载均衡策略(6种)

房东的猫 提交于 2019-12-03 13:59:39
一、关于Nginx的负载均衡    在服务器集群中,Nginx起到一个代理服务器的角色(即反向代理),为了避免单独一个服务器压力过大,将来自用户的请求转发给不同的服务器。详情请查看我的 另一篇博客 。 二、Nginx负载均衡策略    负载均衡用于从“upstream”模块定义的后端服务器列表中选取一台服务器接受用户的请求。一个最基本的upstream模块是这样的,模块内的server是服务器列表: #动态服务器组 upstream dynamic_zuoyu { server localhost:8080; #tomcat 7.0 server localhost:8081; #tomcat 8.0 server localhost:8082; #tomcat 8.5 server localhost:8083; #tomcat 9.0 }    在upstream模块配置完成后,要让指定的访问反向代理到服务器列表: #其他页面反向代理到tomcat容器 location ~ .*$ { index index.jsp index.html; proxy_pass http://dynamic_zuoyu; }    这就是最基本的负载均衡实例,但这不足以满足实际需求;目前Nginx服务器的upstream模块支持6种方式的分配: 负载均衡策略 轮询 默认方式 weight

nginx+tomcat 负载均衡

雨燕双飞 提交于 2019-12-03 13:58:01
第一篇nginx for windows 安装: https://www.cnblogs.com/blogxiao/p/8761734.html 第二篇: tomcat 的部署: 1.nginx可以作为反向代理服务器,作为客户端发送请求的门户,这个门户将接受的请求分均衡发给多个应用服务器,达到高负载的效果,典型的就比如tomcat应用服务器。 2.解释一下反向代理:正向和反向是针对服务器来说的,服务器发送给客户端的是正向,客户端向服务器发起的是反向。 3.先下载一个tomcat,然后拷贝成两份 4.在eclipse新建一个简单的web项目,将生成的放到tomcat 的webapps 的目录下 5.开始配置tomcat ,tomcat 最主要的就是端口号 和 项目根路径,配置tomcat 的server 文件,文件的路径tomcat1->conf->server.xml tomcat1端口号配置 <Server port="8006" shutdown="SHUTDOWN"> <Connector connectionTimeout="20000" port="8090" protocol="HTTP/1.1" redirectPort="8443"/> <Connector port="8001" protocol="AJP/1.3" redirectPort="8443"/>

nginx upstream 容错机制

给你一囗甜甜゛ 提交于 2019-12-03 11:54:11
1. 摘要 (1) 结论 详细描述了nginx记录失效节点的6种状态(time out、connect refuse、500、502、503、504,后四项5XX需要配置proxy_next_upstream中的状态才可以生效)、失效节点的触发条件和节点的恢复条件、所有节点失效后nginx会进行恢复并进行重新监听。 (2) Nginx 负载均衡方式介绍 Nginx的负载均衡方式一共有4种:rr(轮询模式)、ip_hash、fair、url_hash。 (3) Ngxin负载均衡和相关反向代理配置内容 Nginx负载均衡和与容错相关的反向代理的配置。 (4) 获取后端流程 后端server的自动容错流程图。 (5) 测试环境和测试结果 针对几种错误方式进行自动容错测试。 2. 结论 (1) nginx 判断节点失效状态 Nginx 默认判断失败节点状态以connect refuse和time out状态为准,不以HTTP错误状态进行判断失败,因为HTTP只要能返回状态说明该节点还可以正常连接,所以nginx判断其还是存活状态;除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理,在next_upstream过程中,会对fails进行累加,如果备用机处理还是错误则直接返回错误信息