nginx哈希源码(nginx 哈希)

nginx 哈希

nginx负载均衡cookie携带就是ginx-sticky-module 是 Nginx 的一个扩展模块，实现了通过 Cookie 的会话粘贴效果。

Nginx以前对session 保持支持不太好，主要采用ip_hash把同一来源的客户(同一C段的IP)固定指向后端的同一台机器，ip_hash有个缺点是不能实现很好的负载均衡；直到nginx的扩展模块nginx-sticky-module的出现，解决了session sticky的问题。 

基本的原理： 

首先根据轮询RR随机到某台后端，然后在响应的Set-Cookie上加上route=md5(upstream)字段，第二次请求再处理的时候，发现有route字段，直接导向原来的那个节点。

nginx hash cookie

区别：

1、数据存放位置不同：

cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、安全程度不同：

cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。

3、性能使用程度不同：

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

4、数据存储大小不同：

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。

5、会话机制不同

session会话机制：session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。

cookies会话机制：cookie是服务器存储在本地计算机上的小块文本，并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动将来自同一服务器的任何请求绑定到这些cookie。

nginx hash ip

获取url参数

在 ngx_lua 中访问 Nginx 内置变量 ngx.var.arg_PARAMETER 即可获得GET参数PARAMETER的内容。

在 nginx配置中，通过$arg_PARAMETER 即可获得GET参数PARAMETER的内容。

获取请求头

在 ngx_lua 中访问 Nginx 内置变量 ngx.var.http_HEADER 即可获得请求头HEADER的内容。

在 nginx配置中，通过$http_HEADER 即可获得请求头HEADER的内容。

通过以下方式进行验证，比如说，通过 http://www.test.com?name=hello&id=123 来验证url的请求参数，能够在nginx中获取到，只需要修改nginx.conf 配置文件如下,就可以在access.log中看到id和name在log中

