子午随风

对你好，也许是一时兴起。
待你如初，才叫情有独钟。
一见钟情？说白了——不是第一眼就爱上，是第一眼之后，再也忘不掉。
缘分有时候很简单：一眼定生死。
有时候很复杂：一生皆是遗憾。
眼缘，说不清，道不明。
但就是那一眼，像刻在骨子里，万般皆是你，换谁都不行。

视频地址：mmexport1779825063105.mp4

原理

简介 使用upstream模块实现nginx负载均衡 _使用nginx_upstream_check_module模块实现后端服务器的健康检查_ 使用nginx-sticky-module扩展模块实现Cookie会话黏贴（session-sticky效果） _使用proxy模块实现静态文件缓存_ 使用ngx_cache_purge实现更强大的缓存清除功能

1. nginx-sticky-module

  这个模块的作用是通过cookie的方式将来自同一个客户端（浏览器）的请求发送到同一个后端服务器上处理，这样一定程度上可以解决多个backend servers的session同步的问题 —— 因为不再需要同步，而RR轮询模式必须要运维人员自己考虑session同步的实现。 另外内置的 ip_hash 也可以实现根据客户端IP来分发请求，但它很容易造成负载不均衡的情况，而如果nginx前面有CDN网络或者来自同一局域网的访问，它接收的客户端IP是一样的，容易造成负载不均衡现象。淘宝Tengine的 ngx_http_upstream_session_sticky_module 也是类似的功能。nginx-sticky-module的cookie过期时间，默认浏览器关闭就过期，也就是会话方式。 这个模块并不合适不支持 Cookie 或手动禁用了cookie的浏览器，此时默认sticky就会切换成RR。它不能与ip_hash同时使用。 原理其实很简单,当一个客户端请求过来时,会 set-cookie 一个 cookie 来标注本次请求的服务器(第一次是随机).然后下次请求都会包含这个 cookie .然后就能很好的区分原本请求的服务器了.我测试过,当默认请求的后端服务器死掉后,会还是会自动切换的.另外,这个模块并不合适对不支持 Cookie 的浏览器

Sticky module is based on a "best effort" algorithm. Its aim is not to handle security somehow. It's been made to ensure that normal users are always redirected to the same backend server: that's all!

sticky安装

bash
./configure ... --add-module=/absolute/path/to/nginx-sticky-module-ng
make
make install

sticky配置

upstream {
  sticky;
  server 127.0.0.1:9000;
  server 127.0.0.1:9001;
  server 127.0.0.1:9002;
}

sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h]
       [hash=index|md5|sha1] [no_fallback] [secure] [httponly];

• name: the name of the cookies used to track the persistant upstream srv; default: route
• domain: the domain in which the cookie will be valid default: nothing. Let the browser handle this.
• path: the path in which the cookie will be valid default: /
• expires: the validity duration of the cookie default: nothing. It's a session cookie. restriction: must be a duration greater than one second

• hash: the hash mechanism to encode upstream server. It cant' be used with hmac. default: md5hmac: the HMAC hash mechanism to encode upstream server It's like the hash mechanism but it uses hmac_key to secure the hashing. It can't be used with hash. md5|sha1: well known hash default: none. see hash.

  • md5|sha1: well known hash
  • index: it's not hashed, an in-memory index is used instead, it's quicker and the overhead is shorter Warning: the matching against upstream servers list is inconsistent. So, at reload, if upstreams servers has changed, index values are not guaranted to correspond to the same server as before! USE IT WITH CAUTION and only if you need to!
• hmac_key: the key to use with hmac. It's mandatory when hmac is set default: nothing.
• no_fallback: when this flag is set, nginx will return a 502 (Bad Gateway or Proxy Error) if a request comes with a cookie and the corresponding backend is unavailable.
• secure enable secure cookies; transferred only via https
• httponly enable cookies not to be leaked via js

官方文档也有个 sticky 指令，作用几乎是一样的，但这是nginx商业版本里才有的特性。包括后面的check指令，在nginx的商业版本里也有对应的health_check（配在 location ）实现几乎一样的监控检查功能。

