注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

itoedr的it学苑

记录从IT文盲学到专家的历程

 
 
 

日志

 
 

tengine发布新版本,支持新的hash算法(nginx得到补充)  

2013-05-10 04:40:34|  分类: nginx编程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

一.consistent_hash:tengine的调度一致性模块

  • 一致性hash模块
描述
  • 这个模块提供一致性hash作为负载均衡算法。

  • 该模块通过使用客户端信息(如:$ip, $uri, $args等变量)作为参数,使用一致性hash算法将客户端映射到后端机器

  • 如果后端机器宕机,这请求会被迁移到其他机器

  • server id 字段,如果配置id字段,则使用id字段作为server标识,否则使用server ip和端口作为server标识,

    使用id字段可以手动设置server的标识,比如一台机器的ip或者端口变化,id仍然可以表示这台机器。使用id字段

    可以减低增减服务器时hash的波动。

  • server wegiht 字段,作为server权重,对应虚拟节点数目

  • 具体算法,将每个server虚拟成n个节点,均匀分布到hash环上,每次请求,根据配置的参数计算出一个hash值,在hash环

    上查找离这个hash最近的虚拟节点,对应的server作为该次请求的后端机器。

  • 该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器,比如:

consistent_hash $remote_addr:可以根据客户端ip映射

consistent_hash $request_uri: 根据客户端请求的uri映射

consistent_hash $args:根据客户端携带的参数进行映射


**************************
::例子之一::
**************************
worker_processes  1;
http {
    upstream test {
        consistent_hash $request_uri;

        server 127.0.0.1:9001 id=1001 wegiht=3;
        server 127.0.0.1:9002 id=1002 wegiht=10;
        server 127.0.0.1:9003 id=1003 wegiht=20;
    }
}

指令
Syntax: consistent_hash variable_name

Default: none

Context: upstream

配置upstream采用一致性hash作为负载均衡算法,并使用配置的变量名作为hash输入。

**********************************************
例子之二:使用ip地址作为负载标志
***********************************************
upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}
表示使用ip来区分负载的一致性(即同一ip均定向到同一个真实服务器);


二.基于会话一致性的nginx负载均衡调度方法


会话保持ngx_http_upstream_session_sticky_module

::利用此模块实现依据会话来调度upstream的负载均衡

         该模块是一个负载均衡模块,通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。(这对于一些多回合认证的应用成为重要)


××××案例 1××××


# 默认配置:cookie=route mode=insert fallback=on
upstream foo {
   server 192.168.0.1;
   server 192.168.0.2;
   session_sticky;
}

server {
    location / {
        proxy_pass http://foo;
    }
}

××××案例 2××××

#insert + indirect模式:
upstream test {
  session_sticky cookie=uid domain=www.xxx.com fallback=on path=/ mode=insert option=indirect;
  server  127.0.0.1:8080;
}

server {
  location / {
    #在insert + indirect模式或者prefix模式下需要配置session_sticky_hide_cookie
    #这种模式不会将保持会话使用的cookie传给后端服务,让保持会话的cookie对后端透明
    session_sticky_hide_cookie upstream=test;
    proxy_pass http://test;
  }
}

指令


语法:session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time] [mode=insert|rewrite|prefix] [option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]

默认值:session_sticky cookie=route mode=insert fallback=on

上下文:upstream

说明:

本指令可以打开会话保持的功能,下面是具体的参数:


cookie设置用来记录会话的cookie名称

domain设置cookie作用的域名,默认不设置

path设置cookie作用的URL路径,默认不设置

maxage设置cookie的生存期,默认不设置,即为session cookie,浏览器关闭即失效

mode设置cookie的模式:

insert: 在回复中本模块通过Set-Cookie头直接插入相应名称的cookie。

prefix: 不会生成新的cookie,但会在响应的cookie值前面加上特定的前缀,当浏览器带着这个有特定标识的cookie再次请求时,模块在传给后端服务前 先删除加入的前缀,后端服务拿到的还是原来的cookie值,这些动作对后端透明。如:"Cookie: NAME=SRV~VALUE"。


rewrite: 使用服务端标识覆盖后端设置的用于session sticky的cookie。如果后端服务在响应头中没有设置该cookie,则认为该请求不需要进行session sticky,使用这种模式,后端服务可以控制哪些请求需要sesstion sticky,哪些请求不需要。

         option 设置用于session sticky的cookie的选项,可设置成indirect或direct。indirect不会将session sticky的cookie传送给后端服务,该cookie对后端应用完全透明。direct则与indirect相反。

maxidle设置session cookie的最长空闲的超时时间

maxlife设置session cookie的最长生存期

fallback设置是否重试其他机器,当sticky的后端机器挂了以后,是否需要尝试其他机器

hash 设置cookie中server标识是用明文还是使用md5值,默认使用md5

语法: session_sticky_hide_cookie upstream=name;

默认值: none

上下文: server, location

说明:

配合proxy_pass指令使用。用于在insert+indirect模式和prefix模式下删除请求用于session sticky的cookie,这样就不会将该cookie传递给后端服务。upstream表示需要进行操作的upstream名称。


更多内容见>>>tengine.taobao.org

******************************
附:cookie
******************************
       Cookie是由服务器端生成,发送给User-Agent(一般是浏览器),浏览器会将Cookie的key/value保存到某个目录下的文本文件内,下次请求同一网站时就发送该Cookie给服务器(前提是浏览器设置为启用cookie)。Cookie名称和值可以由服务器端开发自己定义,对于JSP而言也可以直接写入jsessionid,这样服务器可以知道该用户是否合法用户以及是否需要重新登录等,服务器可以设置或读取Cookies中包含信息,借此维护用户跟服务器会话中的状态。服务器可以利用Cookies包含信息的任意性来筛选并经常性维护这些信息,以判断在HTTP传输中的状态。Cookies最典型的应用是判定注册用户是否已经登录网站,用户可能会得到提示,是否在下一次进入此网站时保留用户信息以便简化登录手续,这些都是Cookies的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品,这些信息都会写入Cookies,以便在最后付款时提取信息。
           关于document .cookie::   document 为一个超类 .cookie 为他的方法 (函数),Cookie是一种能够让网站服务器把少量数据储存到客户端的硬盘或内存,或是从客户端的硬盘读取数据的一种技术。Cookies是当你浏览某网站时,由Web服务器置于你硬盘上的一个非常小的文本文件,它可以记录你的用户ID、密码、浏览过的网页、停留的时间等信息。
         encodeURIComponent():encodeURIComponent() 来编码不同的 URI.
        
         encodeURI()和decodeURIComponent()函数,这两个函数可以对特定函数生成的密码字符串进行解密操作,就可以生成为未解密的字符串,比较实用.
decodeURI()定义和用法:decodeURI() 函数可对 encodeURI() 函数编码过的URI 进行解码。
       语法:decodeURI(URIstring)
       参数 描述:URIstring 必需。一个字符串,含有要解码的 URI 或其他要解码的文本。
       返回值:URIstring 的副本,其中的十六进制转义序列将被它们表示的字符替换。

        decodeURIComponent()定义和用法:decodeURIComponent() 函数可对 encodeURIComponent() 函数编码的 URI 进行解码。
        语法:decodeURIComponent(URIstring)
        参数 描述:URIstring 必需。一个字符串,含有编码 URI 组件或其他要解码的文本。
         返回值:URIstring 的副本,其中的十六进制转义序列将被它们表示的字符替换。
  评论这张
 
阅读(1509)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017