Skip to content
This repository
Browse code

The universe is 80 characters wide...

  • Loading branch information...
commit 066c91d4f7383a81cf4c07d8e5c4dd75372ca45f 1 parent 3e542b3
Pieter Noordhuis pietern authored

Showing 93 changed files with 754 additions and 618 deletions. Show diff stats Hide diff stats

  1. +39 0 Rakefile
  2. +16 10 commands/append.md
  3. +6 7 commands/auth.md
  4. +8 4 commands/bgrewriteaof.md
  5. +6 5 commands/bgsave.md
  6. +20 21 commands/bitcount.md
  7. +14 11 commands/bitop.md
  8. +14 16 commands/blpop.md
  9. +8 7 commands/config get.md
  10. +10 10 commands/config set.md
  11. +5 7 commands/decr.md
  12. +4 5 commands/decrby.md
  13. +1 1  commands/del.md
  14. +7 3 commands/dump.md
  15. +148 147 commands/eval.md
  16. +3 5 commands/exec.md
  17. +45 38 commands/expire.md
  18. +2 1  commands/expireat.md
  19. +2 1  commands/flushall.md
  20. +3 3 commands/get.md
  21. +2 2 commands/hdel.md
  22. +2 2 commands/hgetall.md
  23. +1 2  commands/hincrby.md
  24. +9 3 commands/hincrbyfloat.md
  25. +2 2 commands/hmget.md
  26. +3 3 commands/hmset.md
  27. +2 2 commands/hset.md
  28. +25 24 commands/incr.md
  29. +4 5 commands/incrby.md
  30. +12 5 commands/incrbyfloat.md
  31. +2 2 commands/info.md
  32. +3 3 commands/keys.md
  33. +4 4 commands/lastsave.md
  34. +5 5 commands/lindex.md
  35. +2 2 commands/linsert.md
  36. +3 3 commands/llen.md
  37. +10 6 commands/lpush.md
  38. +3 3 commands/lpushx.md
  39. +6 7 commands/lrange.md
  40. +5 5 commands/lrem.md
  41. +4 4 commands/ltrim.md
  42. +3 3 commands/mget.md
  43. +25 10 commands/migrate.md
  44. +9 9 commands/monitor.md
  45. +2 2 commands/move.md
  46. +1 1  commands/mset.md
  47. +2 2 commands/msetnx.md
  48. +2 2 commands/multi.md
  49. +5 2 commands/object.md
  50. +3 1 commands/persist.md
  51. +3 1 commands/pttl.md
  52. +5 5 commands/punsubscribe.md
  53. +2 2 commands/renamenx.md
  54. +4 2 commands/restore.md
  55. +16 11 commands/rpoplpush.md
  56. +10 6 commands/rpush.md
  57. +3 3 commands/rpushx.md
  58. +3 3 commands/sadd.md
  59. +10 3 commands/save.md
  60. +8 3 commands/script exists.md
  61. +2 1  commands/script flush.md
  62. +12 5 commands/script kill.md
  63. +10 5 commands/script load.md
  64. +2 2 commands/sdiffstore.md
  65. +2 2 commands/select.md
  66. +1 1  commands/setex.md
  67. +11 14 commands/setnx.md
  68. +8 8 commands/setrange.md
  69. +6 5 commands/shutdown.md
  70. +2 2 commands/sinter.md
  71. +10 10 commands/slaveof.md
  72. +19 20 commands/slowlog.md
  73. +2 3 commands/smove.md
  74. +22 21 commands/sort.md
  75. +2 2 commands/spop.md
  76. +1 1  commands/srem.md
  77. +2 2 commands/strlen.md
  78. +2 2 commands/subscribe.md
  79. +1 2  commands/sunion.md
  80. +4 2 commands/time.md
  81. +3 3 commands/ttl.md
  82. +3 3 commands/type.md
  83. +5 5 commands/unsubscribe.md
  84. +2 1  commands/watch.md
  85. +7 4 commands/zadd.md
  86. +2 2 commands/zcard.md
  87. +4 4 commands/zcount.md
  88. +5 5 commands/zinterstore.md
  89. +3 3 commands/zrange.md
  90. +8 8 commands/zrangebyscore.md
  91. +2 1  commands/zrem.md
  92. +2 1  commands/zrevrangebyscore.md
  93. +1 1  commands/zunionstore.md
39 Rakefile
@@ -39,3 +39,42 @@ task :spellcheck do
39 39 puts "#{file}: #{words.uniq.sort.join(" ")}" if words.any?
40 40 end
41 41 end
  42 +
  43 +namespace :format do
  44 +
  45 + def format(file)
  46 + return unless File.exist?(file)
  47 +
  48 + STDOUT.print "formatting #{file}..."
  49 + STDOUT.flush
  50 +
  51 + matcher = /^(?:\A|\r?\n)((?:[a-zA-Z].+?\r?\n)+)/m
  52 + body = File.read(file).gsub(matcher) do |match|
  53 + formatted = nil
  54 +
  55 + IO.popen("par p0s0w80", "r+") do |io|
  56 + io.puts match
  57 + io.close_write
  58 + formatted = io.read
  59 + end
  60 +
  61 + formatted
  62 + end
  63 +
  64 + File.open(file, "w") do |f|
  65 + f.print body
  66 + end
  67 +
  68 + STDOUT.puts
  69 + end
  70 +
  71 + task :file, :path do |t, args|
  72 + format(args[:path])
  73 + end
  74 +
  75 + task :all do
  76 + Dir["commands/*.md"].each do |path|
  77 + format(path)
  78 + end
  79 + end
  80 +end
26 commands/append.md
Source Rendered
... ... @@ -1,6 +1,6 @@
1   -If `key` already exists and is a string, this command appends the `value` at
2   -the end of the string. If `key` does not exist it is created and set as an
3   -empty string, so `APPEND` will be similar to `SET` in this special case.
  1 +If `key` already exists and is a string, this command appends the `value` at the
  2 +end of the string. If `key` does not exist it is created and set as an empty
  3 +string, so `APPEND` will be similar to `SET` in this special case.
4 4
5 5 @return
6 6
@@ -16,9 +16,9 @@ empty string, so `APPEND` will be similar to `SET` in this special case.
16 16
17 17 ## Pattern: Time series
18 18
19   -the `APPEND` command can be used to create a very compact representation of
20   -a list of fixed-size samples, usually referred as *time series*.
21   -Every time a new sample arrives we can store it using the command
  19 +the `APPEND` command can be used to create a very compact representation of a
  20 +list of fixed-size samples, usually referred as *time series*. Every time a new
  21 +sample arrives we can store it using the command
22 22
23 23 APPEND timeseries "fixed-size sample"
24 24
@@ -28,12 +28,18 @@ Accessing individual elements in the time series is not hard:
28 28 * `GETRANGE` allows for random access of elements. If our time series have an associated time information we can easily implement a binary search to get range combining `GETRANGE` with the Lua scripting engine available in Redis 2.6.
29 29 * `SETRANGE` can be used to overwrite an existing time serie.
30 30
31   -The limitations of this pattern is that we are forced into an append-only mode of operation, there is no way to cut the time series to a given size easily because Redis currently lacks a command able to trim string objects. However the space efficiency of time series stored in this way is remarkable.
  31 +The limitations of this pattern is that we are forced into an append-only mode
  32 +of operation, there is no way to cut the time series to a given size easily
  33 +because Redis currently lacks a command able to trim string objects. However the
  34 +space efficiency of time series stored in this way is remarkable.
