redisdata types, and usage scenarios for each data type
(one)StringThere is actually nothing to say about this. The most common set/get operation, the value can be a String or a number. Generally, some complicated counting
Functional cache.
(2) hash The value here stores structured objects, and the more convenient thing is to operate a certain field. When the blogger is doing single sign-in,
It's using thisData structureStore user information, use cookieId as key, set 30 minutes as cache expiration time, which can simulate similarsession
effect.
(III) list Use List's data structure to perform simple message queue functions. Another thing is that you can use the lrange command to make it based on
Redis's pagination function,performanceExcellent, good user experience.
(IV) set because set piles up a bunch of sets with no duplicate values. Therefore, the global deduplication function can be used. Why not use the JVM's own set for deduplication?
Because our system is generally deployed in clusters, it is more troublesome to use the JVM's own Set. Is it necessary to do a global deduplication and create a public one?
Serve，Too troublesome。 In addition, using operations such as intersection, union, and difference can calculate common preferences, all preferences, and your own unique **
Good features**.
(V) sorted set
The sorted set has an additional weight parameter score, and the elements in the set can be arranged according to score. You can use ranking applications and get the TOP N operation. Other
In addition, referring to another article "Distributed Delay Task Scheme Analysis", the article points out that sorted set can be used to perform delay tasks. The last application is
You can do range searches.
Redis's expiration strategy and memory elimination mechanism
# maxmemory-policy volatile-lru
This configuration is the memory elimination strategy (what, you haven't? Reflect on yourself) 1) noeviction: When the memory is not enough to accommodate the newly written data
, a new write operation will report an error. It probably no one uses it. 2) allkeys-lru: When memory is insufficient to accommodate newly written data, remove the most in the key space
The least used key. It is recommended to use this, currently the project is using this. 3) allkeys-random: When the memory is insufficient to accommodate the newly written data,
In space, a key is removed randomly. No one should use it. If you don’t delete it, use the key at least and delete it randomly. 4) volatile-lru: When the memory is insufficient
When new data is written, the key space with the expiration time is set, the least recently used key is removed. In this case, redis is used as a cache and
Used only when doing persistent storage. Not recommended 5) volatile-random: When the memory is insufficient to accommodate the newly written data, the key to set the expiration time
In space, a key is removed randomly. Still not recommended 6) volatile-ttl: When the memory is insufficient to accommodate the newly written data, the key to set the expiration time
In the space, keys with earlier expiration time will be removed first. Not recommended ps: If the expire key is not set, the prerequisites are not met
(prerequisites); Then the behavior of volatile-lru, volatile-random and volatile-ttl policies is basically the same as noeviction (not deleted).