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
aditya goel

aditya goel

Software Engineer for Big Data distributed systems