负载均衡

HAPROXY简介 HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种负载均衡解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。 2、HAProxy的特点是： 1、HAProxy支持虚拟主机。 2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。 3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。 4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，可以用LVS+Keepalived对MySQL主从做负载均衡。 5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种： 　　① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的； 　　② static-rr

Apache和Nginx对比 功能对比 Nginx和Apache一样，都是HTTP服务器软件，在功能实现上都采用模块化结构设计，都支持通用的语言接口，如PHP、Perl、Python等，同时还支持正向和反向代理、虚拟主机、URL重写、压缩传输、SSL加密传输等。 在功能实现上，Apache的所有模块都支持动、静态编译，而Nginx模块都是静态编译的， 对FastCGI的支持，Apache对Fcgi的支持不好，而Nginx对Fcgi的支持非常好； 在处理连接方式上，Nginx支持epoll，而Apache却不支持； 在空间使用上，Nginx安装包仅仅只有几百K，和Nginx比起来Apache绝对是庞然大物。 Nginx相对apache的优点 轻量级，同样起web 服务，比apache 占用更少的内存及资源 静态处理，Nginx 静态处理性能比 Apache 高 3倍以上 抗并发，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速啊 apache相对nginx的优点 rewrite，比nginx 的rewrite

所有文章 https://www.cnblogs.com/lay2017/p/11908715.html 正文 ribbon是springcloud封装的一个基于http客户端负载均衡的组件。springcloud的openfeign集成使用了ribbon。所以如果你使用openfeign，那么也会很轻易得使用到ribbon。本文将从openfeign切入，看看它是怎么来使用到ribbon这个客户端负载均衡组件的。 LoadBalancerFeignClient提供openfeign的负载均衡实现 在讲openfeign的时候我们说到，最后代理类其实就是发起http请求，并解码返回的字节码内容。回顾一下代码 Object executeAndDecode(RequestTemplate template, Options options) throws Throwable { Request request = targetRequest(template); Response response; try { response = client.execute(request, options); } catch (IOException e) { } boolean shouldClose = true; try { if (Response.class == metadata

网络专用术语，负载均衡建立在现有网络结构之上，它提供了一种 廉价 有效 透明 的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的 灵活性 和可用性。 早期的方法是使用DNS做负载，通过给客户端解析不同的IP地址，让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题，在做出调度策略改变以后，由于DNS各级节点的缓存并不会及时的在客户端生效，而且DNS负载的调度策略比较简单，无法满足业务需求，因此就出现了负载均衡。 客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面，同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。 负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层，主要工作是转发，它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。 　七层负载均衡工作在OSI模型的应用层，因为它需要解析应用层流量，所以七层负载均衡在接到客户端的流量以后，还需要一个完整的TCP/IP协议栈。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去

一.本文所涉及的内容（Contents） 本文所涉及的内容（Contents） 背景（Contexts） 架构原理（Architecture） 测试环境（Environment） 安装Moebius（Install） Moebius测试（Testing） 负载均衡测试（Load Balancing Testing） 高可用性测试（Failover Testing） 数据安全性测试（Security Testing） 总结（Summary） 二.背景（Contexts） 　　前几天在SQL Server MVP宋大侠（宋沄剑）的一篇文章" 数据库集群技术漫谈 ”中看到了格瑞趋势在SQL Server上的负载均衡产品Moebius，搞数据库的都知道：在Oracle上有RAC，MySQL也有对应的方案（可参考： MySQL搭建Amoeba系列 ），而SQL Server上直到SQL Server 2012版本的AlwaysOn到来，微软都没有提供一个负载均衡方案，我从宋大侠那里找来一个Moebius的测试版本进行一下测试，下面是我测试的过程。 三.架构原理（Architecture） （Figure1：Moebius for SQL Server逻辑架构图） 四.测试环境（Environment） 　　　　操作系统：Windows Server 2008 R2 　　　　数据库版本：SQL

