weixin_43867038的博客

更新/重装Windows操作系统之后，Sticky Note便笺无法同步的问题

CentOS的DevTool包，用于升级GCC10

借助淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态，如果后端服务器不可用，则会将其踢出upstream，所有的请求不转发到这台服务器。当期恢复正常时，将其加入upstream。 nginx_upstream_check_module健康检查的时间间隔是毫秒级，而且可以自定义监控url，定制监控页，响应速度快，比原生的敏感度要高。 Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port] Default: 如果没有配置参数，默认值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp Context: upstream 该指令可以打开后端服务器的健康检查功能。指令后面的参数意义是： interval：向后端发送的健康检查包的间隔,单位为毫秒。 fall(fall_count): 如果连续失败次数达到fall_count，服务器就被认为是down。 rise(rise_count): 如果连续成功次数达到rise_count，服务器就被认为是up。 timeout: 后端健康请求的超时时间，单位毫秒。 default_down: 设定初始时服务器的状态，如果是true，就说明默认是down的，如果是false，就是up的。默认值是true，也就是一开始服务器认为是不可用，要等健康检查包达到一定成功次数以后才会被认为是健康的。 type：健康检查包的类型，现在支持以下多种类型： tcp：简单的tcp连接，如果连接成功，就说明后端正常。 ssl_hello：发送一个初始的SSL hello包并接受服务器的SSL hello包。 http：发送HTTP请求，通过后端的回复包的状态来判断后端是否存活。 mysql: 向mysql服务器连接，通过接收服务器的greeting包来判断后端是否存活。 ajp：向后端发送AJP协议的Cping包，通过接收Cpong包来判断后端是否存活。 port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口，比如后端提供的是443端口的应用，你可以去检查80端口的状态来判断后端健康状况。默认是0，表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。 Syntax: check_keepalive_requests request_num Default: 1 Context: upstream 该指令可以配置一个连接发送的请求数，其默认值为1，表示Tengine完成1次请求后即关闭连接。 Syntax: check_http_send http_packet Default: "GET / HTTP/1.0\r\n\r\n" Context: upstream 该指令可以配置http健康检查包发送的请求内容。为了减少传输数据量，推荐采用"HEAD"方法。 当采用长连接进行健康检查时，需在该指令中添加keep-alive请求头，如："HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n"。 同时，在采用"GET"方法的情况下，请求uri的size不宜过大，确保可以在1个interval内传输完成，否则会被健康检查模块视为后端服务器或网络异常。 Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ] Default: http_2xx | http_3xx Context: upstream 该指令指定HTTP回复的成功状态，默认认为2XX和3XX的状态是健康的。 效果： 访问：https://*****/nstatus

Sticky是nginx的一个模块，它是基于cookie的一种nginx的负载均衡解决方案，通过分发和识别cookie，来使同一个客户端的请求落在同一台服务器上，默认标识名为route （a）客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。 （b）后端服务器处理完请求，将响应数据返回给nginx。 （c）此时nginx生成带route的cookie，返回给客户端。route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值 （d）客户端接收请求，并保存带route的cookie。 （e）当客户端下一次发送请求时，会带上route，nginx根据接收到的cookie中的route值，转发给对应的后端服务器。 其他需要注意的 （a）同一客户端的请求，有可能落在不同的后端服务器上。如果客户端启动时同时发起多个请求。由于这些请求都没带cookie，所以服务器会随机选择后端服务器，返回不同的cookie。当这些请求中的最后一个请求返回时，客户端的cookie才会稳定下来，值以最后返回的cookie为准。 （b）cookie不一定生效。由于cookie最初由服务器端下发，如果客户端禁用cookie，则cookie不会生效。 （c）客户端可能不带cookie。Android客户端发送请求时，一般不会带上所有的cookie，需要明确指定哪些cookie会带上。如果希望用sticky做负载均衡，请对Android开发说加上cookie。 （d）cookie名称不要和业务使用的cookie重名。Sticky默认的cookie名称是route，可以改成任何值。 （e）客户端发的第一个请求是不带cookie的。服务器下发的cookie，在客户端下一次请求时才能生效。 （f）Nginx sticky模块不能与ip_hash同时使用 sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h] [hash=index|md5|sha1] [no_fallback] [secure] [httponly]; [name=route] 设置用来记录会话的cookie名称 [domain=.foo.bar] 设置cookie作用的域名 [path=/] 设置cookie作用的URL路径，默认根目录 [expires=1h] 设置cookie的生存期，默认不设置，浏览器关闭即失效，需要是大于1秒的值 [hash=index|md5|sha1] 设置cookie中服务器的标识是用明文还是使用md5值，默认使用md5 [no_fallback] 设置该项，当sticky的后端机器挂了以后，nginx返回502 (Bad Gateway or Proxy Error) ，而不转发到其他服务器，不建议设置 [secure] 设置启用安全的cookie，需要HTTPS支持 [httponly] 允许cookie不通过JS泄漏，没用过