We are all familiar with redis which is one of the key-value store databases. But still, there are a few key points we may not notice when use it. I write this to record some of it.
- The ttl for a nonexist key is -2, not -1.
127.0.0.1:6379> get test
(nil)
127.0.0.1:6379> ttl test
(integer) -2
- when we reset the value of a key, its ttl will also be reset.
127.0.0.1:6379> get test
"1"
127.0.0.1:6379> ttl test
(integer) -1
127.0.0.1:6379> expire test 1000
(integer) 1
127.0.0.1:6379> ttl test
(integer) 996
127.0.0.1:6379> set test 2
OK
127.0.0.1:6379> ttl test
(integer) -1
- All redis operations implemented by single command are atomic, including the ones operating on more complex data structures, so when you use a single redis command that modifies some value, you do not have to think about concurrent access problems.
- Both sadd and lpush are variadic, it means that you can add multiple elements to a list or a set at one time.
- rpop is used to remove and return element from the tail of list. Brop is the blocking version for rpop operation.
- a reliable queue implementation with rpoplpush command.
rpoplpush/brpoplpush is an atomic operation, which can be used for
implementing a reliable messaging queue, according to the
documentation(https://redis.io/commands/rpoplpush). When used in this
scenario, the message lost problem can be handled with another client repush
the timeout element to original list. So you must avoid the message being
repeated consumed, such as using a msgid to indicate whether this message had
been processed before.
- Redis does have transaction, but it does not have rollback mechanisms which can be easily found in kinds of relational databases, such as mysql. The discard command in redis does not behave like rollback, it only abort the command queue, not rollback anything.
These are only partial, i will keep adding when having some new findings in the future.