32 35
33   -Hint: it is possible to switch to a different key based on the current Unix time, in this way it is possible to have just a relatively small amount of samples per key, to avoid dealing with very big keys, and to make this pattern more
34   -friendly to be distributed across many Redis instances.
  36 +Hint: it is possible to switch to a different key based on the current Unix
  37 +time, in this way it is possible to have just a relatively small amount of
  38 +samples per key, to avoid dealing with very big keys, and to make this pattern
  39 +more friendly to be distributed across many Redis instances.
35 40
36   -An example sampling the temperature of a sensor using fixed-size strings (using a binary format is better in real implementations).
  41 +An example sampling the temperature of a sensor using fixed-size strings (using
  42 +a binary format is better in real implementations).
37 43
38 44 @cli
39 45 APPEND ts "0043"
13 commands/auth.md
Source Rendered
... ... @@ -1,11 +1,10 @@
1   -Request for authentication in a password protected Redis server.
2   -Redis can be instructed to require a password before allowing clients
3   -to execute commands. This is done using the `requirepass` directive in the
4   -configuration file.
  1 +Request for authentication in a password protected Redis server. Redis can be
  2 +instructed to require a password before allowing clients to execute commands.
  3 +This is done using the `requirepass` directive in the configuration file.
5 4
6   -If `password` matches the password in the configuration file, the server replies with
7   -the `OK` status code and starts accepting commands.
8   -Otherwise, an error is returned and the clients needs to try a new password.
  5 +If `password` matches the password in the configuration file, the server replies
  6 +with the `OK` status code and starts accepting commands. Otherwise, an error is
  7 +returned and the clients needs to try a new password.
9 8
10 9 **Note**: because of the high performance nature of Redis, it is possible to try
11 10 a lot of passwords in parallel in very short time, so make sure to generate
12 commands/bgrewriteaof.md
Source Rendered
... ... @@ -1,17 +1,21 @@
1   -Instruct Redis to start an [Append Only File][aof] rewrite process. The rewrite will create a small optimized version of the current Append Only File.
  1 +Instruct Redis to start an [Append Only File][aof] rewrite process. The rewrite
  2 +will create a small optimized version of the current Append Only File.
2 3
3 4 [aof]: /topics/persistence#append-only-file
4 5
5 6 If `BGREWRITEAOF` fails, no data gets lost as the old AOF will be untouched.
6 7
7   -The rewrite will be only triggered by Redis if there is not already a background process doing persistence. Specifically:
  8 +The rewrite will be only triggered by Redis if there is not already a background
  9 +process doing persistence. Specifically:
8 10
9 11 * If a Redis child is creating a snapshot on disk, the AOF rewrite is *scheduled* but not started until the saving child producing the RDB file terminates. In this case the `BGREWRITEAOF` will still return an OK code, but with an appropriate message. You can check if an AOF rewrite is scheduled looking at the `INFO` command starting from Redis 2.6.
10 12 * If an AOF rewrite is already in progress the command returns an error and no AOF rewrite will be scheduled for a later time.
11 13
12   -Since Redis 2.4 the AOF rewrite is automatically triggered by Redis, however the `BGREWRITEAOF` command can be used to trigger a rewrite at any time.
  14 +Since Redis 2.4 the AOF rewrite is automatically triggered by Redis, however the
  15 +`BGREWRITEAOF` command can be used to trigger a rewrite at any time.
13 16
14   -Please refer to the [persistence documentation][persistence] for detailed information.
  17 +Please refer to the [persistence documentation][persistence] for detailed
  18 +information.
15 19
16 20 [persistence]: /topics/persistence
17 21
11 commands/bgsave.md
Source Rendered
... ... @@ -1,11 +1,12 @@
1 1
2 2
3   -Save the DB in background. The OK code is immediately returned.
4   -Redis forks, the parent continues to server the clients, the child
5   -saves the DB on disk then exit. A client my be able to check if the
6   -operation succeeded using the `LASTSAVE` command.
  3 +Save the DB in background. The OK code is immediately returned. Redis forks,
  4 +the parent continues to server the clients, the child saves the DB on disk
  5 +then exit. A client my be able to check if the operation succeeded using the
  6 +`LASTSAVE` command.
7 7
8   -Please refer to the [persistence documentation][persistence] for detailed information.
  8 +Please refer to the [persistence documentation][persistence] for detailed
  9 +information.
9 10
10 11 [persistence]: /topics/persistence
11 12
41 commands/bitcount.md
Source Rendered
@@ -4,12 +4,11 @@ By default all the bytes contained in the string are examined. It is possible
4 4 to specify the counting operation only in an interval passing the additional
5 5 arguments *start* and *end*.
6 6
7   -Like for the `GETRANGE` command start and end can contain negative values
8   -in order to index bytes starting from the end of the string, where -1 is the
9   -last byte, -2 is the penultimate, and so forth.
  7 +Like for the `GETRANGE` command start and end can contain negative values in
  8 +order to index bytes starting from the end of the string, where -1 is the last
  9 +byte, -2 is the penultimate, and so forth.
10 10
11   -Non existing keys are treated as empty strings, so the command will return
12   -zero.
  11 +Non existing keys are treated as empty strings, so the command will return zero.
13 12
14 13 @return
15 14
@@ -28,32 +27,32 @@ The number of bits set to 1.
28 27 ## Pattern: real time metrics using bitmaps
29 28
30 29 Bitmaps are a very space efficient representation of certain kinds of
31   -information. One example is a web application that needs the history
32   -of user visits, so that for instance it is possible to determine what
33   -users are good targets of beta features, or for any other purpose.
  30 +information. One example is a web application that needs the history of user
  31 +visits, so that for instance it is possible to determine what users are good
  32 +targets of beta features, or for any other purpose.
34 33
35 34 Using the `SETBIT` command this is trivial to accomplish, identifying every
36   -day with a small progressive integer. For instance day 0 is the first day
37   -the application was put online, day 1 the next day, and so forth.
  35 +day with a small progressive integer. For instance day 0 is the first day the
  36 +application was put online, day 1 the next day, and so forth.
38 37
39   -Every time an user performs a page view, the application can register that
40   -in the current day the user visited the web site using the `SETBIT` command
41   -setting the bit corresponding to the current day.
  38 +Every time an user performs a page view, the application can register that in
  39 +the current day the user visited the web site using the `SETBIT` command setting
  40 +the bit corresponding to the current day.
42 41
43   -Later it will be trivial to know the number of single days the user visited
44   -the web site simply calling the `BITCOUNT` command against the bitmap.
  42 +Later it will be trivial to know the number of single days the user visited the
  43 +web site simply calling the `BITCOUNT` command against the bitmap.
45 44
46   -A similar pattern where user IDs are used instead of days is described
47   -in the article called "[Fast easy realtime metrics using Redis bitmaps][bitmaps]".
  45 +A similar pattern where user IDs are used instead of days is described in the
  46 +article called "[Fast easy realtime metrics using Redis bitmaps][bitmaps]".
48 47
49 48 [bitmaps]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
50 49
51 50 ## Performance considerations
52 51
53   -In the above example of counting days, even after 10 years the application
54   -is online we still have just `365*10` bits of data per user, that is
55   -just 456 bytes per user. With this amount of data `BITCOUNT` is still as fast
56   -as any other O(1) Redis command like `GET` or `INCR`.
  52 +In the above example of counting days, even after 10 years the application is
  53 +online we still have just `365*10` bits of data per user, that is just 456 bytes
  54 +per user. With this amount of data `BITCOUNT` is still as fast as any other O(1)
  55 +Redis command like `GET` or `INCR`.
