redis文檔翻譯_key設定到期時間，redis_key

redis文檔翻譯_key設定到期時間，redis_key

Available since 1.0.0.    使用開始版本1.01

Time complexity: O(1)  時間複雜度O（1）

出處：http://blog.csdn.net/column/details/redisbanli.html

Set a timeout on key. After the timeout has expired, the key will automatically be deleted. A key with an associated timeout is often said to be volatile in Redis terminology.

在key上設定一個逾時時間。這個時間期滿後，key會自動被刪除。key關聯一個逾時時間，在Redis術語中叫volatile （易揮發的）

The timeout is cleared only when the key is removed using the DEL command or overwritten using the SET or GETSET commands. This means that all the operations that conceptually alter the value stored at the key without replacing it with a new one will leave the timeout untouched. For instance, incrementing the value of a key with INCR, pushing a new value into a list with LPUSH, or altering the field value of a hash with HSET are all operations that will leave the timeout untouched.

這個逾時時間僅僅在使用 DEL命令或者使用SET或者GETSET命名重寫時被清除。所有操作，從概念上在key沒有替換，改變儲存的值將與一個新的逾時時間關聯。例如，使用INCR增量操作一個值，使用LPUSH為list增加新值，或者使用HEST設定hash欄位的新值，所有的操作重新關聯一個逾時時間。
The timeout can also be cleared, turning the key back into a persistent key, using thePERSIST command.
也可以使用PERSIST命令將有到期時間的key轉換成永久的key。If a key is renamed with RENAME, the associated time to live is transferred to the new key name.
如果key被RENAME重命令，那麼關聯的時間將被轉移到這個新的key名字上。If a key is overwritten by RENAME, like in the case of an existing key  Key_A that is overwritten by a call like  RENAME Key_B Key_A, it does not matter if the original  Key_Ahad a timeout associated or not, the new key  Key_A will inherit all the characteristics of  Key_B.
如果一個key被RENAME命令覆蓋，例如已經存在了一個Key_A，使用命令RENAME Key_B Key_A(將key_B重名為KEY_A),不管原來的Key_A有沒有關聯逾時時間，新的Key_A將繼承Key_B的所有特性。
Refreshing expires  重新整理到期It is possible to call EXPIRE using as argument a key that already has an existing expire set. In this case the time to live of a key is  updated to the new value. There are many useful applications for this, an example is documented in the  Navigation session pattern section below.
可以使用命令EXPIRE重新為已經存在的逾時時間的key設定新的逾時時間。假如這樣做了，關聯這個key的逾時時間將被更新成新設定的值。在許多應用非常有用，例如下一節的例子。Differences in Redis prior 2.1.3在Redis的2.1.3之前的區別In Redis versions prior  2.1.3 altering a key with an expire set using a command altering its value had the effect of removing the key entirely. This semantics was needed because of limitations in the replication layer that are now fixed.
在Redis2.1.3版本之前，使用命令改變key逾時時間設定，這個值將明確影響key的刪除。因為在那時固定複製層的限制，這種語義是必要的。Return value  返回值Integer reply, specifically:特別的Iteger回覆

• 1 if the timeout was set.    1代表設定了逾時限制
• 0 if key does not exist or the timeout could not be set. 0表示key不存在或者key沒有設定逾時時間。

Examples  redis>  SET mykey "Hello"

OK

redis>  EXPIRE mykey 10

(integer) 1

redis>  TTL mykey

(integer) 10

redis>  SET mykey "Hello World"

OK

redis>  TTL mykey

(integer) -1

redis> 
Pattern: Navigation session 映像session導航Imagine you have a web service and you are interested in the latest N pages  recently visited by your users, such that each adjacent page view was not performed more than 60 seconds after the previous. Conceptually you may think at this set of page views as a  Navigation session if your user, that may contain interesting information about what kind of products he or she is looking for currently, so that you can recommend related products.
想象一下，你有一個web服務，並且你對你的使用者最後訪問的N個網頁高度興趣，使得通過前面的每個相鄰頁面訪問的執行沒有超過60秒。從概念上講你可能認為，頁面瀏覽量大的就是你的使用者佈建頁面的導航會話，那麼可能包含他或她目前正在尋找關於產品種類的有趣資訊，因此你就可以推薦相關的產品。You can easily model this pattern in Redis using the following strategy: every time the user does a page view you call the following commands:
在Redis中你可以使用一個簡單的模式實現：每次使用者訪問網頁就執行下面的命令：

MULTIRPUSH pagewviews.user:<userid> http://.....EXPIRE pagewviews.user:<userid> 60EXEC

If the user will be idle more than 60 seconds, the key will be deleted and only subsequent page views that have less than 60 seconds of difference will be recorded.

如果使用者閑置網頁超過60秒，key將要被刪除並且只有後續訪問不同的網頁少於60秒才會被重新記錄。

This pattern is easily modified to use counters using INCR instead of lists usingRPUSH.

