Redis学习笔记（四）主从复制、Jedis

Redis主从复制

Redis 支持开启和关闭读写分离功能，针对读多写少的业务场景，解决热点数据集中的读需求，最大支持1主5从模式，提供最大5倍的读性能扩展能力。持久化保证了即使 redis 服务重启也会丢失数据，因为 redis 服务重启后会将硬盘上持久化的数据恢复到内存中，但是当 redis 服务器的硬盘损坏了可能会导致数据丢失，如果通过 redis 的主从复制机制就可以避免这种单点故障。

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性。

Redis复制如何去应用

1、配从(库)不配主(库)；
2、从库配置：执行命令slaveof 主库IP 主库端口：
    每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件；
    执行命令info replication查看主从关系；
3、修改配置文件细节操作：
    拷贝多个redis.conf文件；
    开启daemonize yes；
    修改pid文件名字；
    修改指定端口；
    修改log文件名字；
    修改dump.rdb名字；
4、常用三招

一主多仆

一个master两个slave
一些问题？
(1) 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?
答：从头开始复制；
(2) 从机是否可以写？set可否？
答：从机不可以写，也就不能set；
(3) 主机shutdown后情况如何？从机是上位还是原地待命?
答：原地待命；
(4) 主机又回来了后，主机新增记录，从机还能否顺利复制？
答：可以；
(5) 其中一台从机宕掉后情况如何？恢复它能跟上主机吗？
答：不能，需要重新建立主从关系；

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力。
中途变更转向:会清除之前的数据，重新建立拷贝最新的。

 反客为主

主机宕掉后，从机升级为主机：
选择一个从机手动执行slaveof no one命令变更为主机，其他从机与该主机建立主从关系。

Redis复制的原理

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

哨兵模式(sentinel)

哨兵模式简介
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库；
启动哨兵模式步骤：

自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错；
配置哨兵,填写内容在sentinel.conf文件中配置：
sentinel monitor 被监控数据库名字(自己起个名字) 127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多的成为主机；
启动哨兵
执行命令：redis-sentinel /myredis/sentinel.conf （目录依照各自的实际情况配置，可能目录不同）；

如果之前的master重启回来，会不会双master冲突？
不会造成双冲突，之前的master会成为slave。

复制的缺点

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

 

原文地址：https://blog.csdn.net/qq_40804005/article/details/82919154

 

Jedis

maven依赖

<dependency>
     <groupId>redis.clients</groupId>
     <artifactId>jedis</artifactId>
 </dependency>

jedis直连五个步骤：
            1、引包
            2、构造方法 jedis对象。
            3、connect连接
            4、获得数据
            5、disconnect方法关闭连接

public class jedis {
	public static void main(String[] args) {
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		jedis.connect();
		Set<String> keyList = jedis.keys("*");
		for (String key : keyList) {
			System.out.println(key + ":" + jedis.get(key));
		}
		jedis.disconnect();
	}
}

JedisAPI： http://tool.oschina.net/uploads/apidocs/redis/clients/jedis/Jedis.html

 

JedisPoolUtils

项目可以使用jedis连接池避免频繁的连接数据库来减少压力

JedisPoolUtils.java

public class JedisPoolUtils {

    private static volatile JedisPool jedisPool = null;

    private JedisPoolUtils() {
    }

    public static JedisPool getJedisPoolInstance() {
	if (jedisPool == null) {
		synchronized (JedisPoolUtils.class) {
			if (jedisPool == null) {
				JedisPoolConfig poolConfig = new JedisPoolConfig();
				poolConfig.setMaxIdle(1000);
				poolConfig.setMaxIdle(30);
				poolConfig.setMaxWaitMillis(100 * 1000);
				poolConfig.setTestOnBorrow(true);
				jedisPool = new JedisPool(poolConfig, "127.0.0.1", 6379);
			}
		}
	}
	return jedisPool;
    }

    public static Jedis getJedis() {
	return getJedisPoolInstance().getResource();
    }
}

 Jedis连接池配置参数

JedisPool的配置参数很大程度上依赖于实际应用需求、软硬件能力，JedisPool的配置参数大部分是由JedisPoolConfig的对应项来赋值的。
maxActive：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了maxActive个jedis实例，则此时pool的状态就成exhausted了，在JedisPoolConfig
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：在borrow一个jedis实例时，是否提前进行alidate操作；如果为true，则得到的jedis实例均是可用的；
testOnReturn：在return给pool时，是否提前进行validate操作；
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