5.

Debugging

Sec. Behavior Study and Practice

5.1 Identify the type of data structure pointed to by an unknown key. https://redis.io/commands/type

Determine which operations are being sent to a Redis server using the https://redis.io/commands/
5.2
MONITOR command. MONITOR

Understand that the Redis serialization protocol is human-readable and

text-based protocol used for communication between a Redis client and
server.

Understand that each line a RESP message is terminated by a CRLF ("\r\

n").

Understand that each data type is represented by a different symbol. From

the RESP docs:
https://redis.io/topics/protocol
• For Simple Strings the first byte of the reply is "+"
5.3 This is also covered in Redis
• For Errors the first byte of the reply is "-"
University courses RU102J and
• For Integers the first byte of the reply is ":"
RU102JS.
• For Bulk Strings the first byte of the reply is "$"
• For Arrays the first byte of the reply is "*"

Understand that the protocol uses prefixed lengths to indicate the size of
a response. For example, a response beginning with *275 indicates a
response containing an array having 275 elements.

Similarly, a response beginning with $10 indicates a string with a length

of ten.

https://redis.io/commands/
Understand the OBJECT command.
object

Understand the INFO command.

https://redis.io/commands/info
Focus on the "server", "stats", and "keyspace" sections.

TYPE key Available since 1.0.0. Time complexity: O(1)

Returns the string representation of the type of the value stored at key. The different types that can be returned
are: string, list, set, zset, hash and stream.
Return value Simple string reply: type of key, or none when key does not exist.
Examples
redis> SET key1 "value"
"OK"
redis> LPUSH key2 "value"
(integer) 1
redis> SADD key3 "value"
(integer) 1
redis> TYPE key1
"string"
redis> TYPE key2
"list"
redis> TYPE key3
"set"
redis>

OBJECT Available since 2.2.3. Time complexity: Depends on subcommand.

This is a container command for object introspection commands.
To see the list of available commands you can call OBJECT HELP.

MONITOR Available since 1.0.0.

MONITOR is a debugging command that streams back every command processed by the Redis server. It can
help in understanding what is happening to the database. This command can both be used via redis-cli and via
telnet.
The ability to see all the requests processed by the server is useful in order to spot bugs in an application both
when using Redis as a database and as a distributed caching system.
$ redis-cli monitor
1339518083.107412 [0 127.0.0.1:60866] "keys" "*"
1339518087.877697 [0 127.0.0.1:60866] "dbsize"
1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6"
1339518096.506257 [0 127.0.0.1:60866] "get" "x"
1339518099.363765 [0 127.0.0.1:60866] "eval" "return redis.call('set','x','7')" "0"
1339518100.363799 [0 lua] "set" "x" "7"
1339518100.544926 [0 127.0.0.1:60866] "del" "x"
Use SIGINT (Ctrl-C) to stop a MONITOR stream running via redis-cli.
$ telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
MONITOR
+OK
+1339518083.107412 [0 127.0.0.1:60866] "keys" "*"
+1339518087.877697 [0 127.0.0.1:60866] "dbsize"
+1339518090.420270 [0 127.0.0.1:60866] "set" "x" "6"
+1339518096.506257 [0 127.0.0.1:60866] "get" "x"
+1339518099.363765 [0 127.0.0.1:60866] "del" "x"
+1339518100.544926 [0 127.0.0.1:60866] "get" "x"
QUIT
+OK
Connection closed by foreign host.
Manually issue the QUIT or RESET commands to stop a MONITOR stream running via telnet.
Commands not logged by MONITOR Because of security concerns, no administrative commands are logged
by MONITOR's output and sensitive data is redacted in the command AUTH.
Furthermore, the command QUIT is also not logged.
Cost of running MONITOR
Because MONITOR streams back all commands, its use comes at a cost. The following (totally unscientific)
benchmark numbers illustrate what the cost of running MONITOR can be.
Benchmark result without MONITOR running:
$ src/redis-benchmark -c 10 -n 100000 -q
PING_INLINE: 101936.80 requests per second
PING_BULK: 102880.66 requests per second
SET: 95419.85 requests per second
GET: 104275.29 requests per second
INCR: 93283.58 requests per second
Benchmark result with MONITOR running (redis-cli monitor > /dev/null):
$ src/redis-benchmark -c 10 -n 100000 -q
PING_INLINE: 58479.53 requests per second
PING_BULK: 59136.61 requests per second
SET: 41823.50 requests per second
GET: 45330.91 requests per second
INCR: 41771.09 requests per second
In this particular case, running a single MONITOR client can reduce the throughput by more than 50%. Running
more MONITOR clients will reduce throughput even more.
Return value Non standard return value, just dumps the received commands in an infinite flow.
History
Redis version >= 6.0.0: `AUTH` excluded from the command's output.
Redis version >= 6.2.0: `RESET` can be called to exit monitor mode.
Redis version >= 6.2.4: `AUTH`, `HELLO`, `EVAL`, `EVAL_RO`, `EVALSHA` and `EVALSHA_RO`
included in the command's output.

INFO [section] Available since 1.0.0. Time complexity: O(1)

The INFO command returns information and statistics about the server in a format that is simple to parse by
computers and easy to read by humans.
The optional parameter can be used to select a specific section of information:
server: General information about the Redis server
clients: Client connections section
memory: Memory consumption related information
persistence: RDB and AOF related information
stats: General statistics
replication: Master/replica replication information
cpu: CPU consumption statistics
commandstats: Redis command statistics
cluster: Redis Cluster section
modules: Modules section
keyspace: Database related statistics
modules: Module related sections
errorstats: Redis error statistics
It can also take the following values:
all: Return all sections (excluding module generated ones)
default: Return only the default set of sections
everything: Includes all and modules
When no parameter is provided, the default option is assumed.
Return value Bulk string reply: as a collection of text lines.
Lines can contain a section name (starting with a # character) or a property. All the properties are in the form of
field:value terminated by \r\n.

Redis Protocol specification Redis clients communicate with the Redis server using a protocol called RESP
(REdis Serialization Protocol). While the protocol was designed specifically for Redis, it can be used for other
client-server software projects.
RESP is a compromise between the following things:
Simple to implement.
Fast to parse.
 Human readable.
RESP can serialize different data types like integers, strings, arrays. There is also a specific type for errors.
Requests are sent from the client to the Redis server as arrays of strings representing the arguments of the
command to execute. Redis replies with a command-specific data type.
RESP is binary-safe and does not require processing of bulk data transferred from one process to another,
because it uses prefixed-length to transfer bulk data.
Note: the protocol outlined here is only used for client-server communication. Redis Cluster uses a different
binary protocol in order to exchange messages between nodes.
Networking layer A client connects to a Redis server creating a TCP connection to the port 6379.
While RESP is technically non-TCP specific, in the context of Redis the protocol is only used with TCP
connections (or equivalent stream oriented connections like Unix sockets).
Request-Response model Redis accepts commands composed of different arguments. Once a command is
received, it is processed and a reply is sent back to the client.
This is the simplest model possible, however there are two exceptions:
Redis supports pipelining (covered later in this document). So it is possible for clients to send multiple
commands at once, and wait for replies later.
When a Redis client subscribes to a Pub/Sub channel, the protocol changes semantics and becomes a push
protocol, that is, the client no longer requires sending commands, because the server will automatically send to
the client new messages (for the channels the client is subscribed to) as soon as they are received.
Excluding the above two exceptions, the Redis protocol is a simple request-response protocol.
RESP protocol description
The RESP protocol was introduced in Redis 1.2, but it became the standard way for talking with the Redis server
in Redis 2.0. This is the protocol you should implement in your Redis client.
RESP is actually a serialization protocol that supports the following data types: Simple Strings, Errors, Integers,
Bulk Strings and Arrays.
The way RESP is used in Redis as a request-response protocol is the following:
Clients send commands to a Redis server as a RESP Array of Bulk Strings.
The server replies with one of the RESP types according to the command implementation.
In RESP, the type of some data depends on the first byte:
For Simple Strings the first byte of the reply is "+"
For Errors the first byte of the reply is "-"
For Integers the first byte of the reply is ":"
For Bulk Strings the first byte of the reply is "$"
For Arrays the first byte of the reply is "*"
Additionally RESP is able to represent a Null value using a special variation of Bulk Strings or Array as
specified later.
In RESP different parts of the protocol are always terminated with "\r\n" (CRLF).
As you can see after the *<count>CRLF part prefixing the array, the other data types composing the
array are just concatenated one after the other. For example an Array of three integers is encoded as
follows:
"*3\r\n:1\r\n:2\r\n:3\r\n"
The protocol uses prefixed lengths to indicate the size of a response. For example, a response beginning
with *275 indicates a response containing an array having 275 elements.
Similarly, a response beginning with $10 indicates a string with a length of ten.