在 Redis 里，所谓 SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果，不过很多人没有意识到 SETNX 有陷阱！
比如说：某个查询数据库的接口，因为调用量比较大，所以加了缓存，并设定缓存过期后刷新，问题是当并发量比较大的时候，如果没有锁机制，那么缓存过期的瞬间，大量并发请求会穿透缓存直接查询数据库，造成雪崩效应，如果有锁机制，那么就可以控制只有一个请求去更新缓存，其它的请求视情况要么等待，要么使用过期的缓存。
Nginx 配置之安全篇
一、隐藏不必要的信息
大家可以看一下我的博客请求响应头，有这么一行 server: nginx，说明我用的是 Nginx 服务器，但并没有具体的版本号。由于某些 Nginx 漏洞只存在于特定的版本，隐藏版本号可以提高安全性。这只需要在配置里加上这个就可以了：
server_tokens off;
Nginx 配置之性能篇
本文提到的一些 Nginx 配置，需要较高版本 Linux 内核才支持。在实际生产环境中，升级服务器内核并不是一件容易的事，但为了获得最好的性能，有些升级还是必须的。很多公司服务器运维和项目开发并不在一个团队，一方追求稳定不出事故，另一方希望提升性能，本来就是矛盾的。好在我们折腾自己 VPS 时，可以无视这些限制。
HBase、Hadoop版本兼容汇总
HBase的下载地址：http://mirror.bit.edu.cn/apache/hbase/
Hadoop的下载地址：http://mirror.bit.edu.cn/apache/hadoop/common/
Zookeeper配置
# zookeeper中使用的基本时间单位, 毫秒值
tickTime=2000
# zookeeper集群中的包含多台server, 其中一台为leader, 集群中其余的server为follower.
# initLimit参数配置初始化连接时, follower和leader之间的最长心跳时间.
# 此时该参数设置为5, 说明时间限制为5倍tickTime, 即5*2000=10000ms=10s.
initLimit=5
Redis集群技术及Codis实践
互联网早在几年前就已进入Web 2.0时代，对后台支撑能力的要求，提高了几十倍甚至几百倍。在这个演化过程中，缓存系统扮演了举足轻重的角色。运维进化到今天，已经不是重复造轮子的时代。所以，我们在架构优化和自动化运维中，可以尽可能地选用优秀的开源产品，而不是自己完全从头再来（各种技术geek除外）。
Codis集群部署实战
一、概要
1、折腾codis集群已经快两个月了，感谢一直以来codis的作者刘奇和黄东旭的耐心支持，在这里给你们点个赞，现在我司已经有一个业务跑在了codis集群上，目前只是切了整个业务的10%的量，预计下周会全量切到codis上，这个时候大家肯定特别想知道codis稳定吗？有没有什么bug啊，你想知道的也是我想知道的，搞起吧，用了才知道，反正目前我们这没发现啥问题，一些小的问题已经及时联系作者改掉了，好吧，不扯淡了，写这篇文章的目的是帮助想了解codis的初学者快速部署（官方的部署文档对应运维知识弱一点的童鞋看来还是有点费力）还有就是给自己做一个备录以便后期集群的部署。
Redis的常用命令
Redis中sentinel配置
# Example sentinel.conf
# port <sentinel-port>
# The port that this sentinel instance will run on
port 26379
#指定sentinel使用的端口，不能与redis-server运行实例的端口冲突
redis配置详解
# Redis configuration file example.
#
# Note that in order to read the configuration file, Redis must be
# started with the file path as first argument:
#
# ./redis-server /path/to/redis.conf //启动redis服务
# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:
#当你需要为某个配置项指定内存大小的时候，必须要带上单位1k后者1kb，且大小写通用
Redis的安装
CentOS网络接口配置文件ifcfg-eth详解
文件路劲：/etc/sysconfig/network-scripts/ifcfg-eth0
继续阅读
Linux防火墙设定(iptables的使用)
一、四种tables
- filter (过滤器)：主要跟进入 Linux 本机的封包有关，这个是预设的 table 喔！
INPUT：主要与想要进入我们 Linux 本机的封包有关； OUTPUT：主要与我们 Linux 本机所要送出的封包有关； FORWARD：这个咚咚与 Linux 本机比较没有关系， 他可以『转递封包』到后端的计算机中， 与下列 nat table 相关性较高。
HTTP_X_FORWARDED_FOR,HTTP_VIA,REMOTE_ADDR的区别
HTTP负载均衡/反向代理相关参数测试
一、测试目的
- 弄清楚HTTP Upstream 模块中Server指令的max_fails与fail_timeout参 数的关系、它们对后端服务器健康情况的检查起到了什么作用、它们的取值对Http proxy模块中的其它指令是否有直接或间接的影响等
- 测试HTTP Proxy模块中proxy_next_upstream、proxy_connect_timeout、proxy_read_timeout、 proxy_send_timeout指令的作用、对nginx性能的影响、对后端服务器响应的处理等
Nginx反向代理配置
Nginx基本配置与参数说明
使用nginx后如何获取用户ip及原理解释
问题背景：
在实际应用中，我们可能需要获取用户的ip地址，比如做异地登陆的判断，或者统计ip访问次数等，通常情况下我们使用request.getRemoteAddr()就可以获取到客户端ip，但是当我们使用了nginx作为反向代理后，使用request.getRemoteAddr()获取到的就一直是nginx服务器的ip的地址，那这时应该怎么办？ 继续阅读
Nginx location匹配规则
一、匹配命令
- ~ 表示执行一个正则匹配，区分大小写
- ~* 表示执行一个正则匹配，不区分大小写
- ^~ 表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
- = 进行普通字符精确匹配
- @ 定义一个命名的 location，使用在内部定向时，例如 error_page, try_files
Nginx upstream的分配方式
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。