初步了解redis



Redis是一个开源的，使用C语言编写，面向“键/值”对类型数据的分布式NoSQL数据库系统，特点是高性能，持久存储，适应高并发的应用场景。Redis纯粹为应用而产生，它是一个高性能的key-value数据库,并且提供了多种语言的API

性能测试结果表示SET操作每秒钟可达110000次，GET操作每秒81000次（当然不同的服务器配置性能不同）。

redis目前提供五种数据类型：string(字符串),list（链表）, Hash（哈希）,set（集合）及zset(sortedset)（有序集合）

redis提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端

Redis与Memcached的比较.

1.Memcached是多线程，而Redis使用单线程.

2.Memcached使用预分配的内存池的方式，Redis使用现场申请内存的方式来存储数据，并且可以配置虚拟内存。

3.Redis可以实现持久化，主从复制，实现故障恢复。

4.Memcached只是简单的key与value,但是Redis支持数据类型比较多。

Redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到硬盘中来保证持久化。

Redis支持两种持久化方式：

(1)snapshotting(快照)也是默认方式.(把数据做一个备份，将数据存储到文件)

(2)Append-only file(缩写aof)的方式

snapshotting(快照)：快照是默认的持久化方式，这种方式是将内存中数据以快照的方式写到二进制文件中，默认的文件名称为dump.rdb，可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key键修改就自动做快照。

aof方式：由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。aof比快照方式有更好的持久化性，是由于在使用aof时，redis会将每一个收到的写命令都通过write函数追加到文件中，当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。aof方式的持久化也还是有可能会丢失部分修改。可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。

Redis有两种存储方式，默认是snapshot方式，实现方法是定时将内存的快照(snapshot)持久化到硬盘，这种方法缺点是持久化之后如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof方式。

aof即appendonly mode，在写入内存数据的同时将操作命令保存到日志文件，在一个并发更改上万的系统中，命令日志是一个非常庞大的数据，管理维护成本非常高，恢复重建时间会非常长，这样导致失去aof高可用性本意。另外更重要的是Redis是一个内存数据结构模型，所有的优势都是建立在对内存复杂数据结构高效的原子操作上，这样就看出aof是一个非常不协调的部分，其实aof目的主要是数据可靠性及高可用性.

Redis数据快照

数据快照的原理是将整个Redis内存中的所有的数据遍历一遍存储到一个扩展名为rdb的数据文件中，通过save命令

可以调用这个过程。数据快照配置如下:

Save 900 1

Save 300 10

Save 60 10000

以上在redis.conf中的配置指出在多长时间内，有多少次更新操作，就将数据同步到数据文件中，这个可以多个条件进行配合，上面的含义是900秒后有一个key发生改变就执行save,300秒后有10个key发生改变就执行save,60秒有10000个key发生改变就执行save.

数据快照的缺点是持久化之后如果出现系统宕机则会丢失一段数据，因此增加了另外一种追加式的操作日志记录，叫append only file,其日志文件以aof结尾，我们称为aof文件，要开启aof日志的记录，需要在配置文件中进行如下配置: appendonly yes

Appendonly配置不开启，可能在断电时导致一段时间的数据丢失，因为redis本身同步数据文件时按save条件来同步的，所以有的数据会在一段时间内只存在于内存中。

Appendfsync no/always/everysec

no:表示等操作系统进行数据缓存同步到磁盘。性能最好，持久化没有保障。

Always:表示每次更新操作后手动调用fsync()将数据写到磁盘.每次收到写命令就立即强制写入磁盘，最慢的，但是保障完全的持久化。

Everysec:表示每秒同步一次.每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中。

为了定时减小AOF文件的大小，Redis2.4以后增加了自动的bgrewriteaof的功能，Redis会选择一个自认为负载低的情况下执行bgrewriteaof,这个重写AOF文件的过程是很影响性能的。解决方案：Master关闭Save功能，关闭AOF日志功能，以求达到性能最佳。Slave开启Save并开启AOF日志功能，并开启bgrewriteaof功能，不对外提供服务，这样Slave的负载总体上会高于Master负载，但是Master性能达到最好.

Bgrewriterof内部实现：

1.Redis通过fork一个子进程，遍历数据，写入新临时文件

2.父进程继续处理client请求，子进程继续写临时文件。

3.父进程把新写入的AOF写在缓冲区。

4.子进程写完退出，父进程接收退出消息，将缓冲区AOF写入临时文件。

5.临时文件重命名成appendonly.aof,原来文件被覆盖，整个过程完成。

第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于Redis使用单线程服务，如果Master快照文件比较大，那么第一次全量传输会耗费比较长时间，且文件传输过程中Master可能无法提供服务，也就是说服务会中断

Redis数据恢复

当Redis服务器挂掉以后，重启时将按以下优先级恢复数据到内存：

1.如果只配置了AOF，重启时加载AOF文件恢复数据。

2.如果同时配置了RBD和AOF，启动时只加载AOF文件恢复数据。

3.如果只配置了RDB，启动时将加载dump文件恢复数据。