57 56
58 57 When the bitmap is big, there are two alternatives:
59 58
25 commands/bitop.md
Source Rendered
... ... @@ -1,7 +1,8 @@
1   -Perform a bitwise operation between multiple keys (containing string
2   -values) and store the result in the destination key.
  1 +Perform a bitwise operation between multiple keys (containing string values) and
  2 +store the result in the destination key.
3 3
4   -The `BITOP` command supports four bitwise operations: **AND**, **OR**, **XOR** and **NOT**, thus the valid forms to call the command are:
  4 +The `BITOP` command supports four bitwise operations: **AND**, **OR**, **XOR**
  5 +and **NOT**, thus the valid forms to call the command are:
5 6
6 7 + BITOP AND *destkey srckey1 srckey2 srckey3 ... srckeyN*
7 8 + BITOP OR *destkey srckey1 srckey2 srckey3 ... srckeyN*
@@ -15,9 +16,9 @@ The result of the operation is always stored at *destkey*.
15 16
16 17 ## Handling of strings with different lengths
17 18
18   -When an operation is performed between strings having different lengths, all
19   -the strings shorter than the longest string in the set are treated as if
20   -they were zero-padded up to the length of the longest string.
  19 +When an operation is performed between strings having different lengths, all the
  20 +strings shorter than the longest string in the set are treated as if they were
  21 +zero-padded up to the length of the longest string.
21 22
22 23 The same holds true for non-existing keys, that are considered as a stream of
23 24 zero bytes up to the length of the longest string.
@@ -26,7 +27,8 @@ zero bytes up to the length of the longest string.
26 27
27 28 @integer-reply
28 29
29   -The size of the string stored into the destination key, that is equal to the size of the longest input string.
  30 +The size of the string stored into the destination key, that is equal to the
  31 +size of the longest input string.
30 32
31 33 @examples
32 34
@@ -41,7 +43,8 @@ The size of the string stored into the destination key, that is equal to the siz
41 43 `BITOP` is a good complement to the pattern documented in the `BITCOUNT` command documentation. Different bitmaps can be combined in order to obtain a target
42 44 bitmap where to perform the population counting operation.
43 45
44   -See the article called "[Fast easy realtime metrics using Redis bitmaps][bitmaps]" for an interesting use cases.
  46 +See the article called "[Fast easy realtime metrics using Redis
  47 +bitmaps][bitmaps]" for an interesting use cases.
45 48
46 49 [bitmaps]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
47 50
@@ -50,6 +53,6 @@ See the article called "[Fast easy realtime metrics using Redis bitmaps][bitmaps
50 53 `BITOP` is a potentially slow command as it runs in O(N) time.
51 54 Care should be taken when running it against long input strings.
52 55
53   -For real time metrics and statistics involving large inputs a good approach
54   -is to use a slave (with read-only option disabled) where to perform the
55   -bit-wise operations without blocking the master instance.
  56 +For real time metrics and statistics involving large inputs a good approach is
  57 +to use a slave (with read-only option disabled) where to perform the bit-wise
  58 +operations without blocking the master instance.
30 commands/blpop.md
Source Rendered
@@ -21,15 +21,14 @@ that order).
21 21
22 22 ## Blocking behavior
23 23
24   -If none of the specified keys exist, `BLPOP` blocks
25   -the connection until another client performs an `LPUSH` or `RPUSH` operation
26   -against one of the keys.
  24 +If none of the specified keys exist, `BLPOP` blocks the connection until another
  25 +client performs an `LPUSH` or `RPUSH` operation against one of the keys.
27 26
28 27 Once new data is present on one of the lists, the client returns with the name
29 28 of the key unblocking it and the popped value.
30 29
31   -When `BLPOP` causes a client to block and a non-zero timeout is specified, the
32   -client will unblock returning a `nil` multi-bulk value when the specified
  30 +When `BLPOP` causes a client to block and a non-zero timeout is specified,
  31 +the client will unblock returning a `nil` multi-bulk value when the specified
33 32 timeout has expired without a push operation against at least one of the
34 33 specified keys.
35 34
@@ -38,9 +37,9 @@ be used to block indefinitely.
38 37
39 38 ## Multiple clients blocking for the same keys
40 39
41   -Multiple clients can block for the same key. They are put into
42   -a queue, so the first to be served will be the one that started to wait
43   -earlier, in a first-`!BLPOP` first-served fashion.
  40 +Multiple clients can block for the same key. They are put into a queue, so
  41 +the first to be served will be the one that started to wait earlier, in a
  42 +first-`!BLPOP` first-served fashion.
44 43
45 44 ## `!BLPOP` inside a `!MULTI`/`!EXEC` transaction
46 45
@@ -51,8 +50,8 @@ execute the block atomically, which in turn does not allow other clients to
51 50 perform a push operation.
52 51
53 52 The behavior of `BLPOP` inside `MULTI`/`EXEC` when the list is empty is to
54   -return a `nil` multi-bulk reply, which is the same thing that happens when the
55   -timeout is reached. If you like science fiction, think of time flowing at
  53 +return a `nil` multi-bulk reply, which is the same thing that happens when
  54 +the timeout is reached. If you like science fiction, think of time flowing at
56 55 infinite speed inside a `MULTI`/`EXEC` block.
57 56
58 57 @return
@@ -76,12 +75,11 @@ infinite speed inside a `MULTI`/`EXEC` block.
76 75 ## Pattern: Event notification
77 76
78 77 Using blocking list operations it is possible to mount different blocking
79   -primitives. For instance for some application you may need to block
80   -waiting for elements into a Redis Set, so that as far as a new element is
81   -added to the Set, it is possible to retrieve it without resort to polling.
82   -This would require a blocking version of `SPOP` that is
83   -not available, but using blocking list operations we can easily accomplish
84   -this task.
  78 +primitives. For instance for some application you may need to block waiting for
  79 +elements into a Redis Set, so that as far as a new element is added to the Set,
  80 +it is possible to retrieve it without resort to polling. This would require
  81 +a blocking version of `SPOP` that is not available, but using blocking list
  82 +operations we can easily accomplish this task.
85 83
86 84 The consumer will do:
87 85
15 commands/config get.md
Source Rendered
... ... @@ -1,7 +1,7 @@
1 1 The `CONFIG GET` command is used to read the configuration parameters of a
2   -running Redis server. Not all the configuration parameters are
3   -supported in Redis 2.4, while Redis 2.6 can read the whole configuration of
4   -a server using this command.
  2 +running Redis server. Not all the configuration parameters are supported in
  3 +Redis 2.4, while Redis 2.6 can read the whole configuration of a server using
  4 +this command.
5 5
6 6 The symmetric command used to alter the configuration at run time is
7 7 `CONFIG SET`.
@@ -22,7 +22,8 @@ You can obtain a list of all the supported configuration parameters typing
22 22 `CONFIG GET *` in an open `redis-cli` prompt.
23 23
24 24 All the supported parameters have the same meaning of the equivalent
25   -configuration parameter used in the [redis.conf][conf] file, with the following important differences:
  25 +configuration parameter used in the [redis.conf][conf] file, with the following
  26 +important differences:
26 27
27 28 [conf]: http://github.com/antirez/redis/raw/2.2/redis.conf
28 29
@@ -34,9 +35,9 @@ For instance what in `redis.conf` looks like:
34 35 save 900 1
35 36 save 300 10
36 37
37   -that means, save after 900 seconds if there is at least 1 change to the
38   -dataset, and after 300 seconds if there are at least 10 changes to the
39   -datasets, will be reported by `CONFIG GET` as "900 1 300 10".
  38 +that means, save after 900 seconds if there is at least 1 change to the dataset,
  39 +and after 300 seconds if there are at least 10 changes to the datasets, will be
  40 +reported by `CONFIG GET` as "900 1 300 10".
