Redis优缺点

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。

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

Redis 与其余 key - value 缓存产品有如下三个特色：

• Redis支持数据的持久化，能够将内存中的数据保持在磁盘中，重启的时候能够再次加载进行使用。
• Redis不只仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

Redis 优点

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操做。
• 原子 – Redis的全部操做都是原子性的，同时Redis还支持对几个操做全并后的原子性执行。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过时等等特性。

Redis与其余key-value存储有什么不一样？

• Redis有着更为复杂的数据结构而且提供对他们的原子性操做，这是一个不一样于其余数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。

• Redis运行在内存中可是能够持久化到磁盘，因此在对不一样数据集进行高速读写时须要权衡内存，应为数据量不能大于硬件内存。在内存数据库方面的另外一个优势是，相比在磁盘上相同的复杂的数据结构，在内存中操做起来很是简单，这样Redis能够作不少内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，由于他们并不须要进行随机访问。  

redis持久化

RDB

RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

redis在进行数据持久化的过程当中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让咱们能够随时来进行备份，由于快照文件老是完整可用的。

对于RDB方式，redis会单首创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操做的，这样就确保了redis极高的性能。

若是须要进行大规模数据的恢复，且对于数据恢复的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。

虽然RDB有很多优势，但它的缺点也是不容忽视的。若是你对数据的完整性很是敏感，那么RDB方式就不太适合你，由于即便你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。因此，redis还提供了另外一种持久化方式，那就是AOF。

AOF

AOF，英文是Append Only File，即只容许追加不容许改写的文件。

如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

咱们经过配置redis.conf中的appendonly yes就能够打开AOF功能。若是有写操做（如SET等），redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），由于在这种状况下，redis仍然能够保持很好的处理性能，即便redis故障，也只会丢失最近1秒钟的数据。

若是在追加日志时，刚好遇到磁盘空间满、inode满或断电等状况致使日志写入不完整，也没有关系，redis提供了redis-check-aof工具，能够用来进行日志修复。

由于采用了追加方式，若是不作任何处理的话，AOF文件会变得愈来愈大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留能够恢复数据的最小指令集。举个例子或许更形象，假如咱们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，彻底能够把这100条指令合并成一条SET指令，这就是重写机制的原理。

在进行AOF重写时，仍然是采用先写临时文件，所有完成后再替换的流程，因此断电、磁盘满等问题都不会影响AOF文件的可用性，这点你们能够放心。

AOF方式的另外一个好处，咱们经过一个“场景再现”来讲明。某同窗在操做redis时，不当心执行了FLUSHALL，致使redis内存中的数据所有被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件尚未被重写（rewrite），咱们就能够用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，而后重启redis，就能够恢复redis的全部数据到FLUSHALL以前的状态了。是否是很神奇，这就是AOF持久化方式的好处之一。可是若是AOF文件已经被重写了，那就没法经过这种方法来恢复数据了。

虽然优势多多，但AOF方式也一样存在缺陷，好比在一样数据规模的状况下，AOF文件要比RDB文件的体积大。并且，AOF方式的恢复速度也要慢于RDB方式。

若是你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了能够恢复现有数据的最少的命令集。

若是运气比较差，AOF文件出现了被写坏的状况，也没必要过度担心，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时能够经过如下步骤来修复出错的文件：

1. 备份被写坏的AOF文件
2. 运行redis-check-aof –fix进行修复
3. 用diff -u来看下两个文件的差别，确认问题点
4. 重启redis，加载修复后的AOF文件

AOF重写

AOF重写的内部运行原理，咱们有必要了解一下。

在重写即将开始之际，redis会建立（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

与此同时，主工做进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样作是保证原有的AOF文件的可用性，避免在重写过程当中出现意外。

当“重写子进程”完成重写工做后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

当追加结束后，redis就会用新AOF文件来代替旧AOF文件，以后再有新的写指令，就都会追加到新的AOF文件中了。

如何选择RDB和AOF

对于咱们应该选择RDB仍是AOF，官方的建议是两个同时使用。这样能够提供更可靠的持久化方案。

主从

用法

像MySQL同样，redis是支持主从同步的，并且也支持一主多从以及多级从结构。

主从结构，一是为了纯粹的冗余备份，二是为了提高读性能，好比很消耗性能的SORT就能够由从服务器来承担。

redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会下降redis的处理性能。

主从架构中，能够考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样能够提升主服务器的处理性能。

在主从架构中，从服务器一般被设置为只读模式，这样能够避免从服务器的数据被误修改。可是从服务器仍然能够接受CONFIG等指令，因此仍是不该该将从服务器直接暴露到不安全的网络环境中。若是必须如此，那能够考虑给重要指令进行重命名，来避免命令被外人误执行。

同步原理

从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来建立一个子进程专门进行数据持久化工做，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。

在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，而后再将其读取到内存中。这个动做完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外，要说的一点是，即便有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，而后把持久化好的RDB文件发给多个下游。在redis2.8版本以前，若是从服务器与主服务器因某些缘由断开链接的话，都会进行一次主从之间的全量的数据同步；而在2.8版本以后，redis支持了效率更高的增量同步策略，这大大下降了链接断开的恢复成本。

主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断以后，从服务器会尝试再次与主服务器链接，一旦链接成功，从服务器就会把“但愿同步的主服务器ID”和“但愿请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和本身的ID匹配，其次会检查“请求的偏移位置”是否存在于本身的缓冲区中，若是二者都知足的话，主服务器就会向从服务器发送增量内容。

增量同步功能，须要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8以后才具备。

redis的事务处理

众所周知，事务是指“一个完整的动做，要么所有执行，要么什么也没有作”。

在聊redis事务处理以前，要先和你们介绍四个redis指令，即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。

1. MULTI用来组装一个事务；
2. EXEC用来执行一个事务；
3. DISCARD用来取消一个事务；
4. WATCH用来监视一些key，一旦这些key在事务执行以前被改变，则取消事务的执行。

经常使用命令

redis的经常使用命令主要分为两个方面、一个是键值相关命令、一个是服务器相关命令

一、键值相关命令

      keys * 取出当前全部的key

      exists name 查看n是否有name这个key

      del name 删除key name

      expire confirm 100 设置confirm这个key100秒过时

      ttl confirm 获取confirm 这个key的有效时长

      select 0 选择到0数据库 redis默认的数据库是0~15一共16个数据库

      move confirm 1 将当前数据库中的key移动到其余的数据库中，这里就是把confire这个key从当前数据库中移动到1中

      persist confirm 移除confirm这个key的过时时间

      randomkey 随机返回数据库里面的一个key

      rename key2 key3 重命名key2 为key3

      type key2 返回key的数据类型

二、服务器相关命令

      ping PONG返回响应是否链接成功

      echo 在命令行打印一些内容

      select 0~15 编号的数据库

      quit  /exit 退出客户端

      dbsize 返回当前数据库中全部key的数量

      info 返回redis的相关信息

      config get dir/* 实时传储收到的请求

      flushdb 删除当前选择数据库中的全部key

      flushall 删除全部数据库中的数据库