Chapter 4. Functions in the Redis Server

In the previous chapters, we saw some features of Redis Server that make it a key-value NoSQL. We also saw that Redis, apart from storing vanilla key-values, also provides semantics to store data in a structured way. This feature in itself makes Redis stand out in the crowd, since most of the other databases (RDBMS and other NoSQL) don't provide interfaces which programmers can use. Other data stores have a fixed way of storing information, such as documents or maps, and programmers have to convert their data into these semantics to hold information. However, in Redis, programmers can store information in the same sematic that they use in their programs, such as a map, list, and so on. This in way provides a better and an easier way of understanding the program. Apart from that, Redis provides functions which elevate Redis from being just a data store to more like a framework builder, or in other words, more like a Swiss army knife. In this chapter...

Real-time messaging (PUB/SUB)

Enterprises and social media solutions use messaging in a similar way, and in a way, this forms the backbone of any framework or any solution. Messaging also enables us to have architectures which are loosely coupled where components interact via messages and events. Redis provides mechanism to have real time messaging between components. Unlike other messaging systems, the big difference in the messaging model provided in Redis is as follows:

• It does not store the message after delivering it

• It does not store the message if the client (subscriber) was unable to consume it

This can be a disadvantage if compared to a traditional messaging system but is advantageous where data has importance in real time and need not be stored. The message is always sent sequentially. Apart from that, Redis messaging system is simplistic and easy to learn, and does not have the fluff of some of the other messaging systems.

Publish subscribe model of Redis

Following are the commands...

Pipelines in Redis

Redis provides a mechanism for faster execution, called pipeline. This groups up all the commands as one command block and sends it to the server for execution. The results of all the commands get queued in a response block and sent back.

Comparing the way pipeline works with multiple individual commands sent across a connection will give us an idea of how pipeline is more efficient and where it needs to be used. Let's assume a scenario where we have to send three commands to Redis. The time taken to send any command to Redis is X seconds, so the same amount of time is required to send the response. The total time spent in going and return journey is 2X seconds. Let's also assume that the time taken for execution is another X seconds. Now in the pipeline commands, since we are sending three commands as one block, the time taken for going to Redis is around X seconds , the time taken for processing all the three commands is 3X seconds, and the time taken for the return journey...

Transactions in Redis

Redis as a NOSQL data store provides a loose sense of transaction. As in a traditional RDBMS, the transaction starts with a BEGIN and ends with either COMMIT or ROLLBACK. All these RDBMS servers are multithreaded, so when a thread locks a resource, it cannot be manipulated by another thread unless and until the lock is released. Redis by default has MULTI to start and EXEC to execute the commands. In case of a transaction, the first command is always MULTI, and after that all the commands are stored, and when EXEC command is received, all the stored commands are executed in sequence. So inside the hood, once Redis receives the EXEC command, all the commands are executed as a single isolated operation. Following are the commands that can be used in Redis for transaction:

• MULTI: This marks the start of a transaction block

• EXEC: This executes all the commands in the pipeline after MULTI

• WATCH: This watches the keys for conditional execution of a transaction

• UNWATCH: This...

Scripting in Redis

Lua is a high performing scripting language with interpreter written in C. Redis provides mechanism to extend the functionality of Redis by providing support for Lua in the server side. Since Redis is implemented in C, it gives a natural synergy for Lua to be offered along with Redis as a server add on. The Lua interpreter shipped along with Redis is with limited capability and following libraries are shipped along with it:

• The base library

• The table library

• The string library

• The math library

• The debug library

• The cjson library

• The cmsgpack library

  Note

  Libraries which can do File I/O and Networking are not included, so you cannot send a message from LUA script in REDIS to another external system.

Before we start with fun stuff, it's always better to have a hang of the language. LUA has its own dedicated site and tons of resources are available to LUA, but the next section concentrates on just enough LUA to get started for Redis.

Brief introduction on Lua

Okay, by now we all know that LUA is an interpreted language and it has support in Redis. To make use of the capability of Redis, let's learn couple of things about LUA. Types and values supported in LUA are as follows:

• Nil: Nil is a type with single value nil. On comparing it with Java, it can be taken as null.

• Booleans: These will have either true or false as values.

• Numbers: These represent double precession floating point numbers. So we can write our numbers as 1, 1.1, 2e+10, and so on.

• String: These represent a sequence of characters as is common in most of the scripting and programming languages. In LUA, strings are immutable in nature; for example, "Learning Redis" and 'Learning Redis'. LUA provides methods in string library to find substring, replace characters, and so on.

• Tables: These are like arrays which can be indexed with numbers and strings except nil.

Control statements and loops in LUA are as follows:

• The if then else statement: As in Java, where...

Connection management

In this section we will be focusing on the way we can manage the connection to Redis. The functions provided under connection management in Redis help us to do the following:

• AUTH: This command with the password allows the request to be processed if the password matches the configured password. Redis server can be configured with requirepass in the config file along with the password.

• ECHO: This command echoes back the text sent to a Redis instance.

• PING: This command replies with PONG when sent to a Redis instance.

• QUIT: This command kills the connection held by the Redis instance for a client.

• SELECT: This command helps in selecting a database in Redis for executing the command. Data in Redis can have separation of concern and this is achieved by creating a silo and storing the data in that. The data in each silo don't interfere and are isolated.

Redis authentication

Adding a simple password to your Redis server via Redis client and testing it via Java client is explained...

Summary

In this chapter, we saw how to use Redis, not simply as a datastore, but also as pipeline the commands which is so much more like bulk processing. Apart from that, we covered areas such as transaction, messaging, and scripting. We also saw how to combine messaging and scripting, and create reliable messaging in Redis. This capability of Redis makes it different from some of the other datastore solutions. In the next chapter, we will focus on data handling capabilities of Redis.