Redis持久化，事务，主从复制

一：Redis配置文件介绍

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口，默认端口为6379，为什么选用6379作为默认端口？因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
  timeout 300
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
  loglevel verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save
  Redis默认配置文件中提供了三个条件：
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
 10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名，默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
  slaveof
14. 当master服务设置了密码保护时，slav服务连接master的密码
  masterauth
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
  maxmemory
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名，默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件，共有3个可选值： 
  no：表示等操作系统进行数据缓存同步到磁盘（快） 
  always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
  everysec：表示每秒同步一次（折衷，默认值）
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中
   vm-enabled no
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
  activerehashing yes
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf

二：Redis持久化

1.RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。RDB保存的是dump.rdb文件

Fork：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是一个全新的进程，并作为原进程的子进程

配置文件位置:

测试：修改300秒10次为120秒10次，重启Redis，删除Reds安装目录下/bin/dump.rdb文件

在两分钟内连续添加10个以上的key，Redis就会创建dump.rdb文件

注：如果Redis在关闭的时候将空数据刷入dump.rdb文件就会导致下一次重启Redis无法恢复数据，这时可以通过复制保留dump.rdb文件，在原来的dump.rdb为空时，使用复制的这一份重新恢复数据。

通过save(阻塞保存)/bgsave(后台异步保存)命令可以修改一次key就保存一次dump.rdb文件

优势：适合大规模的数据恢复，对数据完整性和一致性要求不高

劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

其他配置：

• stop-writes-on-bgsave-error：如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
•  rdbcompression：rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
•  rdbchecksum：rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
  10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
•  dbfilename：保存的文件名
• dir：保存的路径，默认Redis启动时所在路径

总结：

2.AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，Aof保存的是appendonly.aof文件

配置文件：

这时重启Redis，设置键值，就会生成appendonly.aof，当关闭redis后，在启动就会恢复数据

胡乱修改appendonly.aof文件，并且同时存在dump.rdb文件，重启Redis，发现无法启动，就说明当appendonly.aof与dump.rdb文件同时存在时，Redis启动首选appendonly.aof，那么如果过appendonly.aof文件错乱时，如何修改为正常呢？通过：redis-check-aof --fix appendonly.aof修改。

rewrite：（解决appendonly.aof文件过大的情况）

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

 

其他配置参数：

appendfsync：（持久策略）

• always：同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
• everysec：出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失
• no：不配置

no-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。

auto-aof-rewrite-min-size：设置重写的基准值

auto-aof-rewrite-percentage：设置重写的基准值

AOF优势：

• 每修改同步：appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
• 每秒同步：appendfsync everysec    异步操作，每秒记录   如果一秒内宕机，有数据丢失

AOF劣势：

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

总结：

最终在Redis的持久化中使用哪一个呢？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储，AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

同时开启两种持久化方案：在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整，RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

最终建议： 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果开启 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不开启AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构

三：Redis事务

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞，一个队列中，一次性、顺序性、排他性的执行一系列命令

1.事务相关常用命令：

2.案例一：正常执行

3.案例二：放弃事务

4.案例三：一个语句执行失败，队列中语句全部失效

5.案例四：哪条语句出错，放弃执行哪条语句

案例三与案例四的区别在于，一个还没有加入到队列就出错，一个加入到队列后，执行时出错。

6.案例五：watch监控

1）悲观锁：悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

2）乐观锁：乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，乐观锁策略:提交版本必须大于记录当前版本才能执行更新

3）CAS：Compare-and-Swap比较并替换

4）初始化信用卡可用余额和欠额

无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内

执行期间有篡改

unwatch

一旦执行了exec之前加的监控锁都会被取消掉了，程序提交修改时捕获异常，unwatch后重新修改

5）总结：Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行，通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

7.事务三阶段：

• 开启：以MULTI开始一个事务
• 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
• 执行：由EXEC命令触发事务

