最近集团安全部扫描到我们组的redis没有设置密码。如何扫描的？一个脚本，登陆到服务器上查看固定路径下的redis配置，没有配置密码就被扫出来。简单无脑暴力。
于是开始虐心的添加redis密码之旅。
Server端配置
方法1：redis-cli -h xxx -p xxx CONFIG SET requirepass xxx
方法2：修改redis.conf文件，配置requirepass
对于twemproxy，可以升级到最新版本，然后配置redis_auth xxx。
Client端配置(Jedis)
项目中都是用的JedisPool。我们的方案是给所有代码进行如下处理：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
... var jedis: Jedis = null try { jedis = jedisPool.getResource try{jedis.auth(password)}catch {case Exception=> } ///捕获一切异常，如果redis没有设置密码，这里的异常会被捕获，不影响后续操作 ... } finally { if (jedis != null) { jedisPool.returnResource(jedis.asInstanceOf[BinaryJedis]) } } ... |
看起来应该没问题，实际上测试了下，也一切ok，于是开始了第一次改密码尝试。将涉及到的七八个应用、几十处代码全部修改完毕上线后，一切正常。然后redis server端添加密码，瞬间崩溃了四五个服务，只剩两三个服务正常运转。于是立马去掉密码，开始查原因。
JedisPool初始化的坑
|
1 |
public JedisPool(final Config poolConfig, final String host, int port, int timeout, final String password, final int database) |
经过一轮排查，发现出问题的服务都是用的上面的方式初始化JedisPool。而没有出问题的都是下列方式初始化：
|
1 |
public JedisPool(final Config poolConfig, final String host, final int port, final int timeout) |
然后看了下源码，果然在有database参数且不等于0时，会进行一次select操作，而我们的password用的是null，所以就会报错。于是又一次将涉及到的七八个应用、几十处代码全部修改完毕，开始第二次改密码尝试。所有应用上线后，一切正常。开始redis server端添加密码，瞬间又是几个服务崩溃，几个服务正常。于是立马去掉密码，开始第二次查原因。
setTestOnBorrow的坑
又一轮排查后，发现出问题的服务都是
还好，没有其他幺蛾子了，这次终于没有问题，加上密码，去掉密码，服务都正常运转。心塞。
哥们，我问个问题，你把testOnborrow去掉了。。如果得到的jedis资源是个不可用的，服务从来都不出问题么？
哥们，我问个问题，你把testOnborrow去掉了。。如果得到的jedis资源是个不可用的，服务从来都不出问题么？