2、nginx负载均衡

• 轮询（默认） ： 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，故障系统被自动剔除，使用户访问不受影响。Weight 指定轮询权值，Weight值越大，分配到的访问机率越高，主要用于后端每个服务器性能不均的情况下。
• ip_hash ： 每个请求按访问IP的hash结果分配，这样来自同一个IP的访客固定访问一个后端服务器，有效解决了动态网页存在的session共享问题。当然如果这个节点不可用了，会发到下个节点，而此时没有session同步的话就注销掉了。
• least_conn ： 请求被发送到当前活跃连接最少的realserver上。会考虑weight的值。
• url_hash ： 此方法按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身是不支持url_hash的，如果需要使用这种调度算法，必须安装nginx 的hash软件包 nginx_upstream_hash 。
• fair ： 这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair的，如果需要使用这种调度算法，必须下载Nginx的 upstream_fair 模块。

ip_hash的配置

upstream backend {
    ip_hash;
    server 192.168.1.225:8080 weight 2;
    server 192.168.1.226:8080 weight=1 max_fails=2 fail_timeout=30s;
    server 192.168.1.227:8080 backup;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    }
}

• weight：轮询权值也是可以用在ip_hash的，默认值为1
• max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
• fail_timeout：有两层含义，一是在 30s 时间内最多容许 2 次失败；二是在经历了 2 次失败以后，30s时间内不分配请求到这台服务器。
• backup：备份机器。当其他所有的非backup机器出现故障的时候，才会请求backup机器
• max_conns： 限制同时连接到某台后端服务器的连接数，默认为0即无限制。因为queue指令是commercial，所以还是保持默认吧。
• proxy_next_upstream：这个指令属于 http_proxy 模块的，指定后端返回什么样的异常响应时，使用另一个realserver

项目地址： https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng https://code.google.com/p/nginx-sticky-module/

3、 upstream_check

nginx自带是没有针对负载均衡后端节点的健康检查的，但是可以通过默认自带的 ngx_http_proxy_module 模块和 ngx_http_upstream_module 模块中的相关指令来完成当后端节点出现故障时，自动切换到下一个节点来提供访问。 nginx_upstream_check_module 是专门提供负载均衡器内节点的健康检查的外部模块，由淘宝工程师开发，通过它可以用来检测后端 realserver 的健康状态。如果后端 realserver 不可用，则后面的请求就不会转发到该节点上，并持续检查几点的状态。在淘宝自己的 tengine 上是自带了该模块。

