遷Aliyun Redis遇到的坑分析

這篇文章主要介紹“遷Aliyun Redis遇到的坑分析”，在日常操作中，相信很多人在遷Aliyun Redis遇到的坑分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”遷Aliyun Redis遇到的坑分析”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

背景：

從自建 redis（CacheCloud）到遷移到 aliyun redis

1. 踩“坑”一

問題：
平常小伙伴們在項目中可能用到redis key expire nofity的場景（比如：處理延時任務等），但是發現遷移后 key 過期通知總是比未遷移之前的時間慢一個數量級（基本上分鐘級別，社區版基本上秒級別），及時在很少的 key 情況也是一樣的；之前也和 aliyun support 小伙伴溝通過，給出反饋都一個星期多了~
定位：
了解過 redis 的過期策略以及淘汰策略的小伙伴，應該都知道針對惰性刪除測試，是遍歷整個 db，隨機選取 20 個 key（默認），淘汰；但是，aliyun redis（使用的是 4.x 版本）的默認 db 數是 256（社區版的是 16）
解決：
調整項目 redis db 數為16

2. 踩“坑”二

問題：
遷移后的 redis，在域名（aliyun redis 針對社區版的主從，哨兵，集群模式等暴露出一個域名）指向 ip 發生變化的時候，客戶端通過域名訪問的時候，依然解析指向的是老的 ip，導致連接不上 redis~
定位：
查看 JedisConnectionFactory 的源碼可以發現（以集群為例），在初始化 afterPropertiesSet 時，已經將域名解析成對應的 ip 緩存起來了，故之后域名切換 ip 后，依然訪問的是之前的 ip

private JedisCluster createCluster() {

		JedisCluster cluster = createCluster(this.clusterConfig, getPoolConfig());
		JedisClusterConnection.JedisClusterTopologyProvider topologyProvider = new JedisClusterConnection.JedisClusterTopologyProvider(cluster);
		this.clusterCommandExecutor = new ClusterCommandExecutor(topologyProvider,
				new JedisClusterConnection.JedisClusterNodeResourceProvider(cluster, topologyProvider), EXCEPTION_TRANSLATION);
		return cluster;
	}

解決：
切換域名 ip 后重啟服務

到此，關于“遷Aliyun Redis遇到的坑分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！