8.事务三特性：

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
• 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

四：Redis的发布订阅机制

进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

常用命令：

案例1：订阅多个

案例2：通配符订阅

五：Redis主从复制

行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主，实现读写分离，容灾恢复。

1）配置：(一主二从)

复制三分redis.conf修改对应配置文件为

reids6379.conf

daemonize yes
port 6379
pidfile /var/run/redis6379.pid
dbfilename dump6379.rdb
logfile "6379.log"

redis6380.conf

daemonize yes
port 6380
pidfile /var/run/redis6380.pid
dbfilename dump6380.rdb
logfile "6380.log"

redis6381.conf

daemonize yes
port 6381
pidfile /var/run/redis6381.pid
dbfilename dump6381.rdb
logfile "6381.log"

配置完成后，分别使用对应的配置文件启动redis，使用info replication查看

发现三者都是master节点，使用SLAVEOF 127.0.0.1 6379命令使6380,6381两个节点变为从节点

主节点插入后，从节点无法插入

主节点死亡，从节点依旧是从节点

主节点重启，从节点重新上挂

从节点死亡后，重启不会变为从节点（除非配置到配置文件），需要重新通过SLAVEOF 127.0.0.1 6379加入主节点

通过info replication查看主节点发现其下面挂着两个从节点，现在将6381挂载6380节点下，实现"薪火相传"

上面说过，主节点挂点后，两个从节点依旧是slave节点，现在要求，主节点挂掉后，从节点上位

复制原理：slave启动成功连接到master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步，全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步，但是只要是重新连接master,一次完全同步（全量复制)将被自动执行，第一次执行全量复制。

2）哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

修改6379依旧带着6380,6381两个从节点，自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错，在其中配置 sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

上面最后一个数字1，表示主节点6379挂掉后，从节点谁的票数>1票，谁就是主机节点。

启动哨兵模式：redis-sentinel ../sentinel.conf 

挂掉主节点，哨兵模式自动选举主节点

原主节点恢复后，就会变为从节点

3）主从复制缺点： 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

六：Jedis相关操作

1.redis事务

