如何构建日均千万PV Web站点(二) 之~缓存为王~

随着网站业务的不断发展,用户的规模越来越大;介于中国无比蹩脚复杂的网路环境;南电信;北联通;中间竟然只用一条链路进行互联通信!有研究表明,网站访问延迟和用户流失率正相关,网站访问速度越慢,用户越容易失去耐心而离开。为了提高更好的用户体验,留住用户,网站需要加速网站访问速度。如今主要的手段只有使用CDN和反向代理了;此时网站的架构应该是这样的:

  1、使用CDN和缓存服务器;CDN和反向代理的基本原理都是缓存数据,区别就在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;CDN的网络环境很复杂;所谓的多重负载均衡架构模型;不过它们一般会使用DNS作为全局负载均衡器;高效,并且能够根据客户端的源IP地址,来判断客户端的来源地区;将客户端的请求分配制本地负载均衡器;CDN架构图如下:从下图中可以看到,第一层GSLB和第二层GSLB都有各自的域组,第一层GSLB通过区域设置,将整个服务池分为电信的服务池和联通的服务池,第二层GSLB通过区域设置,将电信的服务池分为各省的服务池。这里的服务池就是提供相同业务的所有POP节点的组合,各省的服务池包含两个POP节点,POP节点也是GSLB在调度配置中所认识到的虚拟服务器.GSLB通过负载均很策略最终返回一个POP节点地址,用户直接访问POP节点来获取网站缓存内容。

 

而反向代理则部署在网站的中心机房中,当用户请求到达中心机房中后,首先访问的服务器就是反向代理服务器,如果反向代理服务器ui中缓存着用户请求的资源,就将其直接返回给用户。使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户的访问速度,另一方面也减轻了后端服务器的负载压力;

  2、分布式数据库;分布式数据库是网站数据拆分的最后手段,只有在表单数据规模非常庞大的时候才使用;

  3、服务器推送;将应用程序服务器;以及缓存服务器全部推送到运营商机房中;

  4、NoSQL以及搜索引擎的引入;随着网站的业务越来越复杂,对数据的存储和检索需求也越来越复杂,这时网站就必须得引入一些非关系型数据库技术如NoSQL(MongoDB,对于大数据量、髙并发、弱事务的互联网应用, MongoDB则是一个如瑞士军刀般的利器。尽管我不认同MongoDB会在所有场合完全取代MySQL,但我相信它完全可以满足Web 2.0和移动互联网应用的数据存储需求。MongoDB内置的水平扩展机制提供了从百万到十亿级别的数据量处理能力,其开箱即用的特性也大大降低了中小网站的运维成本),以及非数据库查询技术如搜索引擎;NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持。因此,此时的架构模型就如下图所示: 喜欢的话就点个赞呗; 

Nginx 反向代理配置:

user                              nobody nobody;
worker_processes                  4;
worker_rlimit_nofile              51200;

error_log                         logs/error.log  notice;

pid                               /var/run/nginx.pid;

events {
  use                             epoll;
  worker_connections              51200;
}

http {
  server_tokens                   off;
  include                         mime.types;

  proxy_redirect                off;
  proxy_set_header              Host $host;
  proxy_set_header              X-Real-IP $remote_addr;
  proxy_set_header              X-Forwarded-For $proxy_add_x_forwarded_for;
  client_max_body_size          20m;
  client_body_buffer_size       256k;
  proxy_connect_timeout         90;
  proxy_send_timeout            90;
  proxy_read_timeout            90;
  proxy_buffer_size             128k;
  proxy_buffers                 4 64k;
  proxy_busy_buffers_size       128k;
  proxy_temp_file_write_size    128k;

  default_type                    application/octet-stream;
  charset                         utf-8;
  
  client_body_temp_path           /var/tmp/client_body_temp 1 2;
  proxy_temp_path                 /var/tmp/proxy_temp 1 2;
  fastcgi_temp_path               /var/tmp/fastcgi_temp 1 2;
  uwsgi_temp_path                 /var/tmp/uwsgi_temp 1 2;
  scgi_temp_path                  /var/tmp/scgi_temp 1 2;

  ignore_invalid_headers          on;
  server_names_hash_max_size      256;
  server_names_hash_bucket_size   64;
  client_header_buffer_size       8k;
  large_client_header_buffers     4 32k;
  connection_pool_size            256;
  request_pool_size               64k;

  output_buffers                  2 128k;
  postpone_output                 1460;

  client_header_timeout           1m;
  client_body_timeout             3m;
  send_timeout                    3m;


  log_format main                 ‘$server_addr $remote_addr [$time_local] $msec+$connection ‘
                                  ‘"$request" $status $connection $request_time $body_bytes_sent "$http_referer" ‘
                                  ‘"$http_user_agent" "$http_x_forwarded_for"‘;

  open_log_file_cache               max=1000 inactive=20s min_uses=1 valid=1m;

  access_log                      logs/access.log      main;
  log_not_found                   on;


  sendfile                        on;
  tcp_nodelay                     on;
  tcp_nopush                      off;

  reset_timedout_connection       on;
  keepalive_timeout               10 5;
  keepalive_requests              100;


  gzip                            on;
  gzip_http_version               1.1;
  gzip_vary                       on;
  gzip_proxied                    any;
  gzip_min_length                 1024;
  gzip_comp_level                 6;
  gzip_buffers                    16 8k;
  gzip_proxied                    expired no-cache no-store private auth no_last_modified no_etag;
  gzip_types                      text/plain application/x-javascript text/css application/xml application/json;
  gzip_disable                    "MSIE [1-6]\.(?!.*SV1)";


  upstream varnish  81 {
    least_conn
  
    server                        172.16.100.103:81 weight=1 max_fails=2;
    server                        172.16.100.104:81 weight=1 max_fails=2;
    server                        172.16.100.105:81 weight=1 max_fails=2;
   } server { listen 80; server_name www.firefox.com; # config_apps_begin root /data/webapps/htdocs; access_log /var/logs/webapp.access.log main; error_log /var/logs/webapp.error.log notice; location / { location ~* ^.*/favicon.ico$ { root /data/webapps; expires 180d; break; } if ( !-f $request_filename ) { proxy_pass http://varnish 81; break; } } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } server { listen 8088; server_name nginx_status; location / { access_log off; deny all; return 503; } location /status { stub_status on; access_log off; allow 127.0.0.1; allow 172.16.100.71; deny all; } } }
转自:http://www.cnblogs.com/xiaocen/p/3726763.html

如何构建日均千万PV Web站点(二) 之~缓存为王~,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。