Caching solutions   with Redis
Upcoming SlideShare
Loading in...5

Caching solutions with Redis



Caching solutions with Redis - presentation held by Bogdan Hadadea at Open Coffee Tech meetup

Caching solutions with Redis - presentation held by Bogdan Hadadea at Open Coffee Tech meetup



Total Views
Views on SlideShare
Embed Views



1 Embed 17 17



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Caching solutions   with Redis Caching solutions with Redis Presentation Transcript

  • Caching Solutions: Redis with Bogdan Hadadea
  • 1. General Description: Redis • • • • NoSQL key-value date store Like MongoDB, but better Built-in persistence More data types o o o o String Hash Set List • Built-in pub/sub feature • Highly scalable
  • 1. General Description: Redis • • • • • • • Creator: Salvatore Sanfilippo Released: 2009 Written in ANSI C Single threaded Open Source Backed by VMWare Early adopted by GitHub
  • 2. Usage: Redis – Who? • StackOverflow – 3 layers of caching o Local cache o Site cache o Global cache • Blizzard – 8 node Redis install o 16GB/instance o For storing auction house and serving avatars • Amazon ElastiCache, Redis-to-go o Cache in the cloud o Cache hosting
  • 2. Usage: Redis – What for? • Redis for cache o Good to place sessions – hashes o A fine place for high score tracking – sorted sets • Redis as database o Persistence to disk o High performance • Redis as message bus o Based on Pub/Sub functionality o Queues with list structures o Resque – Ruby library for creating background jobs
  • 3. Architecture: Redis – Overview
  • 3. Architecture: Redis • Request/Response Protocols: o Redis is a TCP server using the client-server model Request/Response protocol • Pipelining: o Process multiple requests even if response not read yet o Not paying the RTT (Round Trip Time) for every command • Limitations: o Responses stored in a queue o Recommended max: 10k commands • Benchmark: ‘Ping’ – 10k times
  • 3. Architecture: Redis • Scripting o o o o Lua interpreter built in ver. > 2.6 Using EVAL and EVALSHA Conversion between Lua and Redis data types & redis.pcall() o Atomicity of scripts o Emitting Redis logs from scripts o EVALSHA in the context of pipelining
  • 3. Architecture: Redis • Replication: o o o o o o o o o o o o o Master-slave: exact copies Asynchronous replication Master – multiple slaves Non-blocking replication – master side Non-blocking replication – slave side – old dataset Slaves accept connections from other slaves Replication for scalability Replication for cost saving Full/Partial synchronization Configure: slaveof 6379 Read-only slaves Slave authentication to master Write only when N replicas
  • 3. Architecture: Redis • Redis Transactions: o No rollback o Optimistic locking
  • 3. Architecture: Redis • Publisher/Subscriber messaging paradigm o Decoupling pub-sub o Pattern matching subscriptions • Redis clustering o Not production ready • Memory optimization o Encoding of small data – up to 5x less space o Using 32bit instances • Using hashes to abstract a key-value on top of Redis
  • 4. Comparison: Memcached
  • 4. Comparison: Memcached
  • 5. Conclusion • • • • Focused on speed Reliable as database Steeper learning curve than other solutions Still improving