Redis 主从、哨兵Sentinel、Jedis

上篇说到了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. 主从的意义

1. 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的主要工作如下：

1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

2. 配置Sentinel

哨兵应该被放在独立的服务器上，最好最少应该有3个哨兵（3台服务器）。

1. 配置文件sentinel.conf

   // 26379模式是sentinel的运行端口，6379是redis-server的
   port 26379
   // 作为守护进程
   daemonize yes
   // 工作目录，设置到你统一规划的地方</