若是redis已在線上業務使用中,但沒有添加密碼認證,那麼如何在不影響業務服務的前提下給redis添加密碼認證,就是一個須要仔細考慮的問題。git
本文描述一種可行的方案,適用於客戶端使用了jedis鏈接池,服務端使用了redis master-slave集羣的狀況。github
對redis返回的錯誤的處理,作兩處修改:redis
忽略 (error) ERR Client sent AUTH, but no password is set。使配置了密碼的jedis能夠在沒有配置密碼redis上使用;apache
發生(error) NOAUTH Authentication required時,將當前connection置爲broken,從而將鏈接踢出鏈接池。這樣動態給redis添加上密碼時,jedis會自動從新建立可用鏈接。服務器
我已經對jedis 2.8.x版本作好了以上修改。能夠直接下載使用 。若是使用了更高的版本jedis,能夠參考個人代碼自行修改;若是使用了更低版本的,建議升級到2.8.x。maven
修改maven配置。將原來的jedis依賴註釋掉,添加對本地的定製jedis的依賴:ui
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.8.3</version> <scope>system</scope> <systemPath>${project.basedir}/../libs/jedis-2.8.3.jar</systemPath> <!-- 此處的systemPath是jedis-2.8.3所在的相對路徑 --> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> <version>2.4.2</version> </dependency> <!-- <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.8.1</version> </dependency> -->
由於把定製jedis經過本地jar包的形式提供,maven不會自動加載jedis的依賴,因此需額外添加對commons-pool2的依賴。加密
老版本jedis的returnBrokenResource和returnResource這兩個方法在新版本jedis中已經廢棄,若是升級jedis版本的話,須要替換爲close方法。code
替換前:server
try { // ... } catch (JedisException e) { // ... pool.returnBrokenResource(jedis); } finally { pool.returnResource(jedis); }
替換後:
try { // ... } catch (JedisException e) { // ... } finally { jedis.close(); }
此時redis還沒有添加密碼,但定製jedis忽略了「ERR Client sent AUTH, but no password is set」,因此線上運行正常。
動態添加密碼會致使redis主從同步斷開,爲避免引發全量同步對業務形成較大影響。須要dba先調大redis master的client-output-buffer-limit和repl-backlog-size參數,再作配置密碼操做。
給redis server添加密碼的同時,觀察業務代碼的log,添加完密碼後,log中會出現數次以下報錯,隨後恢復正常。報錯次數是添加密碼時,業務服務器的jedis鏈接池中與該redis server之間鏈接數量。
redis.clients.jedis.exceptions.JedisConnectionException: NOAUTH Authentication required.
若是使用了shardedJedis,請逐個分片進行操做,最小化對業務服務的影響。
定製jedis就是爲了動態添加密碼認證。添加完畢後,換回官方jedis,方便從此升級。
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.8.1</version> </dependency>