提到redis，首先要谈一下noSQL。

1、什么是noSQL？

　　NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它可以作为关系型数据库的良好补充。传统关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

　　（1）High performance - 对数据库高并发读写的需求：web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

　　（2）Huge Storage - 对海量数据的高效率存储和访问的需求：类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

　　（3）High Scalability&& High Availability- 对数据库的高可扩展性和高可用性的需求：在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

　　NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

　　NoSQL数据库的四大分类如下：

　　● 键值(Key-Value)存储数据库

　　　　相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB

　　　　典型应用： 内容缓存，主要用于处理大量数据的高访问负载。 

　　　　数据模型： 一系列键值对

　　　　优势： 快速查询

　　　　劣势： 存储的数据缺少结构化

　　● 列存储数据库

　　　　相关产品：Cassandra, HBase, Riak

　　　　典型应用：分布式的文件系统

　　　　数据模型：以列簇式存储，将同一列数据存在一起

　　　　优势：查找速度快，可扩展性强，更容易进行分布式扩展

　　　　劣势：功能相对局限

　　● 文档型数据库

　　　　相关产品：CouchDB、MongoDB

　　　　典型应用：Web应用（与Key-Value类似，Value是结构化的）

　　　　数据模型： 一系列键值对

　　　　优势：数据结构要求不严格

　　　　劣势： 查询性能不高，而且缺乏统一的查询语法

　　● 图形(Graph)数据库

　　　　相关数据库：Neo4J、InfoGrid、Infinite Graph

　　　　典型应用：社交网络

　　　　数据模型：图结构

　　　　优势：利用图结构相关算法。

　　　　劣势：需要对整个图做计算才能得出结果，不容易做分布式的集群方案。

　　redis就是noSQL数据库的一种。

2、redis的应用场景。

　　Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求，目前为止Redis支持的键值数据类型有：字符串类型、散列类型、列表类型、集合类型、有序集合类型。

　　80%的用户请求都集中在20%的热门数据上，所以我们要将这20%的数据放在缓存里。redis可以作为系统缓存（数据查询、短连接、新闻内容、商品内容等）；还可以做分布式集群架构中的session分离、聊天室的在线好友列表、任务队列（秒杀、抢购、12306）、应用排行榜、网站访问统计等都有应用。

3、redis的持久化方案

　　Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。

　　Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。

　　RDB持久化

　　　　RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

　　　　RDB是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：

　　　　　　save 900 1

　　　　　　save 300 10

　　　　　　save 60 10000

　　　　save 开头的一行就是持久化配置，可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系，“save 900 1”表示15分钟（900秒钟）内至少1个键被更改则进行快照，“save 300 10”表示5分钟（300秒）内至少10个键被更改则进行快照。

　　　　在redis.conf中：

　　　　配置dir指定rdb快照文件的位置

　　　　配置dbfilenam指定rdb快照文件的名称

　　　　Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。

　　问题总结：

　　　　通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

　　AOF持久化

默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

　　　　　　appendonly yes

　　　　开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：appendfilename appendonly.aof

　　Redis的持久化方案应该怎么选择？

　　Redis中数据两种情况：

　　一、redis中存储的是从数据库中取出的内容，不使用持久化方案；

　　二、先向redis中写入数据，通过持久化方案向数据库中保存，这就需要使用持久化方案。如果数据不是非常重要，可以选择RDB；否则使用AOF方案。

4、主从复制

　　持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障，如下图：

　　● 说明：

　　　　主redis中的数据有两个副本（replication）即从redis1和从redis2，即使一台redis服务器宕机其它两台redis服务也可以继续提供服务。

　　　　主redis中的数据和从redis上的数据保持实时同步，当主redis写入数据时通过主从复制机制会复制到两个从redis服务上。

　　　　只有一个主redis，可以有多个从redis。主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求。

　　　　一个redis还可以即是主又是从，如下图：