40 41
41 42 @return
42 43
20 commands/config set.md
Source Rendered
@@ -2,17 +2,17 @@ The `CONFIG SET` command is used in order to reconfigure the server at run time
2 2 without the need to restart Redis. You can change both trivial parameters or
3 3 switch from one to another persistence option using this command.
4 4
5   -The list of configuration parameters supported by `CONFIG SET` can be
6   -obtained issuing a `CONFIG GET *` command, that is the symmetrical command
7   -used to obtain information about the configuration of a running
8   -Redis instance.
  5 +The list of configuration parameters supported by `CONFIG SET` can be obtained
  6 +issuing a `CONFIG GET *` command, that is the symmetrical command used to obtain
  7 +information about the configuration of a running Redis instance.
9 8
10 9 All the configuration parameters set using `CONFIG SET` are immediately loaded
11 10 by Redis that will start acting as specified starting from the next command
12 11 executed.
13 12
14 13 All the supported parameters have the same meaning of the equivalent
15   -configuration parameter used in the [redis.conf][conf] file, with the following important differences:
  14 +configuration parameter used in the [redis.conf][conf] file, with the following
  15 +important differences:
16 16
17 17 [conf]: http://github.com/antirez/redis/raw/2.2/redis.conf
18 18
@@ -24,9 +24,9 @@ For instance what in `redis.conf` looks like:
24 24 save 900 1
25 25 save 300 10
26 26
27   -that means, save after 900 seconds if there is at least 1 change to the
28   -dataset, and after 300 seconds if there are at least 10 changes to the
29   -datasets, should be set using `CONFIG SET` as "900 1 300 10".
  27 +that means, save after 900 seconds if there is at least 1 change to the dataset,
  28 +and after 300 seconds if there are at least 10 changes to the datasets, should
  29 +be set using `CONFIG SET` as "900 1 300 10".
30 30
31 31 It is possible to switch persistence from RDB snapshotting to append only file
32 32 (and the other way around) using the `CONFIG SET` command. For more information
@@ -40,8 +40,8 @@ In general what you should know is that setting the `appendonly` parameter to
40 40 commands on the append only file, thus obtaining exactly the same effect of
41 41 a Redis server that started with AOF turned on since the start.
42 42
43   -You can have both the AOF enabled with RDB snapshotting if you want, the
44   -two options are not mutually exclusive.
  43 +You can have both the AOF enabled with RDB snapshotting if you want, the two
  44 +options are not mutually exclusive.
45 45
46 46 @return
47 47
12 commands/decr.md
Source Rendered
... ... @@ -1,11 +1,9 @@
1   -Decrements the number stored at `key` by one.
2   -If the key does not exist, it is set to `0` before performing the operation. An
3   -error is returned if the key contains a value of the wrong type or contains a
4   -string that can not be represented as integer. This operation is limited to **64
5   -bit signed integers**.
  1 +Decrements the number stored at `key` by one. If the key does not exist, it
  2 +is set to `0` before performing the operation. An error is returned if the
  3 +key contains a value of the wrong type or contains a string that can not be
  4 +represented as integer. This operation is limited to **64 bit signed integers**.
6 5
7   -See `INCR` for extra information on increment/decrement
8   -operations.
  6 +See `INCR` for extra information on increment/decrement operations.
9 7
10 8 @return
11 9
9 commands/decrby.md
Source Rendered
... ... @@ -1,8 +1,7 @@
1   -Decrements the number stored at `key` by `decrement`.
2   -If the key does not exist, it is set to `0` before performing the operation. An
3   -error is returned if the key contains a value of the wrong type or contains a
4   -string that can not be represented as integer. This operation is limited to 64
5   -bit signed integers.
  1 +Decrements the number stored at `key` by `decrement`. If the key does not exist,
  2 +it is set to `0` before performing the operation. An error is returned if the
  3 +key contains a value of the wrong type or contains a string that can not be
  4 +represented as integer. This operation is limited to 64 bit signed integers.
6 5
7 6 See `INCR` for extra information on increment/decrement operations.
8 7
2  commands/del.md
Source Rendered
... ... @@ -1,4 +1,4 @@
1   -Removes the specified keys. A key is ignored if it does not exist.
  1 +Removes the specified keys. A key is ignored if it does not exist.
2 2
3 3 @return
4 4
10 commands/dump.md
Source Rendered
... ... @@ -1,12 +1,16 @@
1   -Serialize the value stored at key in a Redis-specific format and return it to the user. The returned value can be synthesized back into a Redis key using the `RESTORE` command.
  1 +Serialize the value stored at key in a Redis-specific format and return it to
  2 +the user. The returned value can be synthesized back into a Redis key using the
  3 +`RESTORE` command.
2 4
3   -The serialization format is opaque and non-standard, however it has a few semantical characteristics:
  5 +The serialization format is opaque and non-standard, however it has a few
  6 +semantical characteristics:
4 7
5 8 * It contains a 64bit checksum that is used to make sure errors will be detected. The `RESTORE` command makes sure to check the checksum before synthesizing a key using the serialized value.
6 9 * Values are encoded in the same format used by RDB.
7 10 * An RDB version is encoded inside the serialized value, so that different Redis versions with incompatible RDB formats will refuse to process the serialized value.
8 11
9   -The serialized value does NOT contain expire information. In order to capture the time to live of the current value the `PTTL` command should be used.
  12 +The serialized value does NOT contain expire information. In order to capture
  13 +the time to live of the current value the `PTTL` command should be used.
10 14
11 15 If `key` does not exist a nil bulk reply is returned.
12 16
295 commands/eval.md
Source Rendered
@@ -3,17 +3,18 @@
3 3 `EVAL` and `EVALSHA` are used to evaluate scripts using the Lua interpreter
4 4 built into Redis starting from version 2.6.0.
5 5
6   -The first argument of `EVAL` is a Lua 5.1 script. The script does not need
7   -to define a Lua function (and should not). It is just a Lua program that will run in the context of the Redis server.
  6 +The first argument of `EVAL` is a Lua 5.1 script. The script does not need to
  7 +define a Lua function (and should not). It is just a Lua program that will run
  8 +in the context of the Redis server.
8 9
9   -The second argument of `EVAL` is the number of arguments that follows
10   -the script (starting from the third argument) that represent Redis key names.
11   -This arguments can be accessed by Lua using the `KEYS` global variable in
12   -the form of a one-based array (so `KEYS[1]`, `KEYS[2]`, ...).
  10 +The second argument of `EVAL` is the number of arguments that follows the
  11 +script (starting from the third argument) that represent Redis key names. This
  12 +arguments can be accessed by Lua using the `KEYS` global variable in the form of
  13 +a one-based array (so `KEYS[1]`, `KEYS[2]`, ...).
13 14
14   -All the additional arguments should not represent key names and can
15   -be accessed by Lua using the `ARGV` global variable, very similarly to
16   -what happens with keys (so `ARGV[1]`, `ARGV[2]`, ...).
  15 +All the additional arguments should not represent key names and can be accessed
  16 +by Lua using the `ARGV` global variable, very similarly to what happens with
  17 +keys (so `ARGV[1]`, `ARGV[2]`, ...).
