标签：
1 nosql的简介
随着互联网Web2.0网站的兴起，传统的关系数据库在应付Web2.0网站，特别是超大规模和高并发的SNS类型的Web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，如：
网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上千万次SQL写数据请求，硬盘IO就已经无法承受了。
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。
在基于Web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像Web服务器和应用服务器那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供7*24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”的需求面前，关系数据库遇到了难以克服的障碍，而对于Web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
（1）数据库事务一致性需求
很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
（2）数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。并不要求这么高的实时性。
（3）对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的Web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构（例如以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销），通常也不存在连接操作。
在大数据存取上具备关系型数据库无法比拟的性能优势，例如：
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的Web2.0时代尤其明显。
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
综上所述，NoSQL的非关系特性使其成为了后Web2.0时代的宠儿，助力大型Web2.0网站的再次起飞，是一项全新的数据库革命性运动。
随着应用对高性能需求的增加，NoSQL逐渐在各大名企的系统架构中生根发芽。时至今日，涌现出的NoSQL产品已经有很多种了，例如Membase、MongoDB、Apache Cassandra、CouchDB等。不过，在国内外互联网巨头例如社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest等名企都不约而同地采用了Redis作为其NoSQL数据库的选择，到底Redis是何方神圣呢？能让如此多的名企为它而痴狂。
按照官方的说法，Redis是一个开源的，使用C语言编写，面向“键/值”（Key/Value）对类型数据的分布式NoSQL数据库系统，特点是高性能，持久存储，适应高并发的应用场景。因此，可以说Redis纯粹为应用而产生，它是一个高性能的key-value数据库，并且还提供了多种语言的API（包括我们的大C#）。那么，也许我们会问：到底性能如何呢？以下是官方的bench-mark数据：
测试完成了50个并发执行100000个请求。
设置和获取的值是一个256字节字符串。
Linux box是运行Linux 2.6,这是X3320 Xeon 2.5 ghz。
文本执行使用loopback接口(127.0.0.1)。
结果:读的速度是110000次/s,写的速度是81000次/s 。（当然不同的服务器配置性能也有所不同）。
和Memcached类似，Redis支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。与Memcached一样，为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步（数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。）。
因此，Redis的出现，很大程度补偿了Memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。
redis是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库。
redis的作者，Salvatore Sanfilippo，来自意大利的西西里岛，现在居住在卡塔尼亚。目前供职于Pivotal公司。他使用的网名是antirez，如果你有兴趣，可以去他的博客逛逛，地址是antirez.com，他的github地址是http://github.com/antirez。
步骤：
1、 将Windows下下载的压缩文件上传到Linux下。我们可以通过filezilla等FTP软件上传，这里通过secureCRT进行上传。步骤如下：
l alt + p
l put c:/redis-2.6.16.tar.gz
l 完成上传
2、 解压文件
l tar –zxvf redis-2.6.16.tar.gz
3、 编译redis
l 进入解压文件夹，cd redis-2.6.16
l 执行make[编译，将.c文件编译为.o文件]
4、 安装
l make PREFIX=/usr/local/redis install
l 安装完后，在/usr/local/redis/bin下有几个可执行文件
redis-benchmark ----性能测试工具
redis-check-aof ----检查修复aof文件 appendonly file
redis-check-dump ----检查快照持久化文件
redis-cli ----命令行客户端
redis-server ----redis服务器启动命令
5、 copy文件
redis启动需要一个配置文件：cp redis.conf /usr/local/redis
6、 启动redis /usr/local/redis/bin… 查看该进程: ps -ef | grep redis 结束该进程：kill -9 pid（进程号）
命令：bin/redis-server redis.conf，这种方式又称为前台启动。后台启动可修redis.conf文件，daemonize no-àyes即可。
redis是一种高级的key-value的存储系统，其中value支持五种数据类型。
1、 字符串（String）
2、 字符串列表（lists）
3、 字符串集合（sets）
4、 有序字符串集合（sorted sets）
5、 哈希（hashs）
而关于key的定义呢，需要大家注意的几点：
1、 key不要太长，最好不要操作1024个字节，这不仅会消耗内存还会降低查找效率
2、 key不要太短，如果太短会降低key的可读性
3、 在项目中，key最好有一个统一的命名规范
字符串类型是Redis中最为基础的数据存储类型，它在Redis中是二进制安全的，这便意味着该类型可以接受任何格式的数据，如JPEG图像数据或Json对象描述信息等。在Redis中字符串类型的Value最多可以容纳的数据长度是512M。
l set key value：设定key持有指定的字符串value，如果该key存在则进行覆盖操作。总是返回”OK”
l get key：获取key的value。如果与该key关联的value不是String类型，redis将返回错误信息，因为get命令只能用于获取String value；如果该key不存在，返回null。
l getset key value：先获取该key的值，然后在设置该key的值。
l incr key：将指定的key的value原子性的递增1.如果该key不存在，其初始值为0，在incr之后其值为1。如果value的值不能转成整型，如hello，该操作将执行失败并返回相应的错误信息。
l decr key：将指定的key的value原子性的递减1.如果该key不存在，其初始值为0，在incr之后其值为-1。如果value的值不能转成整型，如hello，该操作将执行失败并返回相应的错误信息。
l incrby key increment：将指定的key的value原子性增加increment，如果该key不存在，器初始值为0，在incrby之后，该值为increment。如果该值不能转成整型，如hello则失败并返回错误信息
l decrby key decrement：将指定的key的value原子性减少decrement，如果该key不存在，器初始值为0，在decrby之后，该值为decrement。如果该值不能转成整型，如hello则失败并返回错误信息
l append key value：如果该key存在，则在原有的value后追加该值；如果该key不存在，则重新创建一个key/value
在Redis中，List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295。
从元素插入和删除的效率视角来看，如果我们是在链表的两头插入或删除元素，这将会是非常高效的操作，即使链表中已经存储了百万条记录，该操作也可以在常量时间内完成。然而需要说明的是，如果元素插入或删除操作是作用于链表中间，那将会是非常低效的。相信对于有良好数据结构基础的开发者而言，这一点并不难理解。
1、 ArrayList使用数组方式存储数据，所以根据索引查询数据速度快，而新增或者删除元素时需要设计到位移操作，所以比较慢。
2、 LinkedList使用双向链接方式存储数据，每个元素都记录前后元素的指针，所以插入、删除数据时只是更改前后元素的指针指向即可，速度非常快，然后通过下标查询元素时需要从头开始索引，所以比较慢。
3、 双向链表中添加数据
4、 双向链表中删除数据
5、 时间复杂度
l lpush key values[value1 value2…]：在指定的key所关联的list的头部插入所有的values，如果该key不存在，该命令在插入的之前创建一个与该key关联的空链表，之后再向该链表的头部插入数据。插入成功，返回元素的个数。
l lpushx key value：仅当参数中指定的key存在时（如果与key管理的list中没有值时，则该key是不存在的）在指定的key所关联的list的头部插入value。
l lrange key start end：获取链表中从start到end的元素的值，start、end可为负数，若为-1则表示链表尾部的元素，-2则表示倒数第二个，依次类推…
l lpop key：返回并弹出指定的key关联的链表中的第一个元素，即头部元素。如果该key不存在，返回nil；若key存在，则返回链表的头部元素。
l llen key：返回指定的key关联的链表中的元素的数量。
l lrem key count value：删除count个值为value的元素，如果count大于0，从头向尾遍历并删除count个值为value的元素，如果count小于0，则从尾向头遍历并删除。如果count等于0，则删除链表中所有等于value的元素。
l lset key index value：设置链表中的index的脚标的元素值，0代表链表的头元素，-1代表链表的尾元素。操作链表的脚标则放回错误信息。
l linsert key before|after pivot value：在pivot元素前或者后插入value这个元素。
l rpush key values[value1、value2…]：在该list的尾部添加元素。
l rpushx key value’：在该list的尾部添加元素
l rpop key：从尾部弹出元素。
l rpoplpush resource destination：将链表中的尾部元素弹出并添加到头部。[循环操作]
rpoplpush的使用场景：
Redis链表经常会被用于消息队列的服务，以完成多程序之间的消息交换。假设一个应用程序正在执行LPUSH操作向链表中添加新的元素，我们通常将这样的程序称之为"生产者(Producer)"，而另外一个应用程序正在执行RPOP操作从链表中取出元素，我们称这样的程序为"消费者(Consumer)"。如果此时，消费者程序在取出消息元素后立刻崩溃，由于该消息已经被取出且没有被正常处理，那么我们就可以认为该消息已经丢失，由此可能会导致业务数据丢失，或业务状态的不一致等现象的发生。然而通过使用RPOPLPUSH命令，消费者程序在从主消息队列中取出消息之后再将其插入到备份队列中，直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时我们还可以提供一个守护进程，当发现备份队列中的消息过期时，可以重新将其再放回到主消息队列中，以便其它的消费者程序继续处理。
Redis中的Hashes类型可以看成具有String Key和String Value的map容器。所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。
l hset key field value：为指定的key设定field/value对（键值对）。
l hget key field：返回指定的key中的field的值
l hexists key field：判断指定的key中的filed是否存在
l hlen key：获取key所包含的field的数量
l hincrby key field increment：设置key中filed的值增加increment，如：age增加20
l hmset key fields：设置key中的多个filed/value
l hmget key fileds：获取key中的多个filed的值
在Redis中，我们可以将Set类型看作为没有排序的字符集合，和List类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为O(1)，即常量时间内完成次操作。Set可包含的最大元素数量是4294967295。
和List类型不同的是，Set集合中不允许出现重复的元素，这一点和C++标准库中的set容器是完全相同的。换句话说，如果多次添加相同元素，Set中将仅保留该元素的一份拷贝。和List类型相比，Set类型在功能上还存在着一个非常重要的特性，即在服务器端完成多个Sets之间的聚合计算操作，如unions、intersections和differences。由于这些操作均在服务端完成，因此效率极高，而且也节省了大量的网络IO开销。
l sad key values[value1、value2…]：向set中添加数据，如果该key的值已有则不会重复添加
l smembers key：获取set中所有的成员
l scard key：获取set中成员的数量
l sismember key member：判断参数中指定的成员是否在该set中，1表示存在，0表示不存在或者该key本身就不存在
l srem key members[member1、member2…]：删除set中指定的成员
l srandmember key：随机返回set中的一个成员
l sdiff key[sdiff key1 key2…]：返回key1与key2中相差的成员，而且与key的顺序有关。即返回差集。
l sdiffstore destination key[key1、key2…]：将key1、key2相差的成员存储在destination上
l sinter key[key1,key2…]：返回交集。
l sinterstore destination key[key…]：将返回的交集存储在destination上
l sunion key[key1、key2…]：返回并集。
l sunionstore destination key[key…]：将返回的并集存储在destination上
1、可以使用Redis的Set数据类型跟踪一些唯一性数据，比如访问某一博客的唯一IP地址信息。对于此场景，我们仅需在每次访问该博客时将访问者的IP存入Redis中，Set数据类型会自动保证IP地址的唯一性。
2、充分利用Set类型的服务端聚合操作方便、高效的特性，可以用于维护数据对象之间的关联关系。比如所有购买某一电子设备的客户ID被存储在一个指定的Set中，而购买另外一种电子产品的客户ID被存储在另外一个Set中，如果此时我们想获取有哪些客户同时购买了这两种商品时，Set的intersections命令就可以充分发挥它的方便和效率的优势了。
Sorted-Sets和Sets类型极为相似，它们都是字符串的集合，都不允许重复的成员出现在一个Set中。它们之间的主要差别是Sorted-Sets中的每一个成员都会有一个分数(score)与之关联，Redis正是通过分数来为集合中的成员进行从小到大的排序。然而需要额外指出的是，尽管Sorted-Sets中的成员必须是唯一的，但是分数(score)却是可以重复的。
在Sorted-Set中添加、删除或更新一个成员都是非常快速的操作，其时间复杂度为集合中成员数量的对数。由于Sorted-Sets中的成员在集合中的位置是有序的，因此，即便是访问位于集合中部的成员也仍然是非常高效的。事实上，Redis所具有的这一特征在很多其它类型的数据库中是很难实现的，换句话说，在该点上要想达到和Redis同样的高效，在其它数据库中进行建模是非常困难的。
例如：游戏排名、微博热点话题等使用场景。
l zadd key score member score2 member2 … ：将所有成员以及该成员的分数存放到sorted-set中
l zcard key：获取集合中的成员数量
l zcount key min max：获取分数在[min,max]之间的成员
l zincrby key increment member：设置指定成员的增加的分数。
l zrange key start end [withscores]：获取集合中脚标为start-end的成员，[withscores]参数表明返回的成员包含其分数。
l zrangebyscore key min max [withscores] [limit offset count]：返回分数在[min,max]的成员并按照分数从低到高排序。[withscores]：显示分数；[limit offset count]：offset，表明从脚标为offset的元素开始并返回count个成员。
l zrank key member：返回成员在集合中的位置。
l zrem key member[member…]：移除集合中指定的成员，可以指定多个成员。
l zscore key member：返回指定成员的分数
1、可以用于一个大型在线游戏的积分排行榜。每当玩家的分数发生变化时，可以执行ZADD命令更新玩家的分数，此后再通过ZRANGE命令获取积分TOPTEN的用户信息。当然我们也可以利用ZRANK命令通过username来获取玩家的排行信息。最后我们将组合使用ZRANGE和ZRANK命令快速的获取和某个玩家积分相近的其他用户的信息。
2、Sorted-Sets类型还可用于构建索引数据。
l keys pattern：获取所有与pattern匹配的key，返回所有与该key匹配的keys。*表示任意一个或多个字符，?表示任意字符，[abc]表示方括号中任意一个字母
l del key[key1、key2…]：删除指定的key
l exists key：判断该key是否存在，1代表存在，0代表不存在
l rename key newkey：为当前的key重命名
l ttl key：获取该key所剩的超时时间，如果不存在或没有超时设置，返回-1
l type key：获取指定key的类型。该命令将以字符串的格式返回。返回的字符串为string、list、set、hash和zset，如果key不存在返回none。
subscribe channel：订阅频道，例：subscribe mychat，订阅mychat这个频道
psubscribe channel*：批量订阅频道，例：psubscribe s*，订阅以”s”开头的频道
publish channel content：在指定的频道中发布消息，如 publish mychat ‘today is a newday’
一个Redis实例可以包括多个数据库，客户端可以指定连接某个redis实例的哪个数据库，就好比一个mysql中创建多个数据库，客户端连接时指定连接哪个数据库。
一个redis实例最多可提供16个数据库，下标从0到15，客户端默认连接第0号数据库，也可以通过select选择连接哪个数据库，如下连接1号库：
连接0号数据库：
move newkey 1：将当前库的key移植到1号库中
在0号数据库存储数据，在1号数据库执行清空数据命令却把0号数据库的数据给清空了：
建议：不同的应用系统要使用不同的redis实例而不是使用同一个redis实例下的不同数据库。
和众多其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。
1、 在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行
2、 和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。
3、 我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
4、 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。
5、 当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。
l multi：开启事务用于标记事务的开始，其后执行的命令都将被存入命令队列，直到执行EXEC时，这些命令才会被原子的执行，类似与关系型数据库中的：begin transaction
l exec：提交事务，类似与关系型数据库中的：commit
l discard：事务回滚，类似与关系型数据库中的：rollback
同之前我们讲过的solrj一样，通过jedis提供的API我们连接redis服务并对其数据进行维护。而且其API与命令基本一致。
1、 RDB持久化（默认支持，无需配置）
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
2、 AOF持久化
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
3、 无持久化
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
4、 redis同时使用RDB和AOF
1、 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2、 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上
3、 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4、 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
1、 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2、 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟
l save 900 1 #每900秒(15分钟)至少有1个key发生变化，则dump内存快照。
l save 300 10 #每300秒(5分钟)至少有10个key发生变化，则dump内存快照
l save 60 10000 #每60秒(1分钟)至少有10000个key发生变化，则dump内存快照
1、 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2、 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3、 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4、 AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
1、 对于相同数量的数据集而言，AOF文件通常要大于RDB文件
2、 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
dir /var/redis：可以指定生成的AOF文件和dump文件的位置
appendonly yes：开启AOF
appendfsync always/everysec/no：AOF策略
l always #每次有数据修改发生时都会写入AOF文件
l everysec #每秒钟同步一次，该策略为AOF的缺省策略
l no #从不同步。高效但是数据不会被持久化
重写AOF：若不满足重写条件时，可以手动重写，命令：bgrewriteaof
1、 flushall操作 清空数据库
2、 及时关闭redis服务器（防止dump.rdb）。 shutdown nosave
3、 编辑aof文件，将日志中的flushall命令删除并重启服务即可
1、 复制一份redis.conf文件并修改名称，如：cp redis.conf redis6380.conf
2、 修改redis6380.conf文件中的
l 端口号
l 进程id号（pidfile /var/run/redis6380.pid）
l slaveof：主从复制信息
l 存放aof、rdb文件的目录。
3、 启动从服务器：bin/redis-cli –p 6380
完成主从数据复制。
1、 取最新N个数据的操作
比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的5000条评论的ID放在Redis的List集合中，并将超出集合部分从数据库获取
(1)使用LPUSH latest.comments <ID>命令，向list集合中插入数据
(2)插入完成后再用LTRIM latest.comments 0 5000命令使其永远只保存最近5000个ID
(3)然后我们在客户端获取某一页评论时可以用下面的逻辑（伪代码）
# 伪代码
FUNCTION get_latest_comments(start, num_items):
id_list = redis.lrange("latest.comments", start, start+num_items-1)
IF id_list.length < num_items
id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END
如果你还有不同的筛选维度，比如某个分类的最新N条，那么你可以再建一个按此分类的List，只存ID的话，Redis是非常高效的。
2、 排行榜应用，取TOP N操作
这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的sorted set出马了，将你要排序的值设置成sorted set的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。
3、 需要精准设定过期时间的应用
比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把 Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。
4、 计数器应用
Redis的命令都是原子性的，你可以轻松地利用INCR，DECR命令来构建计数器系统。
5、 Uniq操作，获取某段时间所有数据排重值
这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就行了，set意为集合，所以会自动排重。
6、 实时系统，反垃圾系统
通过上面说到的set功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。没有做不到，只有想不到。
7、 Pub/Sub构建实时消息系统
Redis的Pub/Sub系统可以构建实时的消息系统，比如很多用Pub/Sub构建的实时聊天系统的例子。
8、 构建队列系统
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。
标签：
原文地址：http://www.cnblogs.com/wang-meng/p/5808712.html
