大型网站系统架构的演进(四)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/

配置

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 502
       daemon
       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 local3
       retries 3
       maxconn 32000
       balance roundrobin
       stats   uri     /haproxy-stats
       contimeout      5000
       clitimeout      50000
       srvtimeout      50000  

  listen   web_proxy *:80
       appsession JSESSIONID len 52 timeout 3h
       #插入cookie的方式
        cookie SRV insert indirect nocache
       #模式有http tcp health
       mode http
       stats enable
       stats hide-version
       #查看状态
        stats uri /haproxy-stats
       stats refresh 10s
       monitor-uri /haproxy_test
       #负载均衡方案:轮调
        balance roundrobin
       option httpclose
       #后端可以获取客户端的真实ip
       option 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

启动

/usr/local/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个缺点

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

目录 大型网站系统架构的演进目录

时间: 2024-08-13 11:48:16

大型网站系统架构的演进(四)http层负载均衡之haproxy实践篇(一)的相关文章

大型网站系统架构的演进目录

大型网站系统架构的演进(一) 大型网站系统架构的演进(二)分布式模块之间的通信 大型网站系统架构的演进(三)如何提高网站的高可用和高性能

阿里P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程

阶段一.单机构建网站 网站的初期,我们经常会在单机上跑我们所有的程序和软件.此时我们使用一个容器,如tomcat.jetty.jboos,然后直接使用JSP/servlet技术,或者使用一些开源的框架如maven+spring+struct+hibernate.maven+spring+springmvc+mybatis:最后再选择一个数据库管理系统来存储数据,如mysql.sqlserver.oracle,然后通过JDBC进行数据库的连接和操作. 把以上的所有软件都装载同一台机器上,应用跑起来

P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程

阶段一.单机构建网站 网站的初期,我们经常会在单机上跑我们所有的程序和软件.此时我们使用一个容器,如tomcat.jetty.jboos,然后直接使用JSP/servlet技术,或者使用一些开源的框架如maven+spring+struct+hibernate.maven+spring+springmvc+mybatis:最后再选择一个数据库管理系统来存储数据,如mysql.sqlserver.oracle,然后通过JDBC进行数据库的连接和操作. 把以上的所有软件都装载同一台机器上,应用跑起来

大型网站系统架构的演进(三)如何提高网站的高可用和高性能

随着网站的业务越来越多,网站的服务就变的很重要,假设某天你的服务器挂了,会不会是一个天大的灾难呢?而且这种事情发生的概率还不小,断电了,服务器硬盘坏了,内存坏了等等,都会使你的系统挂掉,而且高并发的访问有时候也会使系统资源耗尽,然后导致服务器宕机,那么解决方案呢,那就是集群,将相同的系统分别放到不同的web服务器或者硬件服务器,这样其中一个挂掉了,网站还可以正常运营. Web应用集群 首先我们应该对web前置做集群,我们的方案是用Haproxy做http协议层的负载均衡,后端部署多个web前置,

大型网站系统架构的演进(一)(转)

前言 写这篇文章的目的是想用来帮助自己思考和理清头绪,以及如何从一个简单的网站架构演进发展成一个大型网站架构,主要侧重在技术方面 简单的网站 由于我没有做过php,那么就以jsp为例,jsp做网站前端,以电子商务网站为例,描述一个简单的网站架构 前端 jsp+css+js 后端 java ssh Web容器 tomcat 数据库 mysql 开发人员,美工1个,前端一个,java一个 部署方案为: 一台服务器,部署tomcat和mysql 架构图如下: 应用和数据库分布式部署 那么网站运行一段时

大型网站系统架构的演进(二)分布式模块之间的通信

上一篇文章中讲到了分布式部署之后,各个模块要通过网络进行通信,那么如何通信,用什么协议呢? 可选的方案有http tcp/ip(socket)等 http短连接通信方案 基于http协议,xml报文传输 客户端具体框架为httpclient,服务端为struts2 客户端和服务端的通信在内网 该方案我们实行过一段时间,发现存在性能问题,首先是短连接,在并发量较大的时候,开启大量的tcp连接,这样连接资源容易耗尽,客户端首先成为瓶颈,tps上不去. 我总结的几点原因: 1.每次通信都重新开启新的t

大型网站系统架构实践(六)深入探讨web应用集群Session保持

原理 在第三,四篇文章中讲到了会话保持的问题,而且还遗留了一个问题,就是会话保持存在单点故障, 当时的方案是cookie插入后缀,即haproxy指负责分发请求,应用服务自行保持用户会话,如果应 用服务器宕机,则session会丢失. 现在来温习下解决方案 方案1:session复制 原理 就是将1台服务器的session复制到其它所有的服务器上,这样无论访问哪台服务器,都会得到用户 的session 优点 不存在单点故障问题 缺点 当服务器的数量比较大时,session同步将会变得相当耗时 方

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

大型网站系统架构的演化

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各