17 18
18 19 The following example should clarify what stated above:
19 20
@@ -23,12 +24,12 @@ The following example should clarify what stated above:
23 24 3) "first"
24 25 4) "second"
25 26
26   -Note: as you can see Lua arrays are returned as Redis multi bulk
27   -replies, that is a Redis return type that your client library will
28   -likely convert into an Array type in your programming language.
  27 +Note: as you can see Lua arrays are returned as Redis multi bulk replies, that
  28 +is a Redis return type that your client library will likely convert into an
  29 +Array type in your programming language.
29 30
30   -It is possible to call Redis commands from a Lua script using two different
31   -Lua functions:
  31 +It is possible to call Redis commands from a Lua script using two different Lua
  32 +functions:
32 33
33 34 * `redis.call()`
34 35 * `redis.pcall()`
@@ -39,44 +40,47 @@ error that in turn will force `EVAL` to return an error to the command caller,
39 40 while `redis.pcall` will trap the error returning a Lua table representing the
40 41 error.
41 42
42   -The arguments of the `redis.call()` and `redis.pcall()` functions are simply
43   -all the arguments of a well formed Redis command:
  43 +The arguments of the `redis.call()` and `redis.pcall()` functions are simply all
  44 +the arguments of a well formed Redis command:
44 45
45 46 > eval "return redis.call('set','foo','bar')" 0
46 47 OK
47 48
48   -The above script actually sets the key `foo` to the string `bar`.
49   -However it violates the `EVAL` command semantics as all the keys that the
50   -script uses should be passed using the KEYS array, in the following way:
  49 +The above script actually sets the key `foo` to the string `bar`. However it
  50 +violates the `EVAL` command semantics as all the keys that the script uses
  51 +should be passed using the KEYS array, in the following way:
51 52
52 53 > eval "return redis.call('set',KEYS[1],'bar')" 1 foo
53 54 OK
54 55
55   -The reason for passing keys in the proper way is that, before of `EVAL` all
56   -the Redis commands could be analyzed before execution in order to
57   -establish what are the keys the command will operate on.
  56 +The reason for passing keys in the proper way is that, before of `EVAL` all the
  57 +Redis commands could be analyzed before execution in order to establish what are
  58 +the keys the command will operate on.
58 59
59   -In order for this to be true for `EVAL` also keys must be explicit.
60   -This is useful in many ways, but especially in order to make sure Redis Cluster
61   -is able to forward your request to the appropriate cluster node (Redis
62   -Cluster is a work in progress, but the scripting feature was designed
63   -in order to play well with it). However this rule is not enforced in order to provide the user with opportunities to abuse the Redis single instance configuration, at the cost of writing scripts not compatible with Redis Cluster.
  60 +In order for this to be true for `EVAL` also keys must be explicit. This is
  61 +useful in many ways, but especially in order to make sure Redis Cluster is able
  62 +to forward your request to the appropriate cluster node (Redis Cluster is a
  63 +work in progress, but the scripting feature was designed in order to play well
  64 +with it). However this rule is not enforced in order to provide the user with
  65 +opportunities to abuse the Redis single instance configuration, at the cost of
  66 +writing scripts not compatible with Redis Cluster.
64 67
65   -Lua scripts can return a value, that is converted from the Lua type to the Redis protocol using a set of conversion rules.
  68 +Lua scripts can return a value, that is converted from the Lua type to the Redis
  69 +protocol using a set of conversion rules.
66 70
67 71 ## Conversion between Lua and Redis data types
68 72
69   -Redis return values are converted into Lua data types when Lua calls a
70   -Redis command using call() or pcall(). Similarly Lua data types are
71   -converted into Redis protocol when a Lua script returns some value, so that
72   -scripts can control what `EVAL` will reply to the client.
  73 +Redis return values are converted into Lua data types when Lua calls a Redis
  74 +command using call() or pcall(). Similarly Lua data types are converted into
  75 +Redis protocol when a Lua script returns some value, so that scripts can control
  76 +what `EVAL` will reply to the client.
73 77
74   -This conversion between data types is designed in a way that if
75   -a Redis type is converted into a Lua type, and then the result is converted
76   -back into a Redis type, the result is the same as of the initial value.
  78 +This conversion between data types is designed in a way that if a Redis type is
  79 +converted into a Lua type, and then the result is converted back into a Redis
  80 +type, the result is the same as of the initial value.
77 81
78   -In other words there is a one to one conversion between Lua and Redis types.
79   -The following table shows you all the conversions rules:
  82 +In other words there is a one to one conversion between Lua and Redis types. The
  83 +following table shows you all the conversions rules:
80 84
81 85 **Redis to Lua** conversion table.
82 86
@@ -115,30 +119,29 @@ The followings are a few conversion examples:
115 119 > eval "return redis.call('get','foo')" 0
116 120 "bar"
117 121
118   -The last example shows how it is possible to directly return from Lua
119   -the return value of `redis.call()` and `redis.pcall()` with the result of
120   -returning exactly what the called command would return if called directly.
  122 +The last example shows how it is possible to directly return from Lua the return
  123 +value of `redis.call()` and `redis.pcall()` with the result of returning exactly
  124 +what the called command would return if called directly.
121 125
122 126 ## Atomicity of scripts
123 127
124 128 Redis uses the same Lua interpreter to run all the commands. Also Redis
125   -guarantees that a script is executed in an atomic way: no other script
126   -or Redis command will be executed while a script is being executed.
127   -This semantics is very similar to the one of `MULTI` / `EXEC`.
128   -From the point of view of all the other clients the effects of a script
129   -are either still not visible or already completed.
130   -
131   -However this also means that executing slow scripts is not a good idea.
132   -It is not hard to create fast scripts, as the script overhead is very low,
133   -but if you are going to use slow scripts you should be aware that while the
134   -script is running no other client can execute commands since the server
135   -is busy.
  129 +guarantees that a script is executed in an atomic way: no other script or Redis
  130 +command will be executed while a script is being executed. This semantics is
  131 +very similar to the one of `MULTI` / `EXEC`. From the point of view of all the
  132 +other clients the effects of a script are either still not visible or already
  133 +completed.
  134 +
  135 +However this also means that executing slow scripts is not a good idea. It is
  136 +not hard to create fast scripts, as the script overhead is very low, but if
  137 +you are going to use slow scripts you should be aware that while the script is
  138 +running no other client can execute commands since the server is busy.
136 139
137 140 ## Error handling
138 141
139 142 As already stated calls to `redis.call()` resulting into a Redis command error
140   -will stop the execution of the script and will return that error back, in a
141   -way that makes it obvious that the error was generated by a script:
  143 +will stop the execution of the script and will return that error back, in a way
  144 +that makes it obvious that the error was generated by a script:
142 145
143 146 > del foo
144 147 (integer) 1
@@ -147,17 +150,17 @@ way that makes it obvious that the error was generated by a script:
147 150 > eval "return redis.call('get','foo')" 0
148 151 (error) ERR Error running script (call to f_6b1bf486c81ceb7edf3c093f4c48582e38c0e791): ERR Operation against a key holding the wrong kind of value
149 152
150   -Using the `redis.pcall()` command no error is raised, but an error object
151   -is returned in the format specified above (as a Lua table with an `err`
152   -field). The user can later return this exact error to the user just returning
153   -the error object returned by `redis.pcall()`.
  153 +Using the `redis.pcall()` command no error is raised, but an error object is
  154 +returned in the format specified above (as a Lua table with an `err` field).
  155 +The user can later return this exact error to the user just returning the error
  156 +object returned by `redis.pcall()`.
