大型网站系统架构实践（四）http层负载均衡之haproxy实践篇（一）

方案

上篇文章讲到了负载均衡的相关理论知识，这篇文章我打算讲讲实践方法以及实践中遇到的问题

方案：haproxy http层负载均衡

安装一个haproxy服务，两个web服务

haproxy：192.168.1.227:80

web1 http://192.168.1.226:8081/login

web2 http://192.168.1.246:8888/login

web服务自行准备，文章中就不说了

负载均衡算法为轮询调度

会话保持实现方式为cookie识别，插入cookie

优点：

1 配置简单

2 提供会话保持功能

3 性能不错

安装与配置

安装

tar -zxvf haproxy-1.49.tar.gz

cd haproxy-1.4.9

make TARGET=linux26 PREFIX=/haproxy

make install PREFIX=/haproxy创建日志目录
mkdir /home/haproxy/logs/
创建配置文件目录
mkdir /etc/haproxy/

PREFIX=/haproxy ：安装目录前缀

启动程序将安装在 /haproxy/sbin/haproxy

配置

global  log 127.0.0.1   local3  #log 127.0.0.1  local1 notice  #log loghost    local0 info  maxconn 4096#chroot /usr/local/haproxy#chroot /home/haproxy  uid 502 gid 502daemon  nbproc 1  pidfile /home/haproxy/logs/haproxy.pid  #debug  #quiet  defaults  log     global mode    http  option  httplog  option  dontlognull  option  forwardfor  option  redispatch log     127.0.0.1 local3retries 3  maxconn 32000  balance roundrobin  stats   uri     /haproxy-stats  contimeout      5000  clitimeout      50000  srvtimeout      50000  listen web_proxy *:80appsession JSESSIONID len 52 timeout 3h#插入cookie的方式cookie SRV insert indirect nocache#模式有http tcp healthmode httpstats enablestats hide-version#查看状态stats uri /haproxy-statsstats refresh 10smonitor-uri /haproxy_test#负载均衡方案:轮调balance roundrobinoption httpclose#后端可以获取客户端的真实ipoption forwardfor#健康检查option httpchk HEAD /login HTTP/1.0#option  httpchk GET /ping.jsp #后端真实服务server  webA 192.168.1.226:8081 cookie A check  server  webB 192.168.1.246:8888 cookie B check

这里注意配置检查地址

option httpchk HEAD /login HTTP/1.0

启动

/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg

查看进程

ps -ef|grep haproxy

关闭进程

kill –9 pid

查看监控页面

http://192.168.1.227/haproxy-stats

如下图：注意状态一栏显示200，如果不是则表示web服务器未启动，或者健康检查链接不可访问

测试

然后打开不同的浏览器，模拟用户访问

http://192.168.1.227/login/

会看到

证明请求被分发到不同的web服务器了

查看cookie

cookie被加入了SRV=A

会话保持的流程

1.客户端首次请求，经过haproxy到web服务端时，web服务端set-cookie并响应到haproxy

2.haproxy在cookie后插入SRV=A，并响应客户端

3.客户端第二次请求，经过haproxy时，haproxy将srv后缀去掉，然后请求服务端

总结

该方案解决的问题

1.负载均衡，并解决web服务的单点故障

2.会话保持

存在的缺点

1.web服务器的session保存存在单点故障，即其中一台web服务器宕机之后，存储在上面的session也会丢失

2.负载均衡服务器存在单点故障

下一篇文章将讨论如何解决以上2个缺点

上篇文章大型网站系统架构的演进（三）如何提高网站的高可用和高性能

下篇文章大型网站系统架构的演进（五）深入探讨web应用高可用方案

转载于:https://www.cnblogs.com/tangyanbo/p/4409841.html

大型网站系统架构实践（四）http层负载均衡之haproxy实践篇（一）相关推荐

大型网站系统架构实践（五）深入探讨web应用高可用方案
从上篇文章到这篇文章,中间用了一段时间准备,主要是想把东西讲透,同时希望大家给与一些批评和建议,这样我才能有所进步,也希望喜欢我文章的朋友,给个赞,这样我才能更有激情,呵呵. 由于本篇要写的内容有点多 ...
大型网站系统架构实践（一）从简单到复杂
前言写这篇文章的目的是想用来帮助自己思考和理清头绪,以及如何从一个简单的网站架构演进发展成一个大型网站架构,主要侧重在技术方面简单的网站由于我没有做过php,那么就以jsp为例,jsp做网站前端 ...
大型网站系统架构系列：负载均衡详解（一）
大型网站系统架构系列:负载均衡详解(一) 2016-03-20 架构说面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比 ...
大型网站系统架构的演化
大型网站系统架构的演化来源:http://www.cnblogs.com/leefreeman/ 声明:作者授权转载. 前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的 ...
大型网站系统架构分析--转
大型网站系统架构分析原文地址:http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html 千万级的注册用户,千万级的帖子,nTB级的附件 ...
解读大型网站系统架构的演化
解读大型网站系统架构的演化大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段. 作者:李平来源:LEE的博客前言一 ...
大型网站系统架构的演化【转自飘扬的红领巾】
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...
【面试精选】关于大型网站系统架构你不得不懂的10个问题
该文已加入笔主的开源项目--JavaGuide(一份涵盖大部分Java程序员所需要掌握的核心知识的文档类项目),地址:github.com/Snailclimb/- .觉得不错的话,记得点个Star. ...
亿级流量网站架构核心技术_关于大型网站系统架构你不得不懂的10个问题
来自:JavaGuide(微信号:JavaGuide) 下面这些问题都是一线大厂的真实面试问题,不论是对你面试还是说拓宽知识面应该都很有帮助.之前发过一篇8 张图读懂大型网站技术架构可以作为不太了解 ...

大型网站系统架构实践（四）http层负载均衡之haproxy实践篇（一）

方案

安装与配置

大型网站系统架构实践（四）http层负载均衡之haproxy实践篇（一）相关推荐

最新文章

热门文章