理解web服务器和数据库的负载均衡以及反向代理_服务器其它

但是若该网站平均每秒的请求是200多次,那么问题就来了:这已经是最好的web服务器了,我该怎么办?同样的情景也适用于数据库。要解决这种问题,就需要了解“负载均衡”的原理了。

web服务器如何做负载均衡

为web服务器做负载均衡适用的的较多的方式是DNS重定向和反向代理,其他的方式原理也是很类似。

我们多次ping一下百度,会发现回复的IP会有所不同,例如第一次的结果为:

复制代码 代码如下:

正在 Ping baidu.com [220.181.111.86] 具有 32 字节的数据:
来自 220.181.111.86 的回复: 字节=32 时间=27ms TTL=51
来自 220.181.111.86 的回复: 字节=32 时间=27ms TTL=51
来自 220.181.111.86 的回复: 字节=32 时间=27ms TTL=51

过一会再Ping一次,结果可能就变了:

复制代码 代码如下:

正在 Ping baidu.com [220.181.111.85] 具有 32 字节的数据:
来自 220.181.111.85 的回复: 字节=32 时间=27ms TTL=51
来自 220.181.111.85 的回复: 字节=32 时间=27ms TTL=51
来自 220.181.111.85 的回复: 字节=32 时间=29ms TTL=51

使用nslookup命令可以看到多个ip与baidu.com对应。在这里用到的就是DNS重定向技术,原理很简单:DNS服务器保存某域名对应的多个IP,客户端发出DNS请求时DNS服务器根据算法将IP发回给客户端;发送回的一般是一个IP地址集合,但是每次的排序不同,第一次的第一个IP为201.11.11.1,第二次的第一个可能是201.11.11.2,客户端使用的是第一个IP——简单地说,就是客户端每次获取的域名的IP可能不同。不同的IP对应不同的web服务器,但是这些web服务器的内容应该是一样的。

我们从下图理解反向代理:

客户端向反向代理发送HTTP请求报文(若该网站有域名,域名的IP是反向代理服务器的外网IP),反向代理将请求报文随机发送给一个web服务器,web服务器将HTTP响应报文发送给反向代理,反向代理再将这报文返回给客户端。既然这样简单,我们就可以着手实现一个简单的反向代理。

在linux mint 15 下安装apache和nginx服务器,在apache的80端口的文档根目录下创建文件index.html,内容如下:

复制代码 代码如下:

<html>
<head>
<title>index</title>
</head>
<body>
<h1>hello, i am apache</h1>
</body>
</html>

在nginx的8080端口的文档根目录下创建文件index.html,内容如下:

复制代码 代码如下:

<html>
<head>
<title>index</title>
</head>
<body>
<h1>hello, i am nginx</h1>
</body>
</html>

创建源文件simple_reverse_proxy.py,内容如下:

复制代码 代码如下:

#!/usr/bin/python
#-*-encoding:utf8-*-
'''
这是一个简单的反向代理服务器
'''
import BaseHTTPServer
import urllib2
HOST_NAME = '127.0.0.1'
PORT_NUMBER = 8081  #端口
SERVER_URL=('http://127.0.0.1:80','http://127.0.0.1:8080')
server_choice = 0
class MyHandler(BaseHTTPServer.BaseHTTPRequestHandler):
    def do_GET(s):
        """response to a GET request"""
        global server_choice
        url = SERVER_URL[server_choice]
        print url
        server_choice = (server_choice + 1) % 2
        headers = {'User-Agent': 'Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)'}
        try:
            req = urllib2.Request(url, None, headers)
            response = urllib2.urlopen(req)
            html = response.read()
            #print html
            s.send_response(200);
            s.send_header("Content-type", "text/html")
            s.end_headers()
            s.wfile.write(html)
        except:
            s.send_response(404);
            s.send_header("Content-type", "text/html")
            s.end_headers()
            s.wfile.write('<h2>404</h2>')
