原外包項目redis cluster 三主三從沒有密碼，後面因申請三級等保，要求需要密碼，這時項目尚未交接，於是讓外包公司把集羣密碼補上。
補上密碼之後看似也沒有任何問題，就這樣跑了三個月。
中間因項目框架升級替換了外包原有封裝的jedis客戶端爲redisson，將spring3.1.2升級成springboot項目，然後將項目中原本使用 redisUtil的地方全部替換成redisTemplate，並且將分佈式鎖替換成redissonclient,這個時候也沒有問題。
直到某一天一個開發用redissoncleint 去set，get值發現set成功了但是get爲null，但是在開發環境下同樣的集羣又好用，開發環境原本是單機的，是後面我們自己部署的集羣，於是就開始找問題；各種猜測，得出兩個結論：
- 集羣配置的有問題
redisson client配置有問題
又想既然redistemplate的set，get又正常，那應該是redisson配置有問題的可能性比較大，於是看了下redisson的默認配置，發現readmode默認配置爲slave，於是改了下readmode爲master、或者maste_slave之後就好用了，於是這裏得出一個結論是不是slave節點沒同步導致的，順着這個思路去看了下生產的日誌發現 這樣一個報錯Unexpected reply to PSYNC from master: -NOAUTH Authentication required立馬get到問題所在，配置了密碼卻沒有配置集羣憑證，導致寫的時候寫master，讀的時候讀slave，但是slave數據無法同步到，於是就出現如上情況。
於是技術追溯爲什麼之前外包寫的client沒問題？一看代碼發現他們的寫法是循環拿到所有節點，一個個遍歷去取，這是什麼寫法，看似很笨，但是確實把這個問題完美規避掉了，看到這裏只能給他們豎起一根大大的大拇指。
又看了下爲什麼redisTemplate也沒問題，發現redisTemplate 走的是默認配置用的是LettuceConnectionConfiguration和JedisConnectionConfiguration共同繼承自RedisConnectionConfiguration，這裏設置max-redirect參數，意味着在從節點找不到會返回客戶端重定向到新得節點去獲取，這裏就是被重定向到master節點去獲取，所以沒問題，然而redissonConnectionFactory與這兩者實現不一樣，並沒有max-redirect參數，所以它就不行了。
總結
外包項目真的是隻有把你坑死了才知道坑在哪。