Redis 相关知识*(1)*
1.什么是Redis?
Redis是一个基于内存、可持久化、键值对模式的NoSQl数据库.
优点是速度快(单线程,IO多路复用)、高性能、高可靠。可持久化（rdb、aof),支持丰富的数据结构。
2.Redis能用来做什么？
1.分布式锁
主要利用redis的setnx命令来进行，setnx: "set if not exists",如果不存在则成功
其他的实现方式：数据库、zookeeper
2.缓存
由于redis数据放在内存所以访问速度快、支持的数据类型比较丰富，所以redis很适用来缓存数据，这里一般是做分布式缓存，本地缓存不需要用redis。
其他的实现方式： 自定义数据结构（例如java里的hashmap）
3.保存现实数据
redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。
4.计数器相关问题
redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
5.排行榜相关问题
redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
3.Redis的5种数据类型?
1.字符串String
字符串类型是Redis中最基本的数据存储类型，它是一个由字节组成的序列，在Rediss中是二进制安全的。这意味着该类型可以接受任何格式数据，如JPEG图像数据和Json对象说明信息。它是标准的key-value，通常用于存储字符串、整数和浮点。Value可容纳高达512MB的数据。应用程序场景：非常常见的场景用于计算站点访问量、当前在线人数等。incr命令(++操作)
2.散列hash
在Memcached中,我们经常将一些结构化的信息打包成hashmap,在客户端序列化存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去,这样不仅增大了开销,，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。应用程序方案：存储部分更改数据，如用户信息、会话共享。
3.列表list
Redis的列表允许用户从序列的两端推入或者弹出元素，列表由多个字符串值组成的有序可重复的序列，是链表结构，所以向列表两端添加元素的时间复杂度为0(1)，获取越接近两端的元素速度就越快。这意味着，即使有数以千万计的元素列表，也可以极快地获得10条记录在头部或尾部。可列入名单的要素最多只有4294967295个。应用场景：（1）最新消息排行榜。（2）消息队列，以完成多程序之间的消息交换。可以用push操作将任务存在list中（生产者），然后线程在用pop操作将任务取出进行执行。（消费者）
4.集合set
所谓集合就是一堆不重复值的组合，并且是没有顺序的。在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还提供了诸如collection、union和differences等操作，使得实现诸如commandism、poperhike、secondfriends这样的功能变得很容易，或者选择是将结果返回给客户机，还是将它们保存到使用不同命令的新的集合中。
5.有序集合sort sets
Redis zset和set一样也是string类型元素的集合，且不允许重复的成员。不同之处在于，每个元素都与双类型的分数相关联。Redis使用分数将集合的成员从小到大排序。zset的成员是唯一的，但是grazentra的分数可以重复。sorted set是插入有序的，即自动排序。常用命令：zadd、zrange、zrem、zcard等。当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。应用举例：（1）例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。（2）排行榜应用，根据得分列出topN的用户等。
4.Redis的持久化机制?
关于Redis目前都是使用Redis作为数据缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。
一、redis持久化----两种方式
1、redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
2、RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
3、AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
4、其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
5、如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。
二、redis持久化----RDB
1、RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
2、redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
3、对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
4、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
5、虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。
三、redis持久化----AOF
1、AOF，英文是Append Only File，即只允许追加不允许改写的文件。
2、如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。
3、我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。
4、默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。
5、如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。
6、因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。
7、在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。
8、AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。
9、虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。
如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。
10、如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：
1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异，确认问题点
4.重启redis，加载修复后的AOF文件
四、redis持久化----AOF重写
1、AOF重写的内部运行原理，我们有必要了解一下。
2、在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
3、与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
4、当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
5、当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。
五、redis持久化----如何选择RDB和AOF
1、对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。
2、redis的备份和还原，可以借助第三方的工具redis-dump。
六、Redis的两种持久化方式也有明显的缺点
1、RDB需要定时持久化，风险是可能会丢两次持久之间的数据，量可能很大。
2、AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程。