if __name__ == '__main__':
    server_class = BaseHTTPServer.HTTPServer
    httpd = server_class((HOST_NAME, PORT_NUMBER), MyHandler)
    try:
        httpd.serve_forever()
    except KeyboardInterrupt:
        pass
    httpd.server_close()

启动apache、nginx,并运行simple_reverse_proxy.py。我们在浏览器中打开http://127.0.0.1:8081,我们可以看到:


刷新一下可以看到:

而simple_reverse_proxy.py会有以下信息输出:

复制代码 代码如下:

bash >> ./simple_reverse_proxy.py
http://127.0.0.1:80
127.0.0.1 - - [05/Sep/2013 19:25:02] "GET / HTTP/1.1" 200 -
http://127.0.0.1:8080
127.0.0.1 - - [05/Sep/2013 19:25:43] "GET / HTTP/1.1" 200 -

当然,开源世界里已经有很多优秀的反向代理服务器了,例如Nginx。

只要理解了反向代理的原理,更复杂的架构也容易去实现。

数据库的负载均衡

对于大型网站,一个数据库系统肯定会遇到无法负担大量的读请求、写请求的情况。那么我们怎么来通过负载均衡来实现高并发的读写请求呢?

这其中一个很好的方法就是读写分离:将原本针对一个数据库服务器的读写请求分成读请求和写请求,向一个(或者多个)数据库服务器发送写请求,向另外一个(或多个)服务器发送读请求,这可以明显的提高响应时间。不过其中有一个难点,就是必须保持多个数据库服务器中的数据是一致的,不用担心,很多数据库系统已经实现了这个功能。下面是一个架构示例:

上图中其实有一个写写冲突的问题,想象以下场景:

该系统用于存放某网站的用户注册信息,该网站不允许用户名相同,且以用户名为唯一主键,所以在单数据库架构中必须涉及到事务的处理。现在在这个负载均衡的数据库架构中,用户A要注册用户名为xiaoming,这个写请求分配给了db server 1;与此同时用户B同样注册用户名xiaoming,如果写请求分配给了db server1,就不会有问题发生,可是如果分配给db server 2呢?两个db server分别存放了不同用户的用户名相同的用户信息!解决的方法很简单,写请求的分配不能用随机算法,应该使用哈希映射,例如注册的用户名首字母为x时,写请求分配各 db server2,其他写请求一律分配给db server 1。

另外一个问题,这种架构为开发应用提供了很大的灵活性,就是这种架构不适用于某些ORM框架,解决方法就是在这个架构上再加上一层——“数据库代理”。例如对于MySQL,就有MySQL Proxy这样的解决方案。

时间: 2024-10-28 01:42:51

理解web服务器和数据库的负载均衡以及反向代理_服务器其它的相关文章

负载均衡与反向代理的区别

问题描述 负载均衡与反向代理的区别 反向代理是不是就是负载均衡+本地缓存?是不是反向代理就能完全取代负载均衡? 解决方案 反向代理代理的是服务器.是从客户端连接的角度来看的.对于客户端来说,它看不到后面的真正的应用服务器 而负载均衡是前段进行资源负载分配调度,让多台相同功能的服务器实现尽可能类似的负载.从而最大化效率 两者目的不一样,但是最终实现有点相同 解决方案二: 反向代理顾名思义就是代理. 一般的代理是,你上网的时候,你请求网页不直接和网站通讯,而是发给代理服务器,代理服务器和网站通讯,获

Nginx配置负载均衡及反向代理

简单介绍: 1.Nginx优点 Nginx 负均衡实现比较简单,可配置性很强,可以按URL做负载均衡,默认对后端有健康检查的能力.后端机器少的情况下(少于10台)负载均衡能力表现好.其优点主要有: 1)功能强大,支持高并发连接,内存消耗少:官方测试能够支撑5万并发连接,在实际生产环境中跑到2-3 万并发连接数,且在3万并发连接下,开启的10个Nginx 进程才消耗150M内存(15M*10=150M). 2)成本低廉:Nginx 为开源软件,免费使用. 3)Nginx 工作在网络的7 层,所以它

