如果redis已在線上業務使用中,但沒有添加密碼認證,那么如何在不影響業務服務的前提下給redis添加密碼認證,就是一個需要仔細考慮的問題。
本文描述一種可行的方案,適用于客戶端使用了jedis連接池,服務端使用了redis master-slave集群的情況。
1.定制jedis
對redis返回的錯誤的處理,做兩處修改:
忽略 (error) ERR Client sent AUTH, but no password is set。使配置了密碼的jedis可以在沒有配置密碼redis上使用;
發生(error) NOAUTH Authentication required時,將當前connection置為broken,從而將連接踢出連接池。這樣動態給redis添加上密碼時,jedis會自動重新創建可用連接。
我已經對jedis 2.8.x版本做好了以上修改。可以直接下載使用 。如果使用了更高的版本jedis,可以參考我的代碼自行修改;如果使用了更低版本的,建議升級到2.8.x。
2.在項目代碼中使用定制的jedis
修改maven配置。將原來的jedis依賴注釋掉,添加對本地的定制jedis的依賴:
<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的依賴。
3.如果使用了低版本的jedis
老版本jedis的returnBrokenResource和returnResource這兩個方法在新版本jedis中已經廢棄,如果升級jedis版本的話,需要替換為close方法。
替換前:
try { // ... } catch (JedisException e) { // ... pool.returnBrokenResource(jedis); } finally { pool.returnResource(jedis); }
替換后:
try { // ... } catch (JedisException e) { // ... } finally { jedis.close();}
4.將使用定制jedis的項目代碼上線
此時redis尚未添加密碼,但定制jedis忽略了“ERR Client sent AUTH, but no password is set”,所以線上運行正常。
5.給redis server添加密碼認證
動態添加密碼會導致redis主從同步斷開,為避免引起全量同步對業務造成較大影響。需要dba先調大redis master的client-output-buffer-limit和repl-backlog-size參數,再做配置密碼操作。
給redis server添加密碼的同時,觀察業務代碼的log,添加完密碼后,log中會出現數次如下報錯,隨后恢復正常。報錯次數是添加密碼時,業務服務器的jedis連接池中與該redis server之間連接數量。
如果使用了shardedJedis,請逐個分片進行操作,最小化對業務服務的影響。
6.更換jedis為官方版本
定制jedis就是為了動態添加密碼認證。添加完畢后,換回官方jedis,方便今后升級。
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.8.1</version></dependency>
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持武林網。
新聞熱點
疑難解答