這個模式很簡單地使用了list的RPUSH代碼自曾INCR。Appendix: Redis expires  附件：Redis到期
Keys with an expire  key的到期Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command.
一般key建立沒關聯到期時間。這種key將永遠存在，除非被使用者明確地刪除，例如使用者使用DEL命令。

The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed.

EXPIRE命令族能去關聯給出給出key，有額外的記憶體開銷。當一個key有設定到期時間，Redis確保當到期時間過去時刪除這個key。

The key time to live can be updated or entirely removed using the EXPIRE andPERSIST command (or other strictly related commands).

key的到期時間被更新或者刪除，使用命令EXPIRE 和PERSIST命令實現。Expire accuracy  到期時間精確性

In Redis 2.4 the expire might not be pin-point accurate, and it could be between zero to one seconds out.

在2.4版本之前，到期時間可能不太精確，可能會有0到1秒的誤差。

Since Redis 2.6 the expire error is from 0 to 1 milliseconds.

從2.6版本之後誤差在0到1毫米之間。
Expires and persistence 到期和持久Keys expiring information is stored as absolute Unix timestamps (in milliseconds in case of Redis version 2.6 or greater). This means that the time is flowing even when the Redis instance is not active.
key的到期時間資訊是使用Unix的時間戳記儲存的（從2.6開始使用毫米層級）。意思是即使Redis執行個體沒有已耗用時間也是在流失的。
For expires to work well, the computer time must be taken stable. If you move an RDB file from two computers with a big desync in their clocks, funny things may happen (like all the keys loaded to be expired at loading time).
為了使到期時間工作穩定，必須保證電腦時間穩定。如果你在兩個電腦之間移動RDB檔案的時間延遲非常大，那麼很多有趣是的事情可能就會發生（比如所有設定到期時間的key剛被載入就到期了）。
Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.
甚至Redis總是在檢測電腦時間的，以至於如果你設定一個key的存活為1000秒，然後你設定你的電腦時間為2000秒之後的時間，那麼這個key就會立刻到期，而且已經到期1000秒了。How Redis expires keys Redis的key是如何到期的

Redis keys are expired in two ways: a passive way, and an active way.

Redis key的到期方式有兩種：被動到期和主動到期

A key is actively expired simply when some client tries to access it, and the key is found to be timed out.

主動方式到期比較簡單，當有用戶端去訪問這個key時，找到這個key並且使之逾時。Of course this is not enough as there are expired keys that will never be accessed again. These keys should be expired anyway, so periodically Redis tests a few keys at random among keys with an expire set. All the keys that are already expired are deleted from the keyspace.
當然這還不夠，因為有些key可能在設定到期時間之後，就一直都沒有被訪問。這些key無論如何都應該被到期的，因此Redis會定期隨機抽取設定有到期時間的key進行檢查。到期的key到期將被從 key空間刪除掉。Specifically this is what Redis does 10 times per second:
Redis每秒進行10次檢測：   1：Test 20 random keys from the set of keys with an associated expire.        隨機抽取設定有到期時間中的20個key。   2：Delete all the keys found expired.    刪除已經到期的key。  3：If more than 25% of keys were expired, start again from step 1. 如果有超過25%的key被逾時，那麼開始步驟1。
This is a trivial probabilistic algorithm, basically the assumption is that our sample is representative of the whole key space, and we continue to expire until the percentage of keys that are likely to be expired is under 25%
這個機率演算法是不重要的，主體上就是假設我們的樣品代表了整個key空間，並且繼續使key到期，直到有25%以上的key到期，然後開始第一步。
This means that at any given moment the maximum amount of keys already expired that are using memory is at max equal to max amount of write operations per second divided by 4.
意思是任何時刻，給出已經到期的最大數量key，這些到期key使用的最大記憶體等於每秒最大數量寫操作除以4倍。How expires are handled in the replication link and AOF file在AOF檔案和複製串連中到期是如何處理的

In order to obtain a correct behavior without sacrificing consistency, when a key expires, a DEL operation is synthesized in both the AOF file and gains all the attached slaves. This way the expiration process is centralized in the master instance, and there is no chance of consistency errors.

為了獲得不犧牲一致性的正確做法，當一個key到期時，DEL操作將在AOF檔案和所有的 slaves中同步。這種方式中，到期在master執行個體集中處理，並且避免產生改變一致性錯誤。

However while the slaves connected to a master will not expire keys independently (but will wait for the DEL coming from the master), they'll still take the full state of the expires existing in the dataset, so when a slave is elected to a master it will be able to expire the keys independently, fully acting as a master.

然而，當slaves串連到master上時，就不會獨立地使key到期（但是會等待master DEL的到來），他們將使用所有在資料設定中有到期狀態的key，因此當一個slave被推選成為master時，它將開始獨立地去到期key，充當maste的角色。

出處：http://blog.csdn.net/column/details/redisbanli.html