Nginx 负载均衡会话保持 背景 负载均衡时，如果APP需要保持特定状态的时候，就要保证同一用户的 session 会被分配到同一台服务器上。 实现方案 使用cookie 将用户的 session 存入 cookie 里，当用户分配到不同的服务器时，先判断服务器是否存在该用户的 session，如果没有就先把 cookie 里面的 sessoin 存入该服务器，实现 session 会话保持。缺点是存入 cookie 有安全隐患。 使用缓存 利用 memcache ，Redis 等缓存分布式的特点，可以将所有服务器产生的 session 存入同一台服务器的缓存中，实现 session 共享。这样安全性比较高，而且从内存中读取 session 比从文件中读取速度快。 使用 ip_hash 如果是 nginx 服务器的负载均衡，可以在 upstream 里设置 ip_hash，每个请求按访问 ip 的 hash 结果分配，映射到固定某一台的服务器。缺点是可能导致负载不均衡。 upstream https_proxy { server 172.26.114.89:8443; server 172.26.114.93:8443; ip_hash; } 注：ip_hash 不能和 weight 在一起使用。 注：使用案例，使用 Spring 框架，Redis 共享 Session

前言 Nginx做的代理后面SpringBoot的项目，1N3T的架构，Tomcat的配置也进行了相应的调优。 配置 这里主要来简单的说下Nginx的端口负载均衡，具体的大家可以参考 Nginx文档 | Nginx 烹调书(Nginx Cookbook 中文版) | Nginx文档 upstream是nignx分配方式，默认是轮询 1. 轮询: 轮询是upstream的默认分配方式，即每个请求按照时间顺序轮流分配到不同的后端服务器，若某个后端服务器挂了，会自动剔除。 2. weight: 按着权重的大小进行轮询。 3. ip_hash: 每个请求按照访问ip的hash结果分配，这样每个访客会固定访问一个后端服务器，可以解决session一致问题。 4. fair: 可以根据页面大小、加载时间长短智能的进行负载均衡，响应时间短的后端服务器优先分配请求。 5. url_hash: 与ip_hash类似，但是按照访问url的hash结果来分配请求，使得每个url定向到同一个后端服务器，主要应用于后端服务器为缓存时的场景下。 6. least_conn: 把请求转发给连接数较少的后端服务器 轮询 max_fails=2 fail_timeout=30s 代表在30秒内请求某一应用失败2次，认为该应用宕机，等待30秒再次请求 upstream bakend { server 192.168

Nginx简介 Nginx (engine x) 是一个高性能的 HTTP 和反向代理服务，也是一个 IMAP/POP3/SMTP 服务。 其特点是占有内存少，并发能力强，事实上nginx 的并发能力确实在同类型的网页服务器中 表现较好，中国大陆使用 nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。在连接高并发的情况下，Nginx 是 Apache 服务不错的替代品。 Nginx 的主要功能 静态资源服务器： FTP服务器 + HTTP服务器 虚拟主机 反向代理服务器 负载均衡 来源： https://www.cnblogs.com/HuangJie-sol/p/11939591.html

keepalived实现原理 keepalived采用vrrp热备份协议，实现Linux服务器的多机热备功能 vrrp，虚拟路由冗余协议，是针对路由器的一种备份解决方案 keepalivd案列讲解 keepalived可实现多机热备，每个热备组有多台服务器，最常用的就是双机热备 双机热备的故障切换是由虚拟IP地址的漂移来实现，适用于各种应用服务器 实验原理图 实验环境 虚拟ip 192.168.100.10 lvs1调度服务器 192.168.100.100 lvs2调度服务器 192.168.100.111 web1服务器 192.168.100.200 web2服务器 192.168.100.222 client测试机 192.168.100.20 1，在lvs1调度服务器上安装keepalived，ipvsadm服务 [root@lvs1 ~]# yum install keepalived ipvsadm -y [root@lvs1 ~]# vim /etc/sysctl.conf ##配置路由转发功能 net.ipv4.ip_forward=1 ##路由功能 ##proc响应关闭重定向功能 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf

nginx的作用 Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进行网站的发布处理，另外Nginx可以作为反向代理进行负载均衡的实现。 Web服务器，直接面向用户，往往要承载大量并发请求，单台服务器难以负荷，我使用多台WEB服务器组成 集群，前端使用Nginx负载均衡，将请求分散的打到我们的后端服务器集群中， 实现负载的分发。那么会大大提升系统的吞吐率、请求性能、高容灾 Nginx要实现负载均衡需要用到proxy_pass代理模块配置 Nginx负载均衡与Nginx代理不同地方在于 Nginx代理仅代理一台服务器，而Nginx负载均衡则是将客户端请求代理转发至一组upstream虚拟服务池 Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。 upstream配置 在nginx.conf > http 区域中 upstream django { server 10.0.0.10:8000; server 10.0.0.11:9000; } 在nginx.conf > http 区域 > server区域 > location配置中 添加proxy_pass location / { root html; index index.html index