154 157
155 158 ## Bandwidth and EVALSHA
156 159
157   -The `EVAL` command forces you to send the script body again and again.
158   -Redis does not need to recompile the script every time as it uses an internal
159   -caching mechanism, however paying the cost of the additional bandwidth may
160   -not be optimal in many contexts.
  160 +The `EVAL` command forces you to send the script body again and again. Redis
  161 +does not need to recompile the script every time as it uses an internal caching
  162 +mechanism, however paying the cost of the additional bandwidth may not be
  163 +optimal in many contexts.
161 164
162 165 On the other hand defining commands using a special command or via `redis.conf`
163 166 would be a problem for a few reasons:
@@ -168,8 +171,8 @@ would be a problem for a few reasons:
168 171
169 172 * Reading an application code the full semantic could not be clear since the application would call commands defined server side.
170 173
171   -In order to avoid the above three problems and at the same time don't incur
172   -in the bandwidth penalty, Redis implements the `EVALSHA` command.
  174 +In order to avoid the above three problems and at the same time don't incur in
  175 +the bandwidth penalty, Redis implements the `EVALSHA` command.
173 176
174 177 `EVALSHA` works exactly as `EVAL`, but instead of having a script as first argument it has the SHA1 sum of a script. The behavior is the following:
175 178
@@ -192,43 +195,42 @@ Example:
192 195
193 196 The client library implementation can always optimistically send `EVALSHA` under
194 197 the hoods even when the client actually called `EVAL`, in the hope the script
195   -was already seen by the server. If the `NOSCRIPT` error is returned `EVAL` will be used instead.
  198 +was already seen by the server. If the `NOSCRIPT` error is returned `EVAL` will
  199 +be used instead.
196 200
197   -Passing keys and arguments as `EVAL` additional arguments is also
198   -very useful in this context as the script string remains constant and can be
199   -efficiently cached by Redis.
  201 +Passing keys and arguments as `EVAL` additional arguments is also very useful in
  202 +this context as the script string remains constant and can be efficiently cached
  203 +by Redis.
200 204
201 205 ## Script cache semantics
202 206
203   -Executed scripts are guaranteed to be in the script cache **forever**.
204   -This means that if an `EVAL` is performed against a Redis instance all the
205   -subsequent `EVALSHA` calls will succeed.
206   -
207   -The only way to flush the script cache is by explicitly calling the
208   -SCRIPT FLUSH command, that will *completely flush* the scripts cache removing
209   -all the scripts executed so far. This is usually
210   -needed only when the instance is going to be instantiated for another
211   -customer or application in a cloud environment.
212   -
213   -The reason why scripts can be cached for long time is that it is unlikely
214   -for a well written application to have so many different scripts to create
215   -memory problems. Every script is conceptually like the implementation of
216   -a new command, and even a large application will likely have just a few
217   -hundreds of that. Even if the application is modified many times and
218   -scripts will change, still the memory used is negligible.
219   -
220   -The fact that the user can count on Redis not removing scripts
221   -is semantically a very good thing. For instance an application taking
222   -a persistent connection to Redis can stay sure that if a script was
223   -sent once it is still in memory, thus for instance can use EVALSHA
224   -against those scripts in a pipeline without the chance that an error
225   -will be generated since the script is not known (we'll see this problem
226   -in its details later).
  207 +Executed scripts are guaranteed to be in the script cache **forever**. This
  208 +means that if an `EVAL` is performed against a Redis instance all the subsequent
  209 +`EVALSHA` calls will succeed.
  210 +
  211 +The only way to flush the script cache is by explicitly calling the SCRIPT FLUSH
  212 +command, that will *completely flush* the scripts cache removing all the scripts
  213 +executed so far. This is usually needed only when the instance is going to be
  214 +instantiated for another customer or application in a cloud environment.
  215 +
  216 +The reason why scripts can be cached for long time is that it is unlikely for
  217 +a well written application to have so many different scripts to create memory
  218 +problems. Every script is conceptually like the implementation of a new command,
  219 +and even a large application will likely have just a few hundreds of that. Even
  220 +if the application is modified many times and scripts will change, still the
  221 +memory used is negligible.
  222 +
  223 +The fact that the user can count on Redis not removing scripts is semantically a
  224 +very good thing. For instance an application taking a persistent connection to
  225 +Redis can stay sure that if a script was sent once it is still in memory, thus
  226 +for instance can use EVALSHA against those scripts in a pipeline without the
  227 +chance that an error will be generated since the script is not known (we'll see
  228 +this problem in its details later).
227 229
228 230 ## The SCRIPT command
229 231
230   -Redis offers a SCRIPT command that can be used in order to control
231   -the scripting subsystem. SCRIPT currently accepts three different commands:
  232 +Redis offers a SCRIPT command that can be used in order to control the scripting
  233 +subsystem. SCRIPT currently accepts three different commands:
232 234
233 235 * SCRIPT FLUSH. This command is the only way to force Redis to flush the
234 236 scripts cache. It is mostly useful in a cloud environment where the same
@@ -257,18 +259,18 @@ See the next sections for more information about long running scripts.
257 259 ## Scripts as pure functions
258 260
259 261 A very important part of scripting is writing scripts that are pure functions.
260   -Scripts executed in a Redis instance are replicated on slaves sending the
261   -same script, instead of the resulting commands. The same happens for the
262   -Append Only File. The reason is that scripts are much faster than sending
263   -commands one after the other to a Redis instance, so if the client is
264   -taking the master very busy sending scripts, turning this scripts into single
265   -commands for the slave / AOF would result in too much bandwidth for the
266   -replication link or the Append Only File (and also too much CPU since
267   -dispatching a command received via network is a lot more work for Redis
268   -compared to dispatching a command invoked by Lua scripts).
269   -
270   -The only drawback with this approach is that scripts are required to
271   -have the following property:
  262 +Scripts executed in a Redis instance are replicated on slaves sending the same
  263 +script, instead of the resulting commands. The same happens for the Append Only
  264 +File. The reason is that scripts are much faster than sending commands one after
  265 +the other to a Redis instance, so if the client is taking the master very busy
  266 +sending scripts, turning this scripts into single commands for the slave / AOF
  267 +would result in too much bandwidth for the replication link or the Append Only
  268 +File (and also too much CPU since dispatching a command received via network
  269 +is a lot more work for Redis compared to dispatching a command invoked by Lua
  270 +scripts).
  271 +
  272 +The only drawback with this approach is that scripts are required to have the
  273 +following property:
272 274
273 275 * The script always evaluates the same Redis *write* commands with the
274 276 same arguments given the same input data set. Operations performed by
@@ -301,9 +303,9 @@ time a new script is executed. This means that calling `math.random` will
301 303 always generate the same sequence of numbers every time a script is
302 304 executed if `math.randomseed` is not used.
303 305
304   -However the user is still able to write commands with random behaviors
305   -using the following simple trick. Imagine I want to write a Redis
306   -script that will populate a list with N random integers.
  306 +However the user is still able to write commands with random behaviors using
  307 +the following simple trick. Imagine I want to write a Redis script that will
  308 +populate a list with N random integers.
307 309
308 310 I can start writing the following script, using a small Ruby program:
309 311
@@ -340,11 +342,10 @@ following elements:
340 342 9) "0.74990198051087"
341 343 10) "0.17082803611217"
342 344
343   -In order to make it a pure function, but still making sure that every
344   -invocation of the script will result in different random elements, we can
345   -simply add an additional argument to the script, that will be used in order to
346   -seed the Lua pseudo random number generator. The new script will be like the
347   -following:
  345 +In order to make it a pure function, but still making sure that every invocation
  346 +of the script will result in different random elements, we can simply add an
  347 +additional argument to the script, that will be used in order to seed the Lua
  348 +pseudo random number generator. The new script will be like the following:
