Redis implementation cache, you should understand what ideas!

Scenario one: Similar to Weibo, realizes attention and is focused on features.

Ideas:

Use two collection type keys for each user to store users who are interested in others and who are concerned by that user. When user A is concerned about User B, take two steps:

Sadd user:a B

Sadd user:b A

Question 1:

To complete a user-focused operation, two-step code is required, and for the first time, User a focuses on B and becomes a fan of B. While the second step, for some reason, is not executed or executed successfully, then a does not know that B is concerned about his

Transaction:

The principle of a transaction is to send a command for a transaction to Redis, and then let Redis execute the commands sequentially.

In a transaction, either the execution succeeds or neither is executed

The multi command tells Redis to prepare for the transaction, staging it first, and not executing it. Then send the commands that need to be executed together, finally exec ends the transaction, and Redis executes the command in turn

If, for some reason, Redis is broken before the EXEC command executes, Redis empties the transaction queue.

Question 2:

Sometimes, we need not only through the transaction to deal with some of the actions that must be successful together, such as bank transfer, from the bank card 1 to the bank card 2, must be all together successfully, can not say from the bank card 1 deducted the money, not into the bank card 2 accounts, both actions such as to complete. There are times when we have to do it together and we need to do the next step based on the results of one of the actions.

Watch command

Watch, another command in the transaction. Monitoring one or more keys, once one of the keys has been modified or deleted, then the transaction will not be executed until the exec ends.

Watch monitors Key1, and then modifies Key1, so the set command in the transaction does not execute

Scenario Two: Time-limited activity, cache, verification code invalidation

In the actual development, often encounter time-limited activities, mailbox failure times, verification code failure time, and other scenarios, these data need to be effective in a certain time, expired deleted, if you save this data in a relational database, each check will need to query data, compare time, and then set the data to fail, or delete. In Redis, you can set the expiration time by expire and automatically delete it.

Expire set the failure time, time unit seconds. Successful return 1 if key does not exist return 0

When key does not exist, returns-2. Returns 1 when key exists but no remaining lifetime is set.

Note: Before Redis 2.8, when key does not exist, or key does not set the remaining lifetime, the command returns-1

Implementing caching

In order to provide the load capacity of the Web site, it is necessary to cache the results of an operation that has a high frequency of access, which is computationally expensive or expensive for IO resources, and sets an expiration time. Each time the user accesses, check the existence of the key, if there is a direct fetch of the element and return, if it does not exist, after a series of calculations and cache the results, set the expiration time, returned to the user

Problem:

The implementation of this cache, obviously there are two problems, the first is that the cache is present in the content, if a large number of use of the cache will lead to redis stained memory, on the other hand, in order to prevent redis stained memory and set the expiration time of the key, if the setting time is too short, Can lead to a cache hit rate too low and a lot of content wasted.

How to use:

In development, it is difficult to set the lifetime of a key reasonably, so you can limit the maximum memory used by Redis and have Redis follow certain rules to remove unwanted keys.

Specific ways to modify the maxmemory parameters of the configuration file

If Redis is installed under OS x via homebrew, the configuration file is/usr/local/etc/redis.conf

After limiting the maximum redis memory, when this memory is exceeded, it will be based on the Maxmemory-policy

The specified parameter removes the unwanted key. When this parameter is set to ALLKEYS-LRU, Redis continuously deletes the least recently used key in the database until the current memory size limit is met once the Redis memory exceeds the limit value

Redis implementation cache, you should understand what ideas!