Beginners guide to REDIS

  • Fundamentals of Redis.
  • Multi-threading Redis I/O with Redis 6.0 onwards.
  • Connection-Pooling with Redis.
  • Pipelining with Redis.
  • We can store multiple data types like strings, hashes, and streams, and access them by a unique key name.
  • For example, if you have a string value “Hello World” saved under the key name “greeting,” you can access it by running the GET command followed by the key name “greeting.”
  • All keys in the Redis database are stored in a flat key space.
  • There is no enforced schema or naming policy, and the responsibility for organising the key space is left to the developer.
  • Keys in Redis are pretty much like keys that you see in any other language i.e. objects with a key-value pair approach.
  • The key is the property name, and then you follow with a value.
  • Strings → Setting value as a string. In above example, we have set the value as a String only.
  • Lists → Lists are exactly what the name implies: a list of strings.
  • Hashes → Hashes are similar to objects where you can set a specific object and then add field-value pair. For example, you can add a user 456 and inside of that user, add first name field with value many.
  • Sets → Sets are basically a list of unordered and unique strings. So basically if you try to add the same value twice, say a Unix user, you won’t be able to add it more than once.
  • Sorted-sets → Sorted sets are exactly the same as sets, except the fact they are ordered by user-defined key for the values. For example, a sorted set could be strings of historical events sorted by the year associated with each event.
  • Bitmaps
  • Hyperloglogs
  • Geospatial-Indexes.
  • Redis stores and serves data entirely from RAM-Memory instead of disk, as most other databases do.
  • Another contributing factor is the predominantly single-threaded nature. Single threading avoids race conditions and CPU-heavy context switching associated with threads.
  • The request is first read from the socket.
  • Then request is parsed and processed.
  • And finally, the response is written back to the socket and sent to the user.
  • Applications send requests to the Redis server,
  • Server processes them and returns responses for each.
  • Implement the Redis wire protocol, the format used to send requests and receive responses from the Redis server.
  • Provide an idiomatic API for using Redis commands from a particular programming language.
  • Managing the connections to Redis.
  • The RESP protocol is simple and text based, so it is easily read by humans as well as machines.
  • This simple, well-documented protocol has resulted in Redis clients for almost every language we can think of. The Redis.io client page lists over 200 client libraries for more than 50 programming languages.
  • When the application needs to send a request, the current thread will get one of these connections from the pool, use it, and return it when done.
  • So, if possible, always try to choose a client library, that supports pooling connections, because that decision alone can have a huge influence on your system’s performance.
  • The server reads the request from the socket, parses it, processes it, and writes the response to the socket.
  • The time the data packets take to travel from the client to the server, and then back again, is called network round trip time, or RTT.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store