上篇说到了Redis安装、运行。今天来看一看Redis的主从复制、Sentinel;
一、主从复制
1. 配置
在Master
上修改redis.conf
// 不想用密码,所以把保护模式设置为no
protected-mode no
// 其实master上不需要配置什么,这里只是取消了保护模式
在Slave1
和Slave2
上修改redis.conf
// 同样关闭保护模式
protected-mode no
// 设置本机是谁的slave
slaveof master的ip 6379
// 当配置了slaveof后,下面这条控制本机只能读
slave-read-only yes
2. Jedis操作
// 简单设置3个连接池
private static final JedisPool masterPool;
private static final JedisPool slavePool1;
private static final JedisPool slavePool2;
static {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
// 最多可以有10个连接
jedisPoolConfig.setMaxTotal(10);
jedisPoolConfig.setMaxIdle(5);
jedisPoolConfig.setMinIdle(5);
masterPool = new JedisPool(jedisPoolConfig, "111.111.111.111");
slavePool1 = new JedisPool(jedisPoolConfig, "111.111.111.112");
slavePool2 = new JedisPool(jedisPoolConfig, "111.111.111.113");
}
public static void main(String[] args) throws Exception {
// 简单使用,通过try-with-resource
try (Jedis jedis = masterPool.getResource()) {
jedis.get("key1");
} catch (Exception e) {
e.printStackTrace();
}
}
3. 主从的意义
Redis需要读写分离吗?
可能大家会思考过这样一个问题,在MySQL中常用的读写分离,在Redis这种内存DB中是否还会需要?反对者的观点是:Redis是内存存储,读写都非常快,如果将读且分离到
Master
和Slaves
上不仅可能造成主从不同步的麻烦,甚至不见得会提升整个DB的处理能力和速度。赞成者的观点是:Redis提供的
Master
和Slave
复制功能;官网中的介绍Replication can be used both for scalability, in order to have multiple slaves for read-only queries (for example, slow O(N) operations can be offloaded to slaves), or simply for data redundancy.
甚至配置文件中的参数
slave-read-only yes
都在提示着使用者,Redis给你提供了读写分离的功能。所以,为什么不要用呢?经过思考过后,我觉得:
1 如果使用者的业务数据量不大,则完全不必做读写分离,读写均在
Master
上做即可。但是主从复制还是需要的,可将Slave
作为简单的数据转储。
2 如果使用者的业务数据量比较大,只用一个物理机Master
承担读写已不能满足业务或性能的需求,那么则可以做读且分离。即,在项目代码中封装一下对Redis的操作(如封装Jedis操作),将写操作映射给Master
,将读操作按照你自己定义的分配策略,映射给某个Slave
。
一个企业级系统最重要的指标就是“可用性”和“高性能”。
显然,上面的主从复制、读写分离能够简单的提供“高性能”,但也只是提升了“读”的性能,并不能扩展“写”。(写的扩展这里暂且不表)
另一方面,“可用性”也是极其重要的。如上结构可用性并不高,一旦Master
宕机则Redis将立即不可写,Slave
将只剩下旧数据,系统随即不可用。
必然的,Redis提供了高可用(High Availability)方案,其中之一就是Sentinel-哨兵。
二、Sentinel - 高可用
1. 什么是Sentinel?
见名知意,它是Redis提供的哨兵程序,它是分布式程序,可以这样描述它们:
哨兵一般是好几个一起站岗,他们共同监视一个
Master
以及其Slaves
。当哨兵看到Master
挂掉了,他们就会互相确认有没有看走眼,一旦多数哨兵都说它挂了,那么他们就能得出结论:Master
挂了。
此时第一个发现的Sentinel会负责进行自动故障迁移,它会立即在Slaves
中选出一个担任Master
,所有Slaves
从属于新Master
,所有客户端对Master
的操作转而到这台新Master
上。
Sentinel的主要工作如下:
监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
2. 配置Sentinel
哨兵应该被放在独立的服务器上,最好最少应该有3个哨兵(3台服务器)。
配置文件sentinel.conf
// 26379模式是sentinel的运行端口,6379是redis-server的 port 26379 // 作为守护进程 daemonize yes // 工作目录,设置到你统一规划的地方</