一次设计高可用网站的实战经验
2012-11-02 00:13
459 查看
我公司前段时间做了一个活动,花了5000块购买了5台虚拟机(每台cpu 为单核2GHZ,内存为1.5GB)做了一个两个月大活动,我设计支持高并发的系统如下:
活动的特点是高并发,逻辑不是很复杂,因此我采用DNS做负载均衡器+nginx做前端+php开发+redis数据库的分布式结构。
使用DNS负载均衡的原因是,我没有更多的钱买负载均衡,其次负载均衡至少得双机主备,再次DNS负载均衡不用部署配置,比lvs简单多了。
为了解决跨域的session问题,我使用了一个redis数据库来存储session的id,这样我的php程序得改成不读取本地session,而去读取redis中的session数据。可以实现跨域的session,不用担心分布式带来的session问题。
同时redis可以用作存储用户数据,例如微博id,生成图片路径等等信息,并发性要比mysql高得多。
为了解决redis单点故障,我添加了一个从redis数据库实时和主redis数据库进行同步,若是主数据库挂了,可以用从数据库来顶替
但是这个网站每台机器上都会生成各自的图片,而这些图片需要在网站上显示,这样的话存在一个问题:
某个用户是通过DNS只能请求到一台机器上(VM3)上,那么在网站上出现的VM2,VM4,VM5的图片就无法显示了。
我冥思苦想,想到了一个好办法:就是利用nginx的proxy模块来实现:
1)VM2上由程序生成的每一张的图片都存在目录(10.200.225.158--VM2的内网ip)下,VM3上由程序生成的每一张的图片都存在目录(10.200.226.56)下...
2) 这样VM2下的图片路径就是http://www.a.com/10.200.225.158/xxx.jpg,VM3下的图片就是http://www.a.com/10.200.226.56/xxx.jpg
3)我VM2上的nginx上配置使得:
3.1)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.225.158/xxx.jpg时就直接读取本地图片
3.2)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.226.56/xxx.jpg时就通过VM2代理读取远程的VM3上的图片
3.3)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.55.39/xxx.jpg时就通过VM2代理读取远程的VM4上的图片
3.4)当用户被DNS解析到VM2上时,若URL是http://www.a.com/110.200.51.143/xxx.jpg时就通过VM2代理读取远程的VM5上的图
也就是说当www.a.com解析到vm2,若是要显示vm3上生成的图片的话,得通过vm2的代理去获取,由于我设置的代理的ip都是内网的,因此不占用外网ip的网络资源,不影响用户的访问速度。
vm2的nginx配置文件如下
本文出自 “一方有” 博客,请务必保留此出处http://yifangyou.blog.51cto.com/900206/1047427
活动的特点是高并发,逻辑不是很复杂,因此我采用DNS做负载均衡器+nginx做前端+php开发+redis数据库的分布式结构。
使用DNS负载均衡的原因是,我没有更多的钱买负载均衡,其次负载均衡至少得双机主备,再次DNS负载均衡不用部署配置,比lvs简单多了。
为了解决跨域的session问题,我使用了一个redis数据库来存储session的id,这样我的php程序得改成不读取本地session,而去读取redis中的session数据。可以实现跨域的session,不用担心分布式带来的session问题。
同时redis可以用作存储用户数据,例如微博id,生成图片路径等等信息,并发性要比mysql高得多。
为了解决redis单点故障,我添加了一个从redis数据库实时和主redis数据库进行同步,若是主数据库挂了,可以用从数据库来顶替
但是这个网站每台机器上都会生成各自的图片,而这些图片需要在网站上显示,这样的话存在一个问题:
某个用户是通过DNS只能请求到一台机器上(VM3)上,那么在网站上出现的VM2,VM4,VM5的图片就无法显示了。
我冥思苦想,想到了一个好办法:就是利用nginx的proxy模块来实现:
1)VM2上由程序生成的每一张的图片都存在目录(10.200.225.158--VM2的内网ip)下,VM3上由程序生成的每一张的图片都存在目录(10.200.226.56)下...
2) 这样VM2下的图片路径就是http://www.a.com/10.200.225.158/xxx.jpg,VM3下的图片就是http://www.a.com/10.200.226.56/xxx.jpg
3)我VM2上的nginx上配置使得:
3.1)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.225.158/xxx.jpg时就直接读取本地图片
3.2)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.226.56/xxx.jpg时就通过VM2代理读取远程的VM3上的图片
3.3)当用户被DNS解析到VM2上时,若URL是http://www.a.com/10.200.55.39/xxx.jpg时就通过VM2代理读取远程的VM4上的图片
3.4)当用户被DNS解析到VM2上时,若URL是http://www.a.com/110.200.51.143/xxx.jpg时就通过VM2代理读取远程的VM5上的图
也就是说当www.a.com解析到vm2,若是要显示vm3上生成的图片的话,得通过vm2的代理去获取,由于我设置的代理的ip都是内网的,因此不占用外网ip的网络资源,不影响用户的访问速度。
vm2的nginx配置文件如下
location /10.200.226.56 { root /opt/tmp/; proxy_redirect off ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 50m; client_body_buffer_size 256k; proxy_connect_timeout 30; proxy_send_timeout 30; proxy_read_timeout 60; proxy_buffer_size 256k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; proxy_max_temp_file_size 128m; proxy_pass http://10.200.226.56:80; } location /10.200.55.39 { root /opt/tmp/; proxy_redirect off ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 50m; client_body_buffer_size 256k; proxy_connect_timeout 30; proxy_send_timeout 30; proxy_read_timeout 60; proxy_buffer_size 256k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; proxy_max_temp_file_size 128m; proxy_pass http://10.200.55.39:80; } location /10.200.51.143 { root /opt/tmp/; proxy_redirect off ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 50m; client_body_buffer_size 256k; proxy_connect_timeout 30; proxy_send_timeout 30; proxy_read_timeout 60; proxy_buffer_size 256k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_next_upstream error timeout invalid_header http_500 http_503 http_404; proxy_max_temp_file_size 128m; proxy_pass http://10.200.51.143:80; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name; include fastcgi_params; }
本文出自 “一方有” 博客,请务必保留此出处http://yifangyou.blog.51cto.com/900206/1047427
相关文章推荐
- 高可用网站多点部署架构实战经验总结
- 实战开发经验: 软件系统设计思路
- 支付系统高可用架构设计实战
- 构建Oracle高可用环境HA rac:企业级高可用数据库架构、实战与经验总结
- 可用性高达五个9!支付系统高可用架构设计实战
- 网站DDOS攻击防护实战老男孩经验心得分享
- 设计高可用和高负载的网站系统(转载)
- 可扩展、高可用、负载均衡网站架构设计方案
- 互联网运营智慧——高可用可扩展网站技术实战
- 项目实战之中小网站数据缓存的设计与实现
- 个人网站实战经验总结
- 网站设计经验心得
- 设计高可用和高负载的网站系统的几个注意事项
- 网站性能提高实战经验点滴记录
- IBM经验总结:网站设计中不可忽视的可用性原则
- 滴滴passport设计之道:帐号体系高可用的7条经验
- 数据库实战经验之浅谈数据库的设计技巧【转载】
- 设计高可用和高负载的网站系统
- 可扩展、高可用、负载均衡网站架构设计方案
- 设计高可用和高负载的网站系统