Redis持久化
1.概述：Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，
需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。
2.Rdb持久化(默认支持，无需配置）
*该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
3.AOF持久化
*该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
4.无持久化
*我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
*注意：redis可以同时使用RDB和AOF
RDB持久化机制
1.RDB持久化机制优点
*一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
*对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上
*性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork（分叉）出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
2.RDB持久化机制缺点
*如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
*由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟
3.redis.window.config
# after 900 sec (15 min) if at least 1 key changed //每900秒(15分钟)至少有1个key发生变化，则dump内存快照
# after 300 sec (5 min) if at least 10 keys changed //每300秒(5分钟)至少有10个key发生变化，则dump内存快照
# after 60 sec if at least 10000 keys changed //每60秒(1分钟)至少有10000个key发生变化，则dump内存快照
AOF持久化存储机制
1.AOF持久化机制优点
*该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即
记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
*由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
*如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
*AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建
2.AOF持久化机制缺点
*对于相同数量的数据集而言，AOF文件通常要大于RDB文件
*根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
3.Aof持久化配置
############################## APPEND ONLY MODE ###############################
By default Redis asynchronously dumps the dataset on disk. This mode is
good enough in many applications, but an issue with the Redis process or
a power outage may result into a few minutes of writes lost (depending on
the configured save points).
The Append Only File is an alternative persistence mode that provides
much better durability. For instance using the default data fsync policy
(see later in the config file) Redis can lose just one second of writes in a
dramatic event like a server power outage, or a single write if something
wrong with the Redis process itself happens, but the operating system is
still running correctly.
AOF and RDB persistence can be enabled at the same time without problems.
If the AOF is enabled on startup Redis will load the AOF, that is the file
with the better durability guarantees.
Please check http://redis.io/topics/persistence for more information.
appendonly no
将appendonly修改为yes，开启aof持久化机制，默认会在目录下产生一个appendonly.aof文件
4.AOF持久化时机
# appendfsync always 每执行一次更新命令，持久化一次
# appendfsync everysec 每秒钟持久化一次
# appendfsync no 不持久化
Jedis的基本使用
1.Jedis常用API
*new Jedis(host, port) 创建jedis对象，参数host是redis服务器地址，参数port是redis服务端口
*set(key,value) 设置字符串类型的数据
*get(key) 获得字符串类型的数据
*hset(key,field,value) 设置哈希类型的数据
*hget(key,field) 获得哈希类型的数据
*lpush(key,values) 设置列表类型的数据
*lpop(key) 列表左面弹栈
*del(key) 删除指定的key
2.Jedis的基本操作
/**
-
第一个Demo版
*/
public class RedisUtilSnapshot {
public static void main(String[] args) {
//1. 导入jar包
//2. 建立redis的连接
Jedis connection = new Jedis("localhost", 6379);//3. 使用该连接, 执行命令 connection.set("test", "桂朝阳"); System.out.println(connection.get("test")); //4. 关闭连接 connection.close();}
}
Jedis连接池的基本概念
*jedis连接资源的创建与销毁是很消耗程序性能，所以jedis为我们提供了jedis的池化技术，jedisPool在创建时初始化一些连接资源存储到连接池中，
使用jedis连接资源时不需要创建，而是从连接池中获取一个资源进行redis的操作，使用完毕后，不需要销毁该jedis连接资源，而是将该资源归还给连接池，供其他请求使用。