标签：des style blog http io ar color os 使用
Redis是一个开源、支持网络、基于内存、可持久化的日志型、key-value键值对数据库，使用ANSI C编写。并提供多种语言的API。
Redis使用标准C编写实现，而且将所有数据加载到内存中，所以速度非常快。官方提供的数据表明，在一个普通的Linux机器上，Redis读写速度分别达到81000/s和110000/s。
由于所有数据保持在内存中，所以对数据的更新将异步地保存到磁盘上，Redis提供了一些策略来保存数据，比如根据时间或更新次数。
可以将Redis看做“数据结构服务器”。目前，Redis支持5种数据结构。
Redis对不同数据类型的操作是自动的，因此设置或增加key值，从一个集合中增加或删除一个元素都能安全的操作。
Redis支持多种语言，诸如Ruby, Python, Twisted Python, PHP, Erlang, Tcl, Perl, Lua, Java, Scala, Clojure等。
Redis支持简单而快速的主-从复制。官方提供了一个数据，Slave在21秒即完成了对Amazon网站10G key set的复制。
很容易将数据分布到多个Redis实例中，但这主要看该语言是否支持。目前支持Sharding功能的语言只有PHP、Ruby和Scala。
当数据依赖不再需要，Redis这种基于内存的性质，与在执行一个事务时将每个变化都写入硬盘的数据库系统相比就显得执行效率非常高。写与读操作速度没有明显差别。
Redis的外围由一个键、值映射的字典构成。与其他非关系型数据库主要不同在于：Redis中值的类型不仅限于字符串，还支持这些抽象数据类型：string,list,set,zset,hash.值的类型决定了值本身支持的操作。Redis支持不同无序、有序的列表，无序、有序的集合间的交集、并集等高级服务器端原子操作。
string是redis最基本的类型，而且string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
从内部实现来看其实string可以看作byte数组，最大上限是1G字节。string类型的值也可视为integer，从而可以让“incr”命令族操作，这种情况下，该integer的值限制在64位有符号数
在list、set和zset中包含的独立的元素类型都是string类型
redis的list类型其实就是一个每个子元素都是string类型的双向链表，所以[lr]push和[lr]pop命令的算法时间复杂度都是O(1)，另外list会记录链表的长度，所以llen操作也是O(1).可以通过push,pop操作从链表的头部或者尾部添加删除元素。这使得list既可以用作栈，也可以用作队列。
list的最大长度是2^32-1个元素,约等于4亿个。
set就是redis string的无序集合，不允许有重复元素。对set的操作有交集、并集、差集等
set的最大元素数是2^32-1，约等于4亿。
zset是set的一个升级版本，在set的基础上增加了一个顺序属性，这一属性在添加修改元素时可以指定，每次指定后zset会自动安照指定值重新调整顺序。可以理解为一张表，一列存value，一列存顺序。操作中的key理解为zset的名字。
zset的最大元素数是2^32-1，约等于4亿。
对于已经有序的zset，仍然可以使用sort命令，通过指定asc|desc参数对其进行排序。
键、值都为字符串的哈希表(hash)。redis Hash类型对数据域和值提供了映射，这一结构很方便表示对象。
在Hash中可以只保存有限的几个“域”，而不是将所有的“域”作为key，这可以节省内存
Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
Redis的复制功能是完全建立在基于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生，那么首先要注意你的系统内存容量规划——物理内存使用量不要超过3/5
配置slave服务器很简单，只需要在配置文件中加入如下配置
slaveof 192.168.1.1 6379 #指定master的ip和端口
下面是关于redis主从复制的一些特点
主从复制的过程
Redis复制流程在Slave和Master端各自是一套状态机流转，涉及的状态信息是：
Slave 端：
Master端：
整个状态机流程过程如下：
Redis复制机制的缺陷:Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来非常多的问题
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置
client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求，所以不推荐使用；每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
另外由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式
保存过程如下
缺点：是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。
aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。
有三种方式如下（默认是：每秒fsync一次）
持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。
保存过程如下
缺点：log文件体积过大时系统重启恢复数据非常慢，几十G的数据可能要几小时才能加载完；每条命令都要写log，读写性能会有所下降
标签：des style blog http io ar color os 使用
原文地址：http://blog.csdn.net/shimazhuge/article/details/41946209
