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.可以随意增加节点，减少其他节点的压力(增加节点只会带来部分数据不会命中)
