I decided the tidy up the redis docs and I wrote some notes for myself on the way:
Redis as pure cache:
Setting maxmemory and maxmemory-policy to 'allkeys-lru' will make redis auto expire all keys, starting with the oldest first, without any need for manually setting EXPIRE. Perfect when used just for caching.
Lexicographical sorted sets:
Elements stored under the same key in a sorted set can be retrieved lexicographicaly, powerful for string searching. If you need to normalise a string while retaining the original, you can store them together. E.g. 'banana:Banana' to ignore case while searching but preserve the case of the result.
Getting distributed locks safely is more complicated than it first appears, with a few edge cases that may cause locks to not be released, etc. Redlock has been written as a general solution, and has a large number of implementations in different languages.
- Only returns extra info for tty, raw for all others
- Can be set to repeat commands using -r
- '--stat' produces continuous stats
- Can scan for big keys with --big-keys (can be used in production)
- Supports pub/sub directly
- Can echo all redis commands using MONITOR
- Can show redis latency and intrinsic latency
- Can grab RDB from server
- Can simulate LRU load with 80/20 access rates
- Slaves can chain (slave -> slave replication, doesn't replicate local slave writes)
- Master can use diskless replication, sends rdb directly to slave from mem.
- Master can be set to reject writes unless a certain number of slaves are available.
- Clients can subscribe to sentinel pub/sub for events.
- Sentinels never forget seen sentinels
- Slaves can be given promotion priority to avoid or prefer them becoming masters.
- DISCARD cancels the current queue
- WATCH will cancel EXEC if the watched key has changed since the WATCH command was issued.
- SUNION can take a long time for large/many sets.
- The Lua debugger can be used to step through lua scripts line by line.
- Total memory used can exceed maxmemory briefly, could be by a large amount but only if setting a large key.
- If you are storing a lot of objects in a set, split the key apart and use the first part as a hash key instead -> more memory efficient. ('test1234' -> 'test1' '234'
- Publishing ignores database members
- Subscribing supports pattern matching
- Clients may receive duplicated messages if they have multiple subscriptions
- Keyspace notifications can report all commands affecting a key, all keys receiving lpush, and all keys expiring in db 0.
- Expired keys only fire when they are actually expired by redis, not the exact time they should expire.