㈠ java：Jedis操作Redis時，是否有回調寫法知道某個key是否超時呢
我也不知道，能查所有的key，先查下所有的key然後再做操作
？
㈡ java設置 redis 失效時間多久
EXPIRE命令返回1表示成功，返回0表示鍵值不存在或設置失敗。
同時這里還有一個比較常用的命令是ttl，用於查看一個鍵還有多久時間會被刪除。返回的是剩餘時間（秒數）。
這里就不貼代碼了，有一點需要說明的是，ttl命令在鍵不存在或被刪除之後，會返回-2，在沒有為鍵設置生存時間（即永久存在，建一個鍵之後的默認情況）時返回的是-1。大家可以親自操作一把。
如果想要把一個設置過過期時間的鍵取消過期時間設置，則需要使用persist命令。
redis > SET session:27e7a id1234
OK
redis > EXPIRE session:27e7a 1200
(integer) 1
redis > TTL session:27e7a
(integer) 1092
redis > PERSIST session:27e7a
(integer) 1
redis > TTL session:27e7a
(integer) -1
這里需要說明一點的是，除了使用persist命令外，使用set、getset命令為鍵賦值，也會同時消除鍵的生存時間，如果需要可以重新使用expire命令為鍵設置生存時間。而其他對鍵的操作命令（如incr、lpush、hset、zrem）都不會影響鍵的生存時間。
expire命令的單位是秒，而且這個參數必須為整數，如果需要更精準的時間的話，需要使用pexpire命令設置，其單位為毫秒，同理也需要用pttl命令來看鍵的剩餘毫秒數。當然使用expire命令設置的過期時間也是可以用pttl看鍵的剩餘毫秒數的。
訪問限制
有時候我們會有一個需求是需要限制一個用戶對一個資源的訪問頻率，我們假定一個用戶（用IP作為判斷）每分鍾對一個資源訪問次數不能超過10次。
我們可以使用一個鍵，每次用戶訪問則把值加1，當值加到10的時候，我們設定鍵的過期時間為60秒，並且禁止訪問。這時候下次訪問發現值為10，則不讓訪問了，然後60秒後鍵被刪除，這時候再次創建鍵。這樣就可以解決，但是其實這樣時間並不精準，問題還是挺大的。
我們還有一個方案：使用隊列。前面的章節也說到了，使用列表類型可以用作隊列。
我們設定一個隊列rate.limiting.192.168.1.1（假定是這個IP），我們把每次的訪問時間都添加到隊列中，當隊列長度達到10以後，判斷當前時間與隊列第一個值的時間差是否小於60，如果小於60則說明60秒內訪問次數超過10次，不允許訪問；否則說明可以訪問，則把隊列頭的值刪除，隊列尾增加當前訪問時間。
這種方法可以比較精準的實現訪問限制，但是當限制的次數比較大時，這種方法佔用的存儲空間也會比較大。
緩存
有時候會把一些對CPU或IO資源消耗比較大的操作結果緩存起來，並設置一定時間的自動過期。比如我們設定一個微博外鏈的最熱站點緩存放於新浪微博的首頁，這樣我們不可能每次訪問都重新計算最熱的外鏈站點，所以我們可以設定兩小時更新一次。每次訪問是判斷這個鍵有沒有，如果存在則直接返回，如果沒有則通過計算把內容存入鍵中，並設定兩小時的過期時間。
然而在很多場合這種方法會很恐怖，當伺服器內存有限的時候，大量使用緩存切設置生存時間過長就會導致redis佔用太多內存，而redis有時候會把系統內存都吃掉，導致系統崩潰。但是設置時間過短又會導致緩存的命中太低。
所以我們最好的辦法是設定緩存的淘汰規則。這種方式比較適用於將redis用作緩存系統的時候比較好。
具體就是：修改配置文件中的maxmemory參數，限制redis的最大內存，當超出後會按照maxmemory-policy參數指定的策略刪除不需要的鍵，直到redis佔用的內存小於設定值。
㈢ 關於java redis的操作jedis的疑問
ava操作redis的jedis的范圍查詢是怎麼寫的？ 我要從一個范圍到另一個范圍的區間
我試過了，
List userList = jedis.lrange("userList", 0, -1);
Set user = jedis.zrange("user", 0, -1);
這兩個范圍查詢的得到結果，為何都是 0
但是我用 Set str =jedis.keys("tes2:*");
發現是用完整的數據的，我一次性讀取這么多數據，redis直接socket失敗了
它是專為 .NET 平台設計的一種靜態類型編程語言。 Nemerle 中的程序會被編譯成中間語言位元組碼。它支持函數式，命令式以及面向對象編程。
㈣ java使用redis時不時的報沒有可用的鏈接
出現這種問題從以下幾個方面排查：
1、網路不穩定，這種情況只會出現在調用機器和redis伺服器不在同一台機器的情況，如果調用本機redis請忽略。
2、使用了連接池，並發較大，連接池配置的最大連接數過小，客戶端從連接池獲取連接時，如果沒有可用連接就阻塞當前線程直到有可用連接，等待時間超過配置的超時時間後會拋出連接超時異常。
3、同樣是使用連接池的情況，從連接池獲取連接，使用完成後沒有釋放連接，導致連接池鏈接耗盡。
4、還有可能是硬體性能瓶頸，比如單節點的redis，但是需要支持特別大的並發量，無論怎麼優化配置都是徒勞的，這種情況就需要考慮做讀寫分離，搭建redis集群等，
㈤ spring-data-redis可以設置超時時間嗎
spring-data-redis 中的核心操作類是 RedisTemplate
可以看出 key 和 value 都是泛型的，這就涉及到將類型進行序列化的問題了
所就在 RedisTemplate 中還有幾個 RedisSerializer~
1)redisConnectionFactory()配置了如何連接Redsi伺服器（如何安裝Redis,
2）oxmSerializer()是我新增的，用於定義一個基於Jaxb2Marshaller的OxmSerializer Bean(後面將會用到)
㈥ Java：用redis實現單點登錄是否可行請大神看一下我的方法
用redis實現單點登錄是可行的。
首先，session的大部分實現都是通過cookie的，所以跨域session是不可能的。但跨域的認證還是可以有OAuth等實現方法，不太推薦OAuth項目。
其次，跨域有點難，但放在同一域下的不同項目是可以共享session的，CAS也不算復雜。可以上github搜一下redis-session這個項目，只有一個源代碼文件，它給出了redis下session的一種nodejs實現，就是設置redis的超時來模擬session的超時。
再次，跨域也是可以的，就是使用iframe，在登錄時，在多個域下同時寫cookie，注意瀏覽器差異。
綜上，完全可行。
㈦ java怎麼模擬redis緩存超時
從expires中查找key的過期時間，如果不存在說明對應key沒有設置過期時間，直接返回。
如果是slave機器，則直接返回，因為Redis為了保證數據一致性且實現簡單，將緩存失效的主動權交給Master機器，slave機器沒有許可權將key失效。
如果當前是Master機器，且key過期，則master會做兩件重要的事情：1）將刪除命令寫入AOF文件。2）通知Slave當前key失效，可以刪除了。
master從本地的字典中將key對於的值刪除。
主動失效機制
主動失效機制也叫積極失效機制，即服務端定時的去檢查失效的緩存，如果失效則進行相應的操作。
我們都知道Redis是單線程的，基於事件驅動的，Redis中有個EventLoop，EventLoop負責對兩類事件進行處理：
一類是IO事件，這類事件是從底層的多路復用器分離出來的。
一類是定時事件，這類事件主要用來事件對某個任務的定時執行。
㈧ redis 為什麼會socket超時
Redis在分布式應用中占據著越來越重要的地位，短短的幾萬行代碼，實現了一個高性能的數據存儲服務。最近mp中心的cm8集群出現過幾次redis超時的情況，但是查看redis機器的相關內存都沒有發現內存不夠，或者內存發生交換的情況
㈨ java連接redis超時問題怎麼解決
應該是redis本身的服務有問題了
本文所針對的連接超時問題所涉及的相關元素如下:
Redis客戶端: Jedis (java)
Redis版本 :2.8.12
Redis部署操作系統類型:Linux
正文開始:
No 1.Redis執行大命令(時間復雜度為O(N)的命令)
問題剖析:
a.Redis伺服器端通過單線程處理命令,一旦有大命令被執行,Redis將無法及時響應來自客戶端的任何命令
關於Redis大命令的監控,可以查看slowlog來觀察
b.在使用jedis作為redis客戶端時,當redis連接池的配置參數testOnBorrow=true時,默認會在獲取redis連接
時,先執行redis的ping方法,而基於原因a,此時redis將無法及時響應,自然會報出time out異常
如何解決:
a.盡量避免使用時間復雜度為O(N)的命令
b.如果無法避免使用時間復雜度為O(N)的命令,則應降低其使用頻率,避免在業務高峰期時使用
No 2.Redis單次操作數據包過大
問題分析
a.單次操作數據包過大,且操作頻繁,極有可能會導致網路擁堵
b.在使用jedis作為redis客戶端時,當redis連接池的配置參數testOnBorrow=true時,默認會在獲取redis連接
時,先執行redis的ping方法,而基於原因a,此時redis將無法及時響應,自然會報出time out異常
如何解決:
a.排查代碼,確定是否存在大數據(數據條目過多/單條數據過大)操作,將其進行改造,改造方案有兩個:
a1.數據拆分,變更數據類型(常見的情況是將java中的collection類型序列化後存入redis的String數據
類型中),如將String數據類型調整為hash/list/set等,這常用於解決單條數據量過大的情況
a2.調整業務邏輯,減少單次數據查詢范圍(常見的情況如將redis中的整個hash數據取回,在應用程序內存中獲取需要的entry),如使用hget等單條查詢命令替換hgetall命令