public class RedisTest {
	public boolean transMethod() {
		Jedis jedis = new Jedis("192.168.25.128", 6380);
		int balance;// 可用余额
		int debt;// 欠额
		int amtToSubtract = 10;// 实刷额度

		jedis.watch("balance");
//		jedis.set("balance", "5");// 篡改
		try {
			Thread.sleep(7000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		balance = Integer.parseInt(jedis.get("balance"));
		if (balance < amtToSubtract) {
			jedis.unwatch();
			System.out.println("modify");
			return false;
		} else {
			System.out.println("***********transaction");
			Transaction transaction = jedis.multi();
			transaction.decrBy("balance", amtToSubtract);
			transaction.incrBy("debt", amtToSubtract);
			transaction.exec();
			balance = Integer.parseInt(jedis.get("balance"));
			debt = Integer.parseInt(jedis.get("debt"));
			System.out.println("*******" + balance);
			System.out.println("*******" + debt);
			return true;
		}
	}
	/**
	 * 通俗点讲，watch命令就是标记一个键，如果标记了一个键， 在提交事务前如果该键被别人修改过，那事务就会失败，这种情况通常可以在程序中 重新再尝试一次。
	 * 首先标记了键balance，然后检查余额是否足够，不足就取消标记，并不做扣减； 足够的话，就启动事务进行更新操作，
	 * 如果在此期间键balance被其它人修改， 那在提交事务（执行exec）时就会报错， 程序中通常可以捕获这类错误再重新执行一次，直到成功。
	 */
	public static void main(String[] args) {
		RedisTest test = new RedisTest();
		boolean retValue = test.transMethod();
		System.out.println("main retValue-------: " + retValue);
	}

}

2.主从复制

public class RedisTest2 {
	
	public static void main(String[] args) {
		Jedis jedisMaster=new Jedis("192.168.25.128",6380);//主节点
		Jedis jedisSlave=new Jedis("192.168.25.128",6379);//从节点
		jedisSlave.slaveof("127.0.0.1", 6380);//从节点连接主节点
		String set = jedisMaster.set("k1", "v1");//主节点写
		String string = jedisSlave.get("k1");//从节点读
		System.out.println(string);
	}

}

3.Jedis连接池

public class JedisPoolUtils {
	
	private JedisPoolUtils() {}
	
	private static volatile JedisPool jedisPool;
	
	public static JedisPool getInstance() {//单例
		if(jedisPool==null) {
			synchronized (JedisPoolUtils.class) {
				if (jedisPool==null) {
					JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
					jedisPoolConfig.setMaxTotal(1000);
					jedisPoolConfig.setMaxIdle(32);
					jedisPoolConfig.setMaxWaitMillis(100*1000);
					jedisPoolConfig.setTestOnBorrow(true);
					jedisPool=new JedisPool(jedisPoolConfig,"192.168.25.128",6380);
				}
			}
		}
		return jedisPool;
	}
	public static void release(JedisPool jedisPool,Jedis jedis) {
		if (jedis!=null) {
			jedisPool.returnResourceObject(jedis);
		}
	}

}

public class RedisTest3 {
	
	public static void main(String[] args) {
		JedisPool jedisPool = JedisPoolUtils.getInstance();
		Jedis jedis=null;
		try {
			jedis = jedisPool.getResource();
			String string = jedis.get("k1");
			System.out.println(string);
		} catch (Exception e) {
			e.printStackTrace();
		}finally {
			JedisPoolUtils.release(jedisPool, jedis);
		}
	}

}

JedisPool的配置参数大部分是由JedisPoolConfig的对应项来赋值的。
 
maxActive：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了maxActive个jedis实例，则此时pool的状态为exhausted。
maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
whenExhaustedAction：表示当pool中的jedis实例都被allocated完时，pool要采取的操作；默认有三种。
 WHEN_EXHAUSTED_FAIL --> 表示无jedis实例时，直接抛出NoSuchElementException；
 WHEN_EXHAUSTED_BLOCK --> 则表示阻塞住，或者达到maxWait时抛出JedisConnectionException；
 WHEN_EXHAUSTED_GROW --> 则表示新建一个jedis实例，也就说设置的maxActive无用；
maxWait：表示当borrow一个jedis实例时，最大的等待时间，如果超过等待时间，则直接抛JedisConnectionException；
testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；
 
testOnReturn：return 一个jedis实例给pool时，是否检查连接可用性（ping()）；
 
testWhileIdle：如果为true，表示有一个idle object evitor线程对idle object进行扫描，如果validate失败，此object会被从pool中drop掉；这一项只有在timeBetweenEvictionRunsMillis大于0时才有意义；
 
timeBetweenEvictionRunsMillis：表示idle object evitor两次扫描之间要sleep的毫秒数；
 
numTestsPerEvictionRun：表示idle object evitor每次扫描的最多的对象数；
 
minEvictableIdleTimeMillis：表示一个对象至少停留在idle状态的最短时间，然后才能被idle object evitor扫描并驱逐；这一项只有在timeBetweenEvictionRunsMillis大于0时才有意义；
 
softMinEvictableIdleTimeMillis：在minEvictableIdleTimeMillis基础上，加入了至少minIdle个对象已经在pool里面了。如果为-1，evicted不会根据idle time驱逐任何对象。如果minEvictableIdleTimeMillis>0，则此项设置无意义，且只有在timeBetweenEvictionRunsMillis大于0时才有意义；
 
lifo：borrowObject返回对象时，是采用DEFAULT_LIFO（last in first out，即类似cache的最频繁使用队列），如果为False，则表示FIFO队列；
 
==================================================================================================================
其中JedisPoolConfig对一些参数的默认设置如下：
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1