话说有一名意大利程序员，在 2004 年到 2006 年间主要做嵌入式工作，之后接触了 Web，2007 年和朋友共同创建了一个网站，并为了解决这个网站的负载问题（为了避免 MySQL 的低性能），于是亲自定做一个数据库，并于 2009 年开发完成，这个就是 Redis。这个意大利程序员就是 Salvatore Sanfilippo 江湖人称 Redis 之父，大家更习惯称呼他 Antirez。
Redis 技术越来越火爆，其超高的性能，简洁轻量的设计，易上手，分布式架构的支持，在缓存等领域出色的表现造就了它现在的地位。
官方的 Benchmark 数据：测试完成了 50 个并发执行 10W 个请求。设置和获取的值是一个 256 字节字符串。
结果：写的速度是 110000次/s，读的速度是 81000次/s。值得注意的是，该测试结果还是早些年旧机器上的测试结果。如果与今天的机器设备相比，预估可能是以下结果的两倍。
$ redis-benchmark -n 100000 ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <= 0 milliseconds 99.17% <= 1 milliseconds 99.58% <= 2 milliseconds 99.85% <= 3 milliseconds 99.90% <= 6 milliseconds 100.00% <= 9 milliseconds 114293.71 requests per second ====== GET ====== 100000 requests completed in 1.23 seconds 50 parallel clients 3 bytes payload keep alive: 1 43.12% <= 0 milliseconds 96.82% <= 1 milliseconds 98.62% <= 2 milliseconds 100.00% <= 3 milliseconds 81234.77 requests per second为了满足开发市场需求，Redis 支持单机、主从、哨兵、集群多种架构模式，本文带大家详细讲解这几种架构模式的区别。
单机模式
单机模式顾名思义就是安装一个 Redis，启动起来，业务调用即可。例如一些简单的应用，并非必须保证高可用的情况下可以使用该模式。
优点
部署简单；
成本低，无备用节点；
高性能，单机不需要同步数据，数据天然一致性。
缺点
可靠性保证不是很好，单节点有宕机的风险。
单机高性能受限于 CPU 的处理能力，Redis 是单线程的。
单机 Redis 能够承载的 QPS（每秒查询速率）大概在几万左右。取决于业务操作的复杂性，Lua 脚本复杂性就极高。假如是简单的 key value 查询那性能就会很高。
假设上千万、上亿用户同时访问 Redis，QPS 达到 10 万+。这些请求过来，单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上，此时我们可以通过主从复制解决该问题，实现系统的高并发。
主从复制
Redis 的复制（Replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（Master），而通过复制创建出来的复制品则为从服务器（Slave）。 只要主从服务器之间的网络连接正常，主服务器就会将写入自己的数据同步更新给从服务器，从而保证主从服务器的数据相同。
数据的复制是单向的，只能由主节点到从节点，简单理解就是从节点只支持读操作，不允许写操作。主要是读高并发的场景下用主从架构。主从模式需要考虑的问题是：当 Master 节点宕机，需要选举产生一个新的 Master 节点，从而保证服务的高可用性。
优点
Master/Slave 角色方便水平扩展，QPS 增加，增加 Slave 即可；
降低 Master 读压力，转交给 Slave 节点；
主节点宕机，从节点作为主节点的备份可以随时顶上继续提供服务；
缺点
可靠性保证不是很好，主节点故障便无法提供写入服务；
没有解决主节点写的压力；
数据冗余（为了高并发、高可用和高性能，一般是允许有冗余存在的）；
一旦主节点宕机，从节点晋升成主节点，需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预；
主节点的写能力受到单机的限制；
主节点的存储能力受到单机的限制。
哨兵模式