348 349
349 350 RandomPushScript = <<EOF
350 351 local i = tonumber(ARGV[1])
@@ -360,13 +361,13 @@ following:
360 361 r.del(:mylist)
361 362 puts r.eval(RandomPushScript,1,:mylist,10,rand(2**32))
362 363
363   -What we are doing here is sending the seed of the PRNG as one of the
364   -arguments. This way the script output will be the same given the same
365   -arguments, but we are changing one of the argument at every invocation,
366   -generating the random seed client side. The seed will be propagated as
367   -one of the arguments both in the replication link and in the Append Only
368   -File, guaranteeing that the same changes will be generated when the AOF
369   -is reloaded or when the slave will process the script.
  364 +What we are doing here is sending the seed of the PRNG as one of the arguments.
  365 +This way the script output will be the same given the same arguments, but we are
  366 +changing one of the argument at every invocation, generating the random seed
  367 +client side. The seed will be propagated as one of the arguments both in the
  368 +replication link and in the Append Only File, guaranteeing that the same changes
  369 +will be generated when the AOF is reloaded or when the slave will process the
  370 +script.
370 371
371 372 Note: an important part of this behavior is that the PRNG that Redis implements
372 373 as `math.random` and `math.randomseed` is guaranteed to have the same output
@@ -376,10 +377,11 @@ like big or little endian systems will still produce the same output.
376 377 ## Global variables protection
377 378
378 379 Redis scripts are not allowed to create global variables, in order to avoid
379   -leaking data into the Lua state. If a script requires to take state across
380   -calls (a pretty uncommon need) it should use Redis keys instead.
  380 +leaking data into the Lua state. If a script requires to take state across calls
  381 +(a pretty uncommon need) it should use Redis keys instead.
381 382
382   -When a global variable access is attempted the script is terminated and EVAL returns with an error:
  383 +When a global variable access is attempted the script is terminated and EVAL
  384 +returns with an error:
383 385
384 386 redis 127.0.0.1:6379> eval 'a=10' 0
385 387 (error) ERR Error running script (call to f_933044db579a2f8fd45d8065f04a8d0249383e57): user_script:1: Script attempted to create global variable 'a'
@@ -392,7 +394,8 @@ protection, is not hard. However it is hardly possible to do it accidentally.
392 394 If the user messes with the Lua global state, the consistency of AOF and
393 395 replication is not guaranteed: don't do it.
394 396
395   -Note for Lua newbies: in order to avoid using global variables in your scripts simply declare every variable you are going to use using the *local* keyword.
  397 +Note for Lua newbies: in order to avoid using global variables in your scripts
  398 +simply declare every variable you are going to use using the *local* keyword.
396 399
397 400 ## Available libraries
398 401
@@ -406,8 +409,8 @@ The Redis Lua interpreter loads the following Lua libraries:
406 409 * cjson lib.
407 410 * cmsgpack lib.
408 411
409   -Every Redis instance is *guaranteed* to have all the above libraries so you
410   -can be sure that the environment for your Redis scripts is always the same.
  412 +Every Redis instance is *guaranteed* to have all the above libraries so you can
  413 +be sure that the environment for your Redis scripts is always the same.
411 414
412 415 The CJSON library allows to manipulate JSON data in a very fast way from Lua.
413 416 All the other libraries are standard Lua libraries.
@@ -426,8 +429,9 @@ It is possible to write to the Redis log file from Lua scripts using the
426 429 * `redis.LOG_NOTICE`
427 430 * `redis.LOG_WARNING`
428 431
429   -They exactly correspond to the normal Redis log levels. Only logs emitted by scripting using a log level that is equal or greater than the currently configured
430   -Redis instance log level will be emitted.
  432 +They exactly correspond to the normal Redis log levels. Only logs emitted
  433 +by scripting using a log level that is equal or greater than the currently
  434 +configured Redis instance log level will be emitted.
431 435
432 436 The `message` argument is simply a string. Example:
433 437
@@ -440,26 +444,24 @@ Will generate the following:
440 444 ## Sandbox and maximum execution time
441 445
442 446 Scripts should never try to access the external system, like the file system,
443   -nor calling any other system call. A script should just do its work operating
444   -on Redis data and passed arguments.
  447 +nor calling any other system call. A script should just do its work operating on
  448 +Redis data and passed arguments.
445 449
446 450 Scripts are also subject to a maximum execution time (five seconds by default).
447 451 This default timeout is huge since a script should run usually in a sub
448 452 millisecond amount of time. The limit is mostly needed in order to avoid
449   -problems when developing scripts that may loop forever for a programming
450   -error.
  453 +problems when developing scripts that may loop forever for a programming error.
451 454
452   -It is possible to modify the maximum time a script can be executed
453   -with milliseconds precision, either via `redis.conf` or using the
454   -CONFIG GET / CONFIG SET command. The configuration parameter
455   -affecting max execution time is called `lua-time-limit`.
  455 +It is possible to modify the maximum time a script can be executed with
  456 +milliseconds precision, either via `redis.conf` or using the CONFIG GET / CONFIG
  457 +SET command. The configuration parameter affecting max execution time is called
  458 +`lua-time-limit`.
456 459
457   -When a script reaches the timeout it is not automatically terminated by
458   -Redis since this violates the contract Redis has with the scripting engine
459   -to ensure that scripts are atomic in nature. Stopping a script half-way means
460   -to possibly leave the dataset with half-written data inside.
461   -For this reasons when a script executes for more than the specified time
462   -the following happens:
  460 +When a script reaches the timeout it is not automatically terminated by Redis
  461 +since this violates the contract Redis has with the scripting engine to ensure
  462 +that scripts are atomic in nature. Stopping a script half-way means to possibly
  463 +leave the dataset with half-written data inside. For this reasons when a script
  464 +executes for more than the specified time the following happens:
463 465
464 466 * Redis logs that a script that is running for too much time is still in execution.
465 467 * It starts accepting commands again from other clients, but will reply with a BUSY error to all the clients sending normal commands. The only allowed commands in this status are `SCRIPT KILL` and `SHUTDOWN NOSAVE`.
@@ -469,12 +471,11 @@ the following happens:
469 471 ## EVALSHA in the context of pipelining
470 472
471 473 Care should be taken when executing `EVALSHA` in the context of a pipelined
472   -request, since even in a pipeline the order of execution of commands must
473   -be guaranteed. If `EVALSHA` will return a `NOSCRIPT` error the command can not
474   -be reissued later otherwise the order of execution is violated.
  474 +request, since even in a pipeline the order of execution of commands must be
  475 +guaranteed. If `EVALSHA` will return a `NOSCRIPT` error the command can not be
  476 +reissued later otherwise the order of execution is violated.
475 477
476   -The client library implementation should take one of the following
477   -approaches:
  478 +The client library implementation should take one of the following approaches:
478 479
479 480 * Always use plain `EVAL` when in the context of a pipeline.
480 481
8 commands/exec.md
Source Rendered
@@ -4,9 +4,8 @@ normal.
4 4
5 5 [transactions]: /topics/transactions
6 6
7   -When using `WATCH`, `EXEC` will execute commands only if the
8   -watched keys were not modified, allowing for a [check-and-set
9   -mechanism][cas].
  7 +When using `WATCH`, `EXEC` will execute commands only if the watched keys were
  8 +not modified, allowing for a [check-and-set mechanism][cas].
