Redis基础

[b]Redis[/b]

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

redis是一个key-value存储系统。和Memcached(简单的k/v类型的数据)类似，redis支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）

Redis 是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类key/value存储的不足(数据类型来多)

Redis中，并不是所有的数据都一直存储在内存中的，这是和Memcached相比一个最大的区别。

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。


[b]redis存储[/b]
redis的存储分为内存存储、磁盘存储(持久化)和log(运行日志)文件三部分，配置文件中有三个参数对其进行配置。

save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。

appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。
因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。

appendfsync no/always/everysec ，appendfsync配置，no表示等操作系统进行数据缓存同步到磁盘，always表示每次更新操作后手动调用fsync()
将数据写到磁盘，everysec表示每秒同步一次。


[b]Redis 事务[/b]
Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：
1.事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2.事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

一个事务从开始到执行会经历以下三个阶段：
1.开始事务。
2.命令入队。
3.执行事务。

它先以 MULTI 开始一个事务，然后将多个命令入队到事务中，最后由 EXEC 命令触发事务，一并执行事务中的所有命令。
redis事务在执行的中途遇到错误，不会回滚，而是继续执行后续命令；（违反原子性）


[b]Redis 发布订阅[/b]
redis将消息类型称为通道(channel)。

当发布者通过publish命令向redis server发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。
这里消息的传递是多对多的。一个client可以订阅多个 channel,也可以向多个channel发送消息。

发布订阅(pub/sub)是一种消息通信模式，redis作为一个pub/sub server，在订阅者和发布者之间起到了消息路由的功能。

订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型.(redis作为一个中心信息逻辑处理（接收、分发）单元)


[b]Redis持久化[/b]
redis支持四种持久化方式，一是 Snapshotting（快照）也是默认方式；二是Append-only file（缩写aof）的方式；三是虚拟内存方式；四是diskstore方式。
[b]（一）Snapshotting[/b]
这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
我们可以配置redis在n秒内如果超过m个key被修改就自动做快照.

快照保存过程：
1. redis调用fork,现在有了子进程和父进程。
2. 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，
当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
3. 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。

另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，
必然会引起大量的磁盘io操作，可能会严重影响性能。

另外由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。


[b]（二）Append-only file[/b]
aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。

当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文
件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。（每次收到写命令就立即强制写入磁盘，每秒钟强制写入磁盘一次，完全依赖os等）

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。

redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下：
1. redis调用fork ，现在有父子两个进程
2. 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。


[b]（三）虚拟内存方式（desprecated）[/b]
在Redis-2.4后虚拟内存功能已经被deprecated了.


[b]（四）diskstore方式[/b]
使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存，内存中放不下的数据采用LRU淘汰。(少用)


[b]Redis主从复制[/b]
通过主从复制可以允许多个slave server拥有和master server相同的数据库副本。
redis主从复制的一些特点：
1.master可以有多个slave
2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构
3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。
相反slave在初次同步数据时则会阻塞不能处理client的请求。
4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave专门用于client的读请求，比如sort操作可以使用slave来处理。
5.可以在master禁用数据持久化，只需要注释掉master配置文件中的所有save配置，然后只在slave上配置数据持久化。

主从复制的过程：
1.当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。
2.无论是第一次同步建立的连接还是连接断开后的重新连接，master都会启动(fork)一个后台进程，将数据库快照保存到文件中。
3.同时master主进程会开始收集新的写命令并缓存起来。
4.后台进程完成写文件后，master就发送文件给slave。
5.slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。
6.接着master就会把缓存的命令转发给slave。（快照后面的命令）
7.而且后续master收到的写命令都会通过开始建立的连接发送给slave。


[b]Redis分布式[/b]
Redis-2.4.15目前没有提供集群的功能，Redis作者在博客中说将在3.0中实现集群机制。目前Redis实现集群的方法主要是采用一
致性哈稀分片（Shard），将不同的key分配到不同的redis server上，达到横向扩展的目的。


参考原文：[url]http://blog.csdn.net/freebird_lb/article/details/7778981[/url]