从零到壹搭建一个商城架构--Redis集群

1）、redis集群形式

• 数据分区方案

  1、客户端分区

客户端分区方案的代表为Redis Sharding，Rdis Sharding事Redis Cluster出来之前，业界普遍使用的Redis多实例集群方法。Java的Redis客户端驱动库Jedis，支持Redis Sharding功能，即ShardingJedis以及结合缓存池的ShardingJedisPool。

优点：

不适用第三方中间件，分区逻辑可控，配置简单，节点之间无关联，容易线性扩展，灵活性强

缺点：

客户端无法动态增删服务节点，客户端要自行维护分发维护，分发逻辑，客户端之间，无连接共享会造成连接浪费

2、代理分区

代理分区常用方案有Twemproxy和Codis

3、redis-cluster

2）、高可用方式

1、Sentinel（哨兵机制）支持高可

前面介绍了主从机制，但是从运维角度来看，主节点出现了问题我们还需要通过人工干预的方式把从节点设为主节点，还要通知应用程序更新主节点地址，这种方式非常繁琐笨重，而且主节点的读写能力都十分有限，有没有较好的办法解决这两个问题呢？烧饼机制就是针对第一个问题的有效解决方案，第二个问题则依赖于集群，烧饼的作用就是监控Redis系统的运行状况，其功能主要事包括以下三点：

• 监控（Monitoring）：哨兵（Sentinel）会不断地检查你的Master和Slave是否运行正常
• 提醒（Notification）：当被监控的某个Redis出现问题，哨兵（Sentinel）可以通过API向管理员或者其他应用程序发送通知
• 自动故障迁移（Automatic failover）：当主数据库出现故障时自动将从数据库转换为主数据库

哨兵的原理

Redis哨兵的三个定时任务，Redis哨兵判定一个Redis节点故障不可达主要就是通过三个定时监控任务来完成的

• 每隔10秒每个哨兵节点会向主节点和从节点发送“info replication”命令来获取最新的拓扑结构

• 每隔2秒每个哨兵节点会向Redis节点的_sentinel_hello频道发送自己对主节点是否故障的判断以及自身的节点信息，并且其他的哨兵节点也会订阅这个频道来了解其他哨兵节点的信息以及对主节点的判断
• 每隔1秒每个哨兵会向主节点、从节点、其他的哨兵节点发送一个“ping”命令来做心跳检测

如果在定时Job3检测不到节点的心跳，会判断为“主管下线”。如果该节点还是主节点，那么还会通知到其他的哨兵对改主节点进行心跳检测，这时主管下线的票数超过了数时，那么这个主节点确定就可能时故障不可达了，这时就由原来的主管下线变为了”客观下线“。

故障转移和Leader选举

如果主节点被判定为客观下线之后，就要选取一个哨兵节点来完成后面的故障转移工作，选举出一个leader，这里采用的选举算法为Raft。选举出来的哨兵leader就要来完成故障转移工作，也就是在从节点中选出一个节点来当新的主节点

2、Redis-Cluster

https://redis.io/topics/cluster-tutorial/

Redis的官方多级部署方案，Redis Cluster。一组Redis Cluster是由多个Redis实例组成，官方推荐我们使用6实例，其中3哥为主节点，3哥为从节点。一旦由主节点发生故障的时候，Redis Cluster可以选举出对应的从节点成为主节点，继续对外服务，从而保证服务的高可用性。那么对于客户端来说，知道对应的key是要路由到哪一个节点呢？Redis Cluster把所有的数据划分为16384哥不同的槽位，可以根据机器的性能把不同的槽位分配给不同的redis实例，对于Redis实例来说，它们只会存储部分的Redis数据，当然，槽的数据是可以迁移的，不同的实例之间，可以通过一定的协议，进行数据迁移。

1、槽

Redis集群的功能限制，Redis集群相对单机在功能上存在一些限制，需要开发人员提前了解，在使用时做好规避。JAVA CRC16校验

• key批量操作支持有限
  • 类似mset、mget操作，目前只支持对具有相同slot值的key执行批量操作，对于映射位不同slot值的key由于执行mget、mset等操作可能存在于多个节点上，因此不被支持。
• key事务操作 支持有限
  • 只支持多key在同一节点上的事务，当多个key分布在不同的节点上时无法使用事务功能。
• key作为数据分区的最小粒度
• 不能将一个打的键值对象和hash、list等映射到不同的节点
• 不支持多数据库空间
  • 单机下的Redis可以支持16个数据库（db0~db15）、集群模式下只能使用一个数据库空间，即db0
• 复制结构只支持一层
  • 从节点只能复制主节点，不支持嵌套树状复制结构
• 命令大多会重定向，耗时多

2、一致性hash

一致性哈希可以很好的解决稳定性问题，可以将所有的存储节点排列在首位相接的Hash环上，每个key在计算Hash后会顺时针找到相邻的存储节点存放。而当有节点加入或退出时，仅影响该节点在Hash环上顺时针相邻的后续节点

Hash倾斜

如果节点很少，容易出现倾斜，负载不均衡问题。一致性哈希算法，引入了虚拟节点，在整个环上，均衡增加若干个节点，比如a1,a2,b1,b2,c1,c2，a1和a2都是输入A节点的。解决hash倾斜问题

3）、部署Cluster

Redis Cluster原理图

1、创建6个Redis节点

3主3从方式，从位了同步备份，主进行slot数据分片

for port in $(seq 7001 7006); \
do \
mkdir -p /mydata/redis/node-${port}/conf
touch /mydata/redis/node-${port}/conf/redis.conf
cat << EOF >/mydata/redis/node-${port}/conf/redis.conf
port ${port}
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.56.10
cluster-announce-bus-port 1${port}
appendonly yes
EOF
docker run -p ${port}:${port} -p 1${port}:1${port} --privileged=true --name redis-${port} \
--net host \
-v /mydata/redis/node-${port}/data:/data \
-v /mydata/redis/node-${port}/conf/redis.conf:/etc/redis/redis.conf \
-d redis:5.0.7 redis-server /etc/redis/redis.conf; \
done
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

2、使用redis建立集群

#进入第一个redis
docker exec -it redis-7001 /bin/bash
#设置第一个为主节点
redis-cli --cluster create 192.168.56.10:7001 192.168.56.10:7002 192.168.56.10:7003 192.168.56.10:7004 192.168.56.10:7005 192.168.56.10:7006 --cluster-replicas 1
1
2
3
4