http {

include mime.types;

default_type application/octet-stream;

log_format main '{ "@timestamp": "$time_iso8601", '

'"servername": "$http_host", '

'"id": "$arg_id",'

'"name": "$arg_name",'

'"remote_addr": "$remote_addr",'

'"referer": "$http_referer",'

'"request": "$request",'

'"request_time": "$request_time",'

'"status": $status,'

'"bytes":$body_bytes_sent,'

'"agent": "$http_user_agent",'

'"x_forwarded": "$http_x_forwarded_for",'

'"upstr_addr": "$upstream_addr",'

'"upstr_host": "$upstream_http_host",'

'"ups_resp_time": "$upstream_response_time" }';

access_log logs/access.log main;

server_names_hash_bucket_size 128;

nginx hash 负载均衡

集群，负载均衡和分布式，虽然是不同的概念，但是彼此之间又有联系。

01. 集群

集群是指有多台服务器，它们做着相同的事情，提供相同的服务区，在调用方看来只有一个服务器对外提供服务，这些服务器组合起来就叫做集群。

我们以代码为例：

最早的时候，我们的业务都写在一个项目中，比如我们做一个网上商城的项目，客户注册、商品浏览及下单、支付、物流全部都在同一个项目中。

但是随着用户的不断增多，一台服务器已经不能满足这么大访问量的时候，我们可以将这个项目部署在多台服务器上，这样就可以让跟多的用户访问我们的网站。

虽然这样看起来，我们网站的负载能力更强了，可以让更多的用户访问我们的网站，但是有另外一个问题，就是网站（服务）的入口会有多个，你不可能要求用户能记住你所有服务器的 IP，也不可能申请多个域名挂在不同的服务器上，这时候就需要用到负载均衡了。

02. 负载均衡

负载均衡可以把用户的请求分发到后端的服务器上，就像这样：

这样就变成了统一的入口，然后再做二次分发，将流量按照一定的规则发送到后端的每台服务器上，这个过程就是负载均衡。

负载均衡有硬件的实现方式，比如 F5，这是一台硬件设备，也有软件的实现方式，比如 Nginx、LVS 等等；

负载均衡策略也有很多，比如轮询法、随机法、随机轮询法、源地址哈希法、最小连接数法、最快响应速度法等等；

另外，在微服务架构中，还有一个概念是“客户端负载均衡”，也就是客户端保存着每台服务器的地址，由客户端自己决定去访问哪台服务器。客户端的负载均衡，通常是要和服务注册发现配合使用的。

03. 分布式

如果所有的代码都写在同一个代码包中，随着需求的增多、业务越来越复杂，这个代码包可能会变得越来越大，越来越难维护；以前三五个开发人员就能维护一个项目，现在是三五百个开发人员一起合作开发；功能模块都在一起，一个功能要升级，整个项目就要跟着一起升级；当我们要做另外一个项目的时候，有一些功能就要重复开发...由于以上种种问题，需要我们将项目进行服务化，分布式部署。

集群是多台服务器，每台服务器干相同的事情，那么分布式就是多台机器，每台服务器做不同的事情，它们彼此配合完成工作。

当然不是说使用了分布式之后，就不需要负载均衡了，通常两者是配合使用的。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

nginx url_hash

以下三个功能基于nginx：

1）反向代理功能：Nginx在反向代理上，提供灵活的功能，可以根据不同的正则采用不同的转发策略

2）负载均衡功能：Nginx可使用的负载均衡策略有：轮询（默认）、权重、ip_hash、url_hash(第三方)、fair(第三方)。

3）动静分离功能：Nginx可以根据配置对不同的请求做不同转发，这是动态分离的基础。静态请求对应的静态资源可以直接放在Nginx上做缓冲，更好的做法是放在相应的缓冲服务器上。动态请求由相应的后端服务器处理。

hash nginx

Nginx负载均衡的原理是根据请求的负载大小及服务器的可用性，将客户端请求分发到多个服务器上进行处理，以提高资源利用率和系统的可用性。具体来说，Nginx作为反向代理服务器，通过配置upstream模块进行负载均衡，根据配置的算法（如轮询、权重、IP hash等）将请求分发到指定的服务器上。同时，Nginx还可以实现基于健康检查机制的动态负载均衡，通过定期检查服务器的可用性，将请求分发到可用的服务器上，提高系统的可用性。此外，Nginx还支持对HTTP请求进行流量控制和限速，以及基于HTTP协议的会话保持等功能，为高负载、高并发情况下的服务提供高效、稳定的解决方案。

nginx配置ip hash

第一种：Nginx自己的错误页面

Nginx访问一个静态的html 页面，当这个页面没有的时候，Nginx抛出404，那么如何返回给客户端404呢？

看下面的配置，这种情况下不需要修改任何参数，就能实现这个功能。

server {

listen 80;

server_name www.test.com;

root /var/www/test;

index index.html index.htm;

location / {

}

# 定义错误页面码，如果出现相应的错误页面码，转发到那里。

error_page 404 403 500 502 503 504 /404.html;

# 承接上面的location。

location = /404.html {

# 放错误页面的目录路径。

root /usr/share/nginx/html;

}

}

第二种：反向代理的错误页面

如果后台Tomcat处理报错抛出404，想把这个状态叫Nginx反馈给客户端或者重定向到某个连接，配置如下：

upstream www {

server 192.168.1.201:7777 weight=20 max_fails=2 fail_timeout=30s;

ip_hash;

}

server {

listen 80;

server_name www.test.com;

root /var/www/test;

index index.html index.htm;

location / {

if ($request_uri ~* ‘^/$’) {

rewrite .* http://www.test.com/index.html redirect;

}

# 关键参数：这个变量开启后，我们才能自定义错误页面，当后端返回404，nginx拦截错误定义错误页面

proxy_intercept_errors on;

proxy_pass http://www;

proxy_set_header HOST $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;

}

error_page 404 /404.html;

location = /404.html {

root /usr/share/nginx/html;

}

}

第三种：Nginx解析php代码的错误页面

如果后端是php解析的，需要加一个变量

在http段中加一个变量

fastcgi_intercept_errors on就可以了。

指定一个错误页面：

error_page 404 /404.html;

location = /404.html {

root /usr/share/nginx/html;

}

指定一个url地址：

error_page 404 /404.html;

error_page 404 = http://www.test.com/error.html;