10 9
11 10 [cas]: /topics/transactions#cas
12 11
@@ -15,5 +14,4 @@ mechanism][cas].
15 14 @multi-bulk-reply: each element being the reply to each of the commands
16 15 in the atomic transaction.
17 16
18   -When using `WATCH`, `EXEC` can return a @nil-reply if the execution was
19   -aborted.
  17 +When using `WATCH`, `EXEC` can return a @nil-reply if the execution was aborted.
83 commands/expire.md
Source Rendered
@@ -2,8 +2,8 @@ Set a timeout on `key`. After the timeout has expired, the key will
2 2 automatically be deleted. A key with an associated timeout is often said to be
3 3 _volatile_ in Redis terminology.
4 4
5   -The timeout is cleared only when the key is removed using the `DEL` command or
6   -overwritten using the `SET` or `GETSET` commands. This means that all the
  5 +The timeout is cleared only when the key is removed using the `DEL` command
  6 +or overwritten using the `SET` or `GETSET` commands. This means that all the
7 7 operations that conceptually *alter* the value stored at the key without
8 8 replacing it with a new one will leave the timeout untouched. For instance,
9 9 incrementing the value of a key with `INCR`, pushing a new value into a list
@@ -25,15 +25,15 @@ matter if the original `Key_A` had a timeout associated or not, the new key
25 25
26 26 It is possible to call `EXPIRE` using as argument a key that already has an
27 27 existing expire set. In this case the time to live of a key is *updated* to the
28   -new value. There are many useful applications for this, an example is
29   -documented in the *Navigation session* pattern section below.
  28 +new value. There are many useful applications for this, an example is documented
  29 +in the *Navigation session* pattern section below.
30 30
31 31 ## Differences in Redis prior 2.1.3
32 32
33   -In Redis versions prior **2.1.3** altering a key with an expire set using
34   -a command altering its value had the effect of removing the key entirely.
35   -This semantics was needed because of limitations in the replication layer that
36   -are now fixed.
  33 +In Redis versions prior **2.1.3** altering a key with an expire set using a
  34 +command altering its value had the effect of removing the key entirely. This
  35 +semantics was needed because of limitations in the replication layer that are
  36 +now fixed.
37 37
38 38 @return
39 39
@@ -60,8 +60,8 @@ at this set of page views as a *Navigation session* if your user, that may
60 60 contain interesting information about what kind of products he or she is
61 61 looking for currently, so that you can recommend related products.
62 62
63   -You can easily model this pattern in Redis using the following strategy:
64   -every time the user does a page view you call the following commands:
  63 +You can easily model this pattern in Redis using the following strategy: every
  64 +time the user does a page view you call the following commands:
65 65
66 66 MULTI
67 67 RPUSH pagewviews.user:<userid> http://.....
@@ -79,43 +79,51 @@ using `RPUSH`.
79 79
80 80 ## Keys with an expire
81 81
82   -Normally Redis keys are created without an associated time to live. The key
83   -will simply live forever, unless it is removed by the user in an explicit
84   -way, for instance using the `DEL` command.
  82 +Normally Redis keys are created without an associated time to live. The key will
  83 +simply live forever, unless it is removed by the user in an explicit way, for
  84 +instance using the `DEL` command.
85 85
86 86 The `EXPIRE` family of commands is able to associate an expire to a given key,
87 87 at the cost of some additional memory used by the key. When a key has an expire
88 88 set, Redis will make sure to remove the key when the specified amount of time
89 89 elapsed.
90 90
91   -The key time to live can be updated or entirely removed using the `EXPIRE` and `PERSIST` command (or other strictly related commands).
  91 +The key time to live can be updated or entirely removed using the `EXPIRE` and
  92 +`PERSIST` command (or other strictly related commands).
92 93
93 94 ## Expire accuracy
94 95
95   -In Redis 2.4 the expire might not be pin-point accurate, and it could be
96   -between zero to one seconds out.
  96 +In Redis 2.4 the expire might not be pin-point accurate, and it could be between
  97 +zero to one seconds out.
97 98
98 99 Since Redis 2.6 the expire error is from 0 to 1 milliseconds.
99 100
100 101 ## Expires and persistence
101 102
102   -Keys expiring information is stored as absolute Unix timestamps (in milliseconds in case of Redis version 2.6 or greater). This means that the time is flowing even when the Redis instance is not active.
  103 +Keys expiring information is stored as absolute Unix timestamps (in milliseconds
  104 +in case of Redis version 2.6 or greater). This means that the time is flowing
  105 +even when the Redis instance is not active.
103 106
104   -For expires to work well, the computer time must be taken stable. If you move an RDB file from two computers with a big desync in their clocks, funny things may happen (like all the keys loaded to be expired at loading time).
  107 +For expires to work well, the computer time must be taken stable. If you move an
  108 +RDB file from two computers with a big desync in their clocks, funny things may
  109 +happen (like all the keys loaded to be expired at loading time).
105 110
106   -Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.
  111 +Even running instances will always check the computer clock, so for instance if
  112 +you set a key with a time to live of 1000 seconds, and then set your computer
  113 +time 2000 seconds in the future, the key will be expired immediately, instead of
  114 +lasting for 1000 seconds.
107 115
108 116 ## How Redis expires keys
109 117
110 118 Redis keys are expired in two ways: a passive way, and an active way.
111 119
112   -A key is actively expired simply when some client tries to access it, and
113   -the key is found to be timed out.
  120 +A key is actively expired simply when some client tries to access it, and the
  121 +key is found to be timed out.
114 122
115   -Of course this is not enough as there are expired keys that will never
116   -be accessed again. This keys should be expired anyway, so periodically
117   -Redis test a few keys at random among keys with an expire set.
118   -All the keys that are already expired are deleted from the keyspace.
  123 +Of course this is not enough as there are expired keys that will never be
  124 +accessed again. This keys should be expired anyway, so periodically Redis test a
  125 +few keys at random among keys with an expire set. All the keys that are already
  126 +expired are deleted from the keyspace.
119 127
120 128 Specifically this is what Redis does 10 times per second:
121 129
@@ -123,24 +131,23 @@ Specifically this is what Redis does 10 times per second:
123 131 2. Delete all the keys found expired.
124 132 3. If more than 25 keys were expired, start again from step 1.
125 133
126   -This is a trivial probabilistic algorithm, basically the assumption is
127   -that our sample is representative of the whole key space,
128   -and we continue to expire until the percentage of keys that are likely
129   -to be expired is under 25%
  134 +This is a trivial probabilistic algorithm, basically the assumption is that our
  135 +sample is representative of the whole key space, and we continue to expire until
  136 +the percentage of keys that are likely to be expired is under 25%
130 137
131   -This means that at any given moment the maximum amount of keys already
132   -expired that are using memory is at max equal to max amount of write
133   -operations per second divided by 4.
  138 +This means that at any given moment the maximum amount of keys already expired
  139 +that are using memory is at max equal to max amount of write operations per
  140 +second divided by 4.
134 141
135 142 ## How expires are handled in the replication link and AOF file
136 143
137   -In order to obtain a correct behavior without sacrificing consistency, when
138   -a key expires, a `DEL` operation is synthesized in both the AOF file and gains
139   -all the attached slaves. This way the expiration process is centralized in
140   -the master instance, and there is no chance of consistency errors.
  144 +In order to obtain a correct behavior without sacrificing consistency, when a
  145 +key expires, a `DEL` operation is synthesized in both the AOF file and gains
  146 +all the attached slaves. This way the expiration process is centralized in the