详解Nginx HTTP负载均衡和反向代理配置_nginx

当前大并发的网站基本都采用了Nginx来做代理服务器,并且做缓存,来扛住大并发.先前也用nginx配置过简单的代理,今天有时间把整合过程拿出来和大家分享,不过其中大部分也是网上找来的资源. nginx完整的反向代理代码如下所示  : [root@data conf]# vim nginx.conf user www www; worker_processes 10; error_log /var/log/nginx/nginx_error.log; pid logs/nginx.pid; wor

CentOS中nginx负载均衡和反向代理的搭建

1: 修改centos命令行启动(减少内存占用): vim /etc/inittab     id:5:initdefault:  --> 修改5为3  若要界面启动使用 startx 2:安装jdk 1)解压:jdk-7u55-linux-i586.tar.gz        [root@localhost jdk]# tar -zxvf jdk-7u55-linux-i586.tar.gz 2)复制:[root@localhost jdk]# cp -rf jdk1.7.0_55/ /usr

服务器集群和负载均衡如何实现?

问题描述 请教一个问题,javasocket服务器如何实现服务器集群和负载均衡?目前以项目遇到这个问题,请大神指点一下! 解决方案 解决方案二:socket与硬件有关,是指定到某台机器的某个端口的.所以一般我们在Socket前用负载均衡,根据业务特性,有nginx,LVS,F5硬件等).至于集群,那和具体业务相关.像普通的HTTP,各HTTP服务器有SESSION共享和同步就行了.

asp.net 服务器读取数据库信息生成 excel,然后保存到服务器的临时文件夹下

问题描述 asp.net服务器读取数据库信息生成excel,然后保存到服务器的临时文件夹下,这个怎么实现啊?郁闷了.怎么弄.那个文件都会在客户端输出下载.我只需要保存到服务器的目录下就行了. 解决方案 解决方案二:1.用ExcelCOM生成:2.或者找个第3方生成Excel的比如POI解决方案三: 解决方案四:C#导出Excel的函数(可根据实际需要进行相应修改)//导出Excel的方法privatevoidExportExcel(){DataSetds=dtsSelect;//数据源if(ds

kangle反向代理FTP服务器

使用kangle有一段时间,感觉kangle还是非常强大的.我们今天就来介绍一下,如果通过kangle反向代理FTP服务器.在此说明kangle目前不支持FTP反向代理功能,此文章中介绍的反向代理FTP服务器其实是利用"曲线救国"的方式来实现的,主要还是利用kangle的HTTP反向代理功能. 既然要将反向代理FTP服务器,那肯定要在内网中的一台服务器上已经安装并设置好了FTP的相关权限. 在此我使用的是Wing FTP这款软件,为什么要使用这款软件呢?各位可以看看我前几天写的那篇文章

web集群服务的负载均衡方案选择与实现

web 集群系统,是由一群同时运行同一个web应用的服务器组成的集群系统,在外界看来,就像是一个服务器一样.为了均衡集群服务器的负载,达到优化系统性能的目的,集群服务器将众多的访问请求,分散到系统中的不同节点进行处理.从而实现了更高的有效性和稳定性,而这也正是基于Web的企业应用所必须具备的特性. 高可靠性可以看作为系统的一种冗余设定.对于一个特定的请求,如果所申请的服务器不能进行处理的话,那么其他的服务器能不能对之进行有效的处理呢?对于一个高效的系统,如果一个Web服务器失败的话,其他的服务器

大型Web应用运行时 PHP负载均衡指南

过去当运行一个大的web应用时候意味着需要运行一个大型的web服务器.因为你的应用吸引了大量的用户,你将不得不在你的服务器里增加更多的内存和处理器.今天,"大型服务器"模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术. "更多小服务器"的优势超过过去的"大型服务器"模式体现在两个方面: 1. 如果服务器宕机,那么负载均衡系统将停止请求到宕机的服务器,转而分发负载到其他正常运行的服务器上. 2. 扩展你的服务器更加容易.你要做的