redis文檔翻譯_LRU緩衝，redis文檔_lru
Using Redis as an LRU cache使用Redis作為LRU緩衝
出處：http://blog.csdn.net/column/details/redisbanli.html
When Redis is used as a cache, sometimes it is handy to let it automatically evict old data as you add new one. This behavior is very well known in the community of developers, since it is the default behavior of the popular memcached system.
當使用Redis作為緩衝時，有時候為了向緩衝添加新資料，要讓Redis自動刪除舊資料。在社區，眾所周知的 memcached 系統就有這種預設的做法。
LRU is actually only one of the supported eviction methods. This page covers the more general topic of the Redis maxmemory directive that is used in order to limit the memory usage to a fixed amount, and it also covers in depth the LRU algorithm used by Redis, that is actually an approximation of the exact LRU.
LRU事實上是Redis唯一支援逐出的方法。此頁包括Redis的maxmemory指令，用於限制Redis使用最大實體記憶體的大小，也包含Redis深度的LRU演算法，實際是近似的LRU演算法。
Maxmemory configuration directive 最大記憶體配置指令The maxmemory configuration directive is used in order to configure Redis to use a specified amount of memory for the data set. It is possible to set the configuration directive using the redis.conf file, or later using the CONFIG SETcommand at runtime.
maxmemory 指令是用作配置指定Redis使用記憶體的最大值。可以在redis.conf檔案配置，運行過程中還可以使用CONFIG SET 命令設定。
For example in order to configure a memory limit of 100 megabytes, the following directive can be used inside the redis.conf file.
例如，為了配置限制記憶體為100M，可以在redis.conf檔案中配置：
maxmemory 100mb
Setting
maxmemory to zero results into no memory limits. This is the default behavior for 64 bit systems, while 32 bit systems use an implicit memory limit of 3GB.
設定
maxmemory 為0 的結果是沒有記憶體限制。這是64位系統的預設做法，32位系統是限制3G。
When the specified amount of memory is reached, it is possible to select among different behaviors, called
policies. Redis can just return errors for commands that could result in more memory being used, or it can evict some old data in order to return back to the specified limit every time new data is added.當指定記憶體數量達到最大限制時，Redis可以選擇不同的做法，稱為
policies（政策）。
每當新的資料被添加時，可以只返回一個錯誤，或者可以逐出一些舊資料讓新資料可以被添加。
Eviction policies 逐出政策The exact behavior Redis follows when the
maxmemory limit is reached is configured using the
maxmemory-policy configuration directive.
當Redis記憶體到達上限時，Redis使用 maxmemory-policy 指令配置的政策執行。
The following policies are available: 下面是policies可以配置的 變數
- noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).
- noeviction：當達到最大記憶體使用量限制並且用戶端嘗試執行使用更多記憶體的命令時，將返回一個錯誤。
- allkeys-lru: evict keys trying to remove the less recently used (LRU) keys first, in order to make space for the new data added.
- allkeys-lru：為了新添加的資料使用記憶體，將逐出最近最少使用的key。
- volatile-lru: evict keys trying to remove the less recently used (LRU) keys first, but only among keys that have anexpire set, in order to make space for the new data added.
- volatile-lru: 為了新添加的資料使用記憶體，將逐出有到期時間設定並且最近最少使用的key。
- allkeys-random: evict random keys in order to make space for the new data added.
- allkeys-random:： 為了新添加的資料使用記憶體，將隨機逐出key。
- volatile-random: evict random keys in order to make space for the new data added, but only evict keys with anexpire set.
- volatile-random: 為了新添加的資料使用記憶體，將隨機逐出具有到期時間設定的key。
- volatile-ttl: In order to make space for the new data, evict only keys with an expire set, and try to evict keys with a shorter time to live (TTL) first.
- 為了新添加的資料使用記憶體，將逐出有到期時間限制，並且存活時間（TTL）最短的key。
The policies volatile-lru, volatile-random and volatile-ttl behave like noeviction if there are no keys to evict matching the prerequisites.
volatile-lru,
volatile-random 和
volatile-ttl 在沒有匹配key的時候和
noeviction是一樣的
。
To pick the right eviction policy is important depending on the access pattern of your application, however you can reconfigure the policy at runtime while the application is running, and monitor the number of cache misses and hits using the Redis INFO output in order to tune your setup.
依賴於你的應用去選擇正確的逐出政策是非常重要的，然而在Redis運行時，你也可以重新設定逐出政策，並且你可以使用INFO命令輸出記憶體使用量情況然後重新設定。
In general as a rule of thumb: 一般的配置規則
- Use the allkeys-lru policy when you expect a power-law distribution in the popularity of your requests, that is, you expect that a subset of elements will be accessed far more often than the rest. This is a good pick if you are unsure.
使用allkeys-lru，當你希望你的請求是一個 power-law 分布，如此，你期望常駐記憶體的元素是你可被訪問元素的子集。如果你不確定的話，使用allkeys-lru是好的選擇。
- Use the allkeys-random if you have a cyclic access where all the keys are scanned continuously, or when you expect the distribution to be uniform (all elements likely accessed with the same probability).
如果所有key被周期地訪問或者的當逐出分布不統一時（所有元素被訪問的機率一樣），使用allkeys-random。
- Use the volatile-ttl if you want to be able to provide hints to Redis about what are good candidate for expiration by using different TTL values when you create your cache objects.
在建立對象緩衝的時候如果你想通過使用TTL的值提供好的逐出候選者，使用volatile-ttl 。
The allkeys-lru and volatile-random policies are mainly useful when you want to use a single instance for both caching and to have a set of persistent keys. However it is usually a better idea to run two Redis instances to solve such a problem.
當你使用一個執行個體作為緩衝並且key都是永久性的時候，使用allkeys-lru和
volatile-random。但是還有更好的做法，可以使用兩個Redis執行個體解決記憶體不足問題。
It is also worth to note that setting an expire to a key costs memory, so using a policy like allkeys-lru is more memory efficient since there is no need to set an expire for the key to be evicted under memory pressure.
另外注意，設定到期時間是消耗記憶體的，因此使用像
allkeys-lru 的政策比較有記憶體效率，因為它不需要去為到期的key的逐出增加額外的記憶體壓力。
How the eviction process works 逐出是這樣工作的
It is important to understand that the eviction process works like this:
理解逐出工作方式，就像這樣：
- A client runs a new command, resulting in more data added.
一個用戶端運行一個新的命令，導致更多資料被添加。
- Redis checks the memory usage, and if it is greater than the
maxmemory limit , it evicts keys according to the policy.
Redis檢測記憶體使用量，如何超過
maxmemory 限制，就根據政策逐出key。
- A new command is executed, and so forth.
新的命令被執行。
So we continuously cross the boundaries of the memory limit, by going over it, and then by evicting keys to return back under the limits.
因此我們持續添加資料達到記憶體限制，通過上面的步驟，逐出一些key使得記憶體回到限制之下。
If a command results in a lot of memory being used (like a big set intersection stored into a new key) for some time the memory limit can be surpassed by a noticeable amount.
如果命令的結果是導致很大的記憶體被使用（比如一個新的key是一個大的set集合），很多時候達到記憶體限制是顯而易見的。
Approximated LRU algorithm 近似的LRU演算法Redis LRU algorithm is not an exact implementation. This means that Redis is not able to pick the best candidate for eviction, that is, the access that was accessed the most in the past. Instead it will try to run an approximation of the LRU algorithm, by sampling a small number of keys, and evicting the one that is the best (with the oldest access time) among the sampled keys.
Redis的LRU演算法不是準確的實現。也就是說Redis沒有為逐出選擇 最好的候選人 ，也就是沒有選擇過去最後被訪問離現在最久的。反而 是去執行一個 近似LRU的演算法，通過抽樣少量的key，並且逐出抽樣中最後被訪問離現在最久的key（最老的訪問時間）。
However since Redis 3.0 (that is currently in beta) the algorithm was improved to also take a pool of good candidates for eviction. This improved the performance of the algorithm, making it able to approximate more closely the behavior of a real LRU algorithm.
在Redis 3.0（目前的測試版），演算法被改進了，使用了一個逐出最佳候選池。改進了演算法的效能，使它更加近似真正LRU演算法。
What is important about the Redis LRU algorithm is that you are able to tune the precision of the algorithm by changing the number of samples to check for every eviction. This parameter is controlled by the following configuration directive:
演算法中，關於逐出檢測的樣品數量，你可以自己去調整。配置參數是：
maxmemory-samples 5
The reason why Redis does not use a true LRU implementation is because it costs more memory. However the approximation is virtually equivalent for the application using Redis. The following is a graphical comparison of how the LRU approximation used by Redis compares with true LRU.
Redis沒有使用真正實現LRU算是的原因是，因為消耗更多的記憶體。然而對於使用Redis的應用來說，事實上是等價的。下面是Redis的LRU演算法和真正LRU演算法的比較：
The test to generate the above graphs filled a Redis server with a given number of keys. The keys were accessed from the first to the last, so that the first keys are the best candidates for eviction using an LRU algorithm. Later more 50% of keys are added, in order to force half of the old keys to be evicted.
給出配置數量的key產生上面的圖表。key從第一行到最後一行被訪問，那麼第一個key是LUR演算法中最好的逐出候選者。之後有50%的key被添加，那麼一半的舊key被逐出。
You can see three kind of dots in the graphs, forming three distinct bands.
在中你可以看見3個明顯的區別：
- The light gray band are objects that were evicted.
淺灰色帶是被逐出的對象。
- The gray band are objects that were not evicted.
灰色帶是沒有被逐出的對象。
- The green band are objects that were added.
綠色帶是被添加的對象。In a theoretical LRU implementation we expect that, among the old keys, the first half will be expired. The Redis LRU algorithm will instead only probabilistically expire the older keys.
LRU理論實現是在所有的舊key中前一半被逐出。Redis使用的是近似到期的key被逐出。
As you can see Redis 3.0 does a better job with 5 samples compared to Redis 2.8, however most objects that are among the latest accessed are still retained by Redis 2.8. Using a sample size of 10 in Redis 3.0 the approximation is very close to the theoretical performance of Redis 3.0.
如你所見，3.0的工作比2.8更好，然而在2.8版本中，大多數最新訪問對象的仍然保留。在3.0使用樣品為10 時，效能非常接近理論上的LRU演算法。
Note that LRU is just a model to predict how likely a given key will be accessed in the future. Moreover, if your data access pattern closely resembles the power law, most of the accesses will be in the set of keys that the LRU approximated algorithm will be able to handle well.
注意：LRU僅僅是一個預測模式，給出的key很可能在未來被訪問。此外，如果你的資料訪問模式類似於冪律（線性），大多數key都可能被訪問那麼這個LRU演算法的處理就是非常好的。
In simulations we found that using a power law access pattern, the difference between true LRU and Redis approximation were minimal or non-existent.
在實戰中 ，我們發現使用冪律（線性）的訪問模式，在真正的LRU演算法和Redis的LRU演算法之間差異很小或者不存在差異。
However you can raise the sample size to 10 at the cost of some additional CPU usage in order to closely approximate true LRU, and check if this makes a difference in your cache misses rate.
你可以提升樣品大小配置到10，它將接近真正的LRU演算法，並且有不同錯過率，但是要消耗更多的CPU。
To experiment in production with different values for the sample size by using the CONFIG SET maxmemory-samples <count> command, is very simple.
在調試時使用不同的樣品大小去調試非常簡單，使用命令CONFIG SET maxmemory-samples <count> 實現。
出處：http://blog.csdn.net/column/details/redisbanli.html
