redis理论知识与简单应用

redis简介
RedisClient提供api实现对redis的操作
只能储存进string类型数据（所有类型都是以string存储的）（利用JsonUtil工具类进行转型）
redis是一个高性能的key-value数据库
redis支持数据的持久化，将内存中的数据储存到磁盘中，重启之后还能用。
redis不仅支持key-value类型，同时还支持list（列表） set（集合） String（字符串） sorted set（有序集合，他是一个接口，里面只有treeset一个实现可用） 


redis的优势
性能极高 读的快 110000次/s  写的快81000次/s
丰富的数据类型   redis支持    redisCommandArgv接口是二进制安全的，我们可以利用此接口实现对二进制的存取。
redis的所有操作都是原子性的（原子性就是要么全部执行，要么全部都不执行），就是单个操作多个操作都是原子性，用MULTI和EXEC包起来。
丰富的特性  redis还支持publish/subscribe，通知，key过期等等。


redis和其他key-value储存有什么不同
redis储存数据结构更复杂，并且提供对他们的原子性操作，这是不同于其他数据库的进化形式。redis的数据类型都是基于基本数据类型的同时对程序员透明，无需进行另外的抽象。
redis储存在内存但可以持久化到磁盘（意思就是想用的时候用，不用了就直接在磁盘里删了），所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。


redis命令按顺序执行的概念（在复杂场景下，提交一次操作可能包含多条redis命令。但业务逻辑是一次操作，但多条redis命令提交，是没法保证在服务端在各个命令中间不插入其他的redis命令。所有一般用事务来保证）


持久化就是在持久态和瞬时态之间转换，在一定时间内不变就是持久化。
持久化RDB    AOF
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文件

简单应用

集群版的就不说了，这次用单机版的。

本次实现对redis的单表存储

jedis接口定义

jedis实现类定义

服务层实现

头脑不太聪明，个人理解如上所述，仅供参考，有不对的或是没有覆盖的知识希望大家能私信留言，立马整改，谢谢各位。