redis集群理论与实战(二)

joyieldInc代理

下载编译好的文件

git地址：
https://github.com/joyieldInc/predixy
编译文件地址:
https://github.com/joyieldInc/predixy/releases/download/1.0.5/predixy-1.0.5-bin-amd64-linux.tar.gz

　　

编辑conf/predixy.conf

Bind 127.0.0.1:7617
Include sentinel.conf
# Include try.conf

　　

编辑conf/sentinel.conf

复制一份 Examples中SentinelServerPool
光标定位复制行
:.,$y 回车复制  大GNP粘贴

去掉#
:.,$s/#//

配置:
    Sentinels {
        + 127.0.0.1:26379
        + 127.0.0.1:26380
        + 127.0.0.1:26381
    }
    Group shard001 {
    }
    Group shard002 {
    }
Sentinels 代表三台哨兵
shard001 、shard002 代表两套主从的主

　　

配置对应三台哨兵

vi 26379.conf
port 26379
sentinel monitor shard001 127.0.0.1 36379 1
sentinel monitor shard002 127.0.0.1 46379 1

vi 26380.conf
port 26380
sentinel monitor shard001 127.0.0.1 36379 2
sentinel monitor shard002 127.0.0.1 46379 2

vi 26381.conf
port 26381
sentinel monitor shard001 127.0.0.1 36379 2
sentinel monitor shard002 127.0.0.1 46379 2

说明: 26379、26380、26381三台哨兵监控主36379/46379

启动

1.启动三台哨兵
redis-server 26379.conf --sentinel
redis-server 26380.conf --sentinel
redis-server 26381.conf --sentinel

2.启动两套主从
mkdir 36379
mkdir 36380
mkdir 46379
mkdir 46380
redis-server --port 36379
redis-server --port 36380 --replicaof 127.0.0.1 36379
redis-server --port 46379
redis-server --port 46380 --replicaof 127.0.0.1 46379


3.启动joyieldinc代理(进入src)
./predixy ../conf/predixy.conf

　　

测试代理：

[root@redis2 ~]# redis-cli -p 7617
127.0.0.1:7617> set k1 aa
OK
127.0.0.1:7617> set k2 bb
OK
127.0.0.1:7617> set xiaoke 03
OK
127.0.0.1:7617> key *
(error) ERR unknown command 'key'
127.0.0.1:7617> watch k1
(error) ERR forbid transaction in current server pool
127.0.0.1:7617> multi
(error) ERR forbid transaction in current server pool
127.0.0.1:7617> 

　　

测试主36379/36380

[root@redis2 ~]# redis-cli -p 36379
127.0.0.1:36379> keys *
1) "k1"

　　

测试主46379/46380

[root@redis2 ~]# redis-cli -p 46380
127.0.0.1:46380> keys *
1) "k2"
2) "xiaoke"

　　

 down 46379 46380会被哨兵安排为主

9419:X 23 Jan 2021 23:30:34.588 # +config-update-from sentinel f05144068bb19e08d15e2243259ac7575dbf375d 127.0.0.1 26381 @ shard002 127.0.0.1 46379
9419:X 23 Jan 2021 23:30:34.588 # +switch-master shard002 127.0.0.1 46379 127.0.0.1 46380
9419:X 23 Jan 2021 23:30:34.588 * +slave slave 127.0.0.1:46379 127.0.0.1 46379 @ shard002 127.0.0.1 46380
9419:X 23 Jan 2021 23:31:04.604 # +sdown slave 127.0.0.1:46379 127.0.0.1 46379 @ shard002 127.0.0.1 46380

　　

面试总结：

1.你在上家公司redis都遇到哪些问题呢?

以前去过的公司redis都是单节点的，随着业务、客户数量的增多，面临以下问题 a.单点故障 b.容量有限 c 访问压力

2.那你的解决方案是?

    a.对于单点故障和压力： 我们可以横向扩展(x轴)，增加备用机器，当主挂掉备用机器顶上去，可以使用主从模式，主负责写，从负责读取
    b.对于容量有限问题： 可以纵向扩展(y轴), 进行业务拆分，嵌套到微服务内，每个redis集群负责各自的业务范围
    c.当我们的客户量达到几个亿，以上的方案难以支撑,可以增加Z轴,进行类似分库操作，比如： 1-1亿存A集群 1亿-2亿B集群

3.搭建集群会面临什么问题，比如？假设集群：X  有A、B、C三个节点，A为主节点 

    a.集群一变多，会带来数据一致性问题
        1.假设集群是同步阻塞模式(数据强一致性)，client访问给A写入数据，B此时网络不通，那么A节点同步不到B，聚会出现四等问题，client也会同步等死，破坏了可用性(数据一致性破坏可用性)
        2.假如集群是异步非阻塞模式(数据弱一致性)，clinet访问给A写入数据，B此时网络不通，那么B数据丢失，当B恢复，客户去集群B查询，拿不到数据(这种情况不影响客户正常使用，可以去数据库拿，但是增加了DB压力)
        3.通过1和2方案，折中方案：使得数据最终一致性，增加一个消息中间件，具备条件：可靠、高可用、响应速度快(集群) client访问给A写入数据，A将数据写入kafka,B此时网络不通，等待B恢复，就去kafka同步数据，最终数据一致性
        
    b.Redis一般使用主从集群，数据延迟问题?

    c.为了解决单点故障增加了集群，那么主从切换时怎么做到的？
        1.增加监控 - 哨兵sentinel， a.说明当前主机是否挂了, b.投票选主
        2.一个哨兵: 统计不够准确，不高可用
        3.2个哨兵：容易脑裂
        4.三个机以上，成功解决脑裂问题 n/2 + 1 得票过半
            a.3台监控，允许一台挂掉，选主得票2，过半
            b.4台监控，允许一台挂掉，选主得票3，过半
            c.5台允许2台挂掉，选主得票3，过半
            4.so过半指的是得到的选票/总机器
    d.哨兵之间是可以通信的，通过发布订阅其他哨兵(PSUBSCRIBE*可以查看)



    

4.解决容量的具体方案?

说明: 数据按照业务微服务的那种方式已经无法再分，搭建redis集群A和B
    a.算法：hash+取模，将不同的数据分配到A和B中，问题:有数据倾斜问题
    b.random随机分配，讲不通的数据分配到A和B中，取数据的时候要去两个集群取，然后拼接起来
    c.kemata一致性哈希,规划一个环形哈希环
        1.可以解决数据倾斜问题
        2.可以随意增加节点，减少其他节点的压力(增加节点只会带来部分数据不会命中)