5 Data structures form the basis of Redis, and there are many other commands that do not have a specific data structure associated with them. We've seen some of these commands: Info,select,flushdb,multi,exec,discard,watch, and Keys. This chapter will look at some of the other important commands. Terms of Use (expiration) Redis allows you to mark the lifespan of a keyword. You can give an absolute time with a Unix timestamp form (1970 01 01), or a second-based survival time. This is a keyword-based command, so it doesn't care what kind of data structure the keyword represents. expire pages:about expire pages:about 1356933600 The first command will delete the keyword after 30 seconds, including its associated value, The second command deletes the keyword at 12 o'clock in the morning on December 31, 2012. This allows Redis to be an ideal buffer engine. With the TTL command, you can tell how long a keyword can survive. With the persist command, you can delete a keyword's lifespan. TTL pages:about persist pages:about Finally there is a special string command, and the Setex command lets you set a string value in a separate atomic command. At the same time specify a lifetime (which is more convenient than anything) Setex page:about ' hellowolrd ' equivalent to two commands combined with set page:about ' HelloWorld '; Expire Page:about 30 Publish and subscribe REDIS list data structures have Blpop and Brpop commands that can be returned from the table and delete the first (or last) element, or be blocked until an element is available for operation. This can be used to implement a simple queue In addition, Redis has first-class support for message publishing and channel subscriptions. You can open a second redis-cli window and try these features. Subscribe to a channel in the first window (a) Subscribe a it will reply to the information you have subscribed to. Now, another window, post a message to channel A: Publish a ' Hey, it'sA ' at this time, subscribe to a channel will receive a channel release message, need special boast, he can subscribe to multiple channels at the same time subscribe a B C even pingdao* very hanging! Monitoring and latency logging an excellent debugging tool, monitor. The Monitor command allows you to see what REDSI is doing. But only for debugging and development use, not for the production environment, reason: Naturally, there is a lot of extra overhead. Together with the Monitor command, Redis has a slowlog command, which is an excellent profiling tool. It will record time more than a certain number of subtle commands.
config set slowlog-log-slower-than 0
Slowlog Get 10
For each command you type, you should see 4 parameters:
1. An auto-incrementing ID
2. A Unix timestamp indicating when the command began to run
3. A subtle level of time that shows the total time the command was run
4. The command and the parameters
deferred logs are kept in memory, so running in a production environment (even with a low threshold) should not be a problem. By default, it will track the last 1024 logs SortThe Sort command is one of the most powerful commands for Redis. It allows you to sort the values in a list, collection, or a collection of categories (the category collection is sorted by tags, not members in the collection).
rpush users:leto:guesses 5 9 10 2 4 10 19 2sort users:leto:guesses
sadd friends:ghanima leto paul chani jessica alia duncansort friends:ghanima limit 0 3 desc alpha
The above command shows us how to page through a sorted record (through),
limit
how to return the result of a descending sort (through
desc
), and how to use a dictionary order instead of a numerical order (pass
alpha
).
sort
The true power of a command is its ability to sort based on a reference object. Earlier, we explained that lists, collections, and categorical collections were often used to refer to other Redis objects, and sort
commands were able to dereference those relationships and sort by potential values. For example, suppose we have a bug tracker that allows users to see all sorts of existing problems. We may use a collection data structure to track the issues being monitored:
sadd watch:leto 12339 1382 338 9338
You may have a strong feeling that you want to sort these questions by ID (which is the default sort), but we are more likely to sort these issues by the severity of the problem. To do this, we'll tell redis what pattern to use for sorting. First, in order to see a meaningful result, let's add a bit more data:
set severity:12339 3set severity:1382 2set severity:338 5set severity:9338 4
To sort these bugs in descending order by the severity of the problem, you can do this:
sort watch:leto by severity:* desc
Redis will use the values stored in the list (collection or category collection) to replace *
(pass through) in the pattern by
. This creates a keyword name, and Redis sorts it by querying its actual value.
in Redis, although you can have thousands of keywords, a relationship like the one shown above can cause some confusion. Fortunately,
sort
commands can also work in hashed data structures and their associated domains. Compared to having a large number of high-level keywords, you can take advantage of hashing:
hset bug:12339 severity 3hset bug:12339 priority 1hset bug:12339 details "{id: 12339, ....}"hset bug:1382 severity 2hset bug:1382 priority 2hset bug:1382 details "{id: 1382, ....}"hset bug:338 severity 5hset bug:338 priority 3hset bug:338 details "{id: 338, ....}"hset bug:9338 severity 4hset bug:9338 priority 2hset bug:9338 details "{id: 9338, ....}"
All things not only become easier to manage, but we can severity
sort by or priority
to tell the sort
command exactly which field to retrieve data from:
sort watch:leto by bug:*->priority get bug:*->details
The same value overrides appear, but Redis also recognizes the ->
symbol, which is used to view the fields specified in the hash. The parameters are also included get
here, and the value substitution and domain view are also performed to retrieve the details of the bug (Details field data).
For a collection that is too large, sort
the execution of the command may become slow. The good news is that the sort
output of the command can be stored:
sort watch:leto by bug:*->priority get bug:*->details store watch_by_priority:leto
expiration
sort
store
This is a wonderful combination of the ability to use commands that we've already seen, and then combine commands.
Summary
This chapter focuses on commands that are associated with non-specific data structures. As with everything else, their use depends on the situation. When you build a program or feature, you may not use features such as age, publish, or subscription or sort. But it is good to know that these functions exist. Moreover, we have only access to a number of commands. There are more commands, and when you're done digesting the book, it's worth looking at the complete list of commands.
\clearpage
Redis System Learning Four, beyond the data structure