Redis vs MySQL & Memcached: Key Differences, Use‑Cases, and HA Design

Redis vs MySQL Comparison

Similarities:

Master‑Slave architecture; under cluster mode data copy and consistency are challenging.

Both support persistent storage, but large data files can pose safety risks on crash‑restart.

Differences:

Redis offers far higher latency performance than MySQL , operates mainly in memory, and supports complex data types.

Redis is a NoSQL/Store‑Cache database, whereas MySQL is an RDBMS; MySQL’s query cache is limited.

Redis allows horizontal sharding, flexible key‑value indexing, and set operations (intersection, union, difference).

MySQL has limits: single table up to 5 million rows and ~3000 concurrent connections per second.

Redis periodically persists data to disk, keeping most data in memory to reduce I/O.

Conclusion:

Both face scaling challenges under high concurrency due to Master‑Slave limits; careful sizing of data files, disk, and memory is required for recovery.

Redis is better suited for frequent queries, set operations, and scenarios like social‑network relationship graphs.

Redis vs Memcached, EhCache, OSCache

EhCache and OSCache were popular for small applications but incur high synchronization costs in distributed environments; e.g., EhCache Server uses multicast, which can cause network storms.

Memcached uses consistent hashing to distribute keys across servers, enabling easy horizontal scaling without disk storage, but has limits: object size ≤ 1 MB, key size ≤ 250 bytes, and writes are slower than reads.

Redis acts as a Store‑Cache, supporting 1 GB object size, 512 Byte keys, complex data types, and in‑memory sorting, but lacks built‑in sharding and may present single‑point‑of‑failure risks when used as a database.

Simple Redis High‑Availability Architecture Idea

Deploy Redis Master‑Slave units behind a virtual IP; use Keepalive for automatic failover.

Perform client‑side sharding with a Redis client (e.g., Jedis) to access multiple Redis servers.

Implement read‑write separation: writes to master, reads from slaves. Note that during horizontal scaling, client consistent‑hashing may need adjustment; simple data file copying can handle master‑to‑slave transition, but multi‑node scaling requires further hashing strategies.

These thoughts are personal brainstorming; feedback is welcome.

For tuning details, see http://www.oschina.net/translate/redis-latency-problems-troubleshooting?from=20130317