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

1. Caching Solutions:
Redis
with Bogdan Hadadea

2. 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

3. 1. General Description: Redis
•
•
•
•
•
•
•
Creator: Salvatore Sanfilippo
Released: 2009
Written in ANSI C
Single threaded
Open Source
Backed by VMWare
Early adopted by GitHub

4. 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

5. 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

6. 3. Architecture: Redis – Overview

7. 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

8. 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.call() & redis.pcall()
o Atomicity of scripts
o Emitting Redis logs from scripts
o EVALSHA in the context of pipelining

9. 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 192.168.1.1 6379
Read-only slaves
Slave authentication to master
Write only when N replicas

10. 3. Architecture: Redis
• Redis Transactions:
o No rollback
o Optimistic locking

11. 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

12. 4. Comparison: Memcached

13. 4. Comparison: Memcached

14. 5. Conclusion
•
•
•
•
Focused on speed
Reliable as database
Steeper learning curve than other solutions
Still improving