upstream backend {
    sticky;
    server 192.168.1.225:8080 weight=2;
    server 192.168.1.226:8081 weight=1 max_fails=2 fail_timeout=30s;
    server 192.168.1.227:8080 weight=1 max_fails=2 fail_timeout=30s;
    server 192.168.1.227:8081;

    check interval=5000 rise=2 fall=3 timeout=1000 type=http;
    check_http_send "HEAD / HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

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

    location /status {
        check_status;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}

nginx_upstream_check_module 对name这个负载均衡条目中的所有节点，每个5秒检测一次，请求2次正常则标记 realserver状态为up，如果检测 3 次都失败，则标记 realserver的状态为down，超时时间为1秒。check指令只能出现在upstream中：

• interval ： 向后端发送的健康检查包的间隔。
• fall ： 如果连续失败次数达到fall_count，服务器就被认为是down。
• rise ： 如果连续成功次数达到rise_count，服务器就被认为是up。
• timeout ： 后端健康请求的超时时间。
• default_down ： 设定初始时服务器的状态，也就是一开始服务器认为是不可用，要等健康检查包达到一定成功次数以后才会被认为是健康的。

• type：健康检查包的类型，现在支持以下多种类型

  • tcp：简单的tcp连接，如果连接成功，就说明后端正常。
  • http：发送HTTP请求，通过后端的回复包的状态来判断后端是否存活。
  • ajp：向后端发送AJP协议的Cping包，通过接收Cpong包来判断后端是否存活。
  • ssl_hello：发送一个初始的SSL hello包并接受服务器的SSL hello包。
  • mysql: 向mysql服务器连接，通过接收服务器的greeting包来判断后端是否存活。
  • fastcgi：发送一个fastcgi请求，通过接受解析fastcgi响应来判断后端是否存活
• port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口，比如后端提供的是443端口的应用，你可以去检查80端口的状态来判断后端健康状况。默认是0，表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。

如果 type 为 http ，你还可以使用check_http_send来配置http监控检查包发送的请求内容，为了减少传输数据量，推荐采用 HEAD 方法。当采用长连接进行健康检查时，需在该指令中添加keep-alive请求头，如： HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n 。当采用 GET 方法的情况下，请求uri的size不宜过大，确保可以在1个interval内传输完成，否则会被健康检查模块视为后端服务器或网络异常。 check_http_expect_alive 指定HTTP回复的成功状态，默认认为 2XX 和 3XX 的状态是健康的。 项目地址：https://github.com/yaoweibin/nginx\_upstream\_check\_module 。

4、 proxy缓存的使用

缓存配置如下

http {
    proxy_temp_path /usr/local/nginx/proxy_temp;

    proxy_cache_path /usr/local/nginx/proxy_cache 
        levels=1:2 
        keys_zone=cache_one:100m 
        inactive=2d 
        max_size=2g;

    server {
        location ~ .*\.(gif|jpg|png|html|css|js|ico|swf|pdf)$ {
            proxy_pass http://backend;

            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;

            proxy_cache cache_one;
            add_header Nginx-Cache $upstream_cache_status;

            proxy_cache_valid 200 304 301 302 8h;
            proxy_cache_valid 404 1m;
            proxy_cache_valid any 2d;

            proxy_cache_key $host$uri$is_args$args;

            expires 30d;
        }
    }
}

清除缓存

上述配置的proxy_cache_purge指令用于方便的清除缓存，需要ngx_cache_purge 模块

location ~ /purge(/.*) {
    allow 127.0.0.1;
    allow 192.168.1.0/24;
    deny all;

    proxy_cache_purge cache_one $host$1$is_args$args;
    error_page 405 =200 /purge$1;
}

echo -e 'PURGE / HTTP/1.0\r\n' | nc example.com
echo -e 'GET /purge/ HTTP/1.0\r\n' | nc example.com

项目地址
nginx-sticky-module
https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng
https://code.google.com/p/nginx-sticky-module/
nginx_upstream_check_module
https://github.com/yaoweibin/nginx_upstream_check_module
ngx_cache_purge
https://github.com/FRiCKLE/ngx_cache_purge/

越长大，越难和另一个人在一起。

不是因为条件。还是有人喜欢你，你也活得比以前更好，不再那么任性，更像在投资的艺术品。

也不是因为对爱情死心。在KTV突然听到的某首歌，会让你不自禁模糊了视线。一些场景，一些气息，始终无法忘怀。朋友帮你介绍时，你也会满心期待。

却依然单身。闭上眼睛吹蜡烛的时候，总是希望身边有另一个人一起许愿。一些客气的场合，有人来搭讪，话题围绕着你单身的原因。而他们最后给出的结论是，你太挑了。你在心里面笑，所以其他人都不挑？

其实你自己知道，为什么不能好好谈一场恋爱。就是因为，你太清楚自己是怎样的一块料，所以不会再轻而易举把自己交出去。就像是，有一天你发现跌倒以后的伤口，会开始留下疤痕，于是走路时不敢再大步跨出去。

因为，你惯性太强、记性太好。认识一个人很简单，忘记一个人很困难。你曾经心满意足的闭上眼睛，让另一个人带你去任何地方，最后却差点回不来。所以不能再失去方向感。

于是你就变得胆小了。以前打电话找不到人就拼命的打，现在发了短信没回应，即使心中有波动也可以忍住。以前最有兴趣的话题是对方的过去，现在会先关心这份感情有没有未来。
所以，空暇的时候，你宁愿和朋友在烈日下逛街，也不愿让对方觉得自己很在乎什么。你安慰自己，有朋友就够了，一个人生活也很好。如果有一天当那个人出现时，你反而会开始慌张、害怕。

只是，你并不是一定要单身，就像你也没计划过一定用哪只手写字。不过是，既然如此了那就这样吧。你想要有人一起旅行，一起看电影。你想和那个人说自己准备好了，只是没有勇气，请对方多一点耐心。你想说不再需要太多惊喜，在心里等的是一份相守以望的感情，抬起头来相视而笑，安心的生活，如此而已。

所有人都认为你过的很好

你爱开玩笑 也爱大声笑

有不少的朋友

别人都猜测你有数不清的暧昧关系

可是只有你明白一个人自己在家开着灯整夜失眠

看着天越来越亮才慢慢睡着是什么感觉

你不说话 房间里就一点声音都没有

2015年11月20日 燕京初冬，悄然落雪。倚门抬头，静寂的天空尽显苍茫，它无力挥洒着纯洁的雪白，不知那时神仙的泪花？还是对世间不平事的申诉。

不离家不知相思苦，不体验不知生活苦.

离家一载,回家两次,还是不能泯灭对家的思念，对乡土的一种念头.

在家乡的土地上有一种莫名的踏实。

不了解别人怎么想，自由并不能代替想家。

    按照惯例,每年生日都会有一篇属于自己的文章,懵懂,爱情.已经在过去的文章中写过了,慢慢就要步入社会了,漂泊的一年,学习的一年,一个新的环境,一段新的精力,让我深深的理解高中时的老生常谈的话题--感恩.学会感恩生活,也就是学会感激在生活中面对的林林总总,感激一切令自己成长的人.

    面对别人浅浅的微笑,那就感激对方的那份真诚的善意,在这善意里让快乐渲染自己,沉浸自己,鼓励自己,也美好自己.

    面对别人特别是来自朋友给你深深的伤害,不要恨,不要怨,不要痛,不要伤,此时的你应该感激他们给了你意志的磨练,令你在痛苦中坚强起来,微笑着给他们一份真诚的祝福吧.

    面对来自别人的责怪,不论任何情况下的你应该感激他们给了你一个反省的机会,重新认识自己,提高自己.

    面对来自别人的帮助,一个援手甚至会纠正自己在路程上的所有岔路,让自己享受成功,享受来自明面的所有荣誉.感恩所有在幕后帮助自己的人,在别人需要帮助的时候也要竭尽自己的左右努力去搭把手,锦上添花不如雪中送炭.朋友多,以后的路途也会更加顺利.

    面对在人生这风雨上绊倒了你的人,不要去责怪绊倒你的人,此时的你应该感激他们给了你一个提示,你的这个站立不稳,是因为你需强化双腿的训练.

　　面对一份欺骗,不要愤怒,不要痛恨,更不要不相信世上没有真诚,此时的你应该感激他们增强了你的智慧,令你在今后的岁月里减少伤痛,同时也增强了对自己付出真诚和自豪,不是吗?

　　面对蔑视你的人,那么就感激他们让你觉醒,让你觉醒了自尊,也让你真正的面对自己,面对自己所有的一切,找回一个真正的自己.

　　面对遗弃你的人,那么就感激给了你享受孤寂,品味孤寂,玩味孤寂的同时也教会了你独立.

 　笑过,哭过,痛过,伤过,体验过,感受过。珍惜生活中所有的历程,不管它代表的是快乐还是泪水,我们都应该带着一颗感恩的心面对,去珍惜,乐观的生活下去,为爱过的伤过的人们.

十九岁,一年又一年,一年比一年成熟.最后,感谢生活学习中的同学,感谢网络中认识我的所有朋友,感谢你们带给了我生活,带给我全部.

本文使用Blog_Backup未注册版本导出，请到soft.pt42.com注册。