| title |
|---|
秒杀活动技术方案，Redis申请32个G，被技术总监挑战了 |
作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学
作为一名技术从业人员，性能优化是每个人的必修课
就像大学时期给漂亮妹子修电脑的绝招就是”重启电脑“一样，性能优化也有自己的必杀技
你一定听过一句话：性能不够，缓存来凑！对，你没听错，就是缓存。
但是，哈哈，也不是拿来主义，张手就来。
这不，小王接到一个秒杀活动任务，设计技术方案，大量的数据扔到缓存里，想借助Redis的高吞吐量来抗住峰值压力。
这个思路也没错，这不一评估缓存内容占用的空间大小，需要30来个G。
你觉得有没有问题？觉得没问题的同学，可以去打游戏了
我们知道Redis集群有主从模式或者哨兵模式
无论采用采用那种模式，从节点同步数据时，开始需要fork子进程，生成RDB文件，如果数据容量过大，那么占用的时间会很长。如果主节点再开启持久化机制，那性能就更没法保证。
为了解决这个问题，Redis 又提出了一个新的解决方案，将大数据碎片化
假如原来一个节点存了30G的数据，现在我们拆分6个实例，每个实例的数据就只有5个G，压力一下小了很多
特别说明：由于key的路由规则基于特殊的负载算法，实际上并不是均等分配。
接下来，我们重点讨论的是，这个拆分方案要如何设计？
Redis 3.0 版本之前，官方还没有提供集群方案，但是单台实例受内存限制，无法实现垂直扩展，怎么办？
一些人提出了基于客户端的分区方案。
比如：基于客户端分区的 ShardedJedis，基于代理的 Codis、Twemproxy 等，后面挂载着若干个Redis实例，不同实例间完全隔离，互不通信。通过客户端代理组成了一个逻辑上的集群。从而解决庞大的数据容量问题。
Redis 官方在 3.0 版本 提出一个集群方案，称为 Redis Cluster。
Redis Cluster 核心设计引入一个哈希槽（Hash Slot），将整个集群切成了 16384 个哈希槽，你可以理解成一个个小的数据分区。
当我们操作Redis 时，根据传入的 key ，按照 CRC16算法计算出一个16位的二进制值，然后再对16384取模，便得到一个哈希槽编号。
注意：如果手动分配哈希槽，一定要把16384全部分配完，否则 Redis 集群无法工作。
分为手动搭建和自动搭建
我们先来看下纯手动如何搭建一个Redis Cluster集群。
首先，准备机器，为了方便测试，我们只用一台，通过不同端口模拟出 6个Redis 实例
1、构建三个目录：conf、data、log，分别存放 配置、数据 和 日志 相关文件。
修改conf配置文件如下
# redis后台运行
daemonize yes
# 数据存放目录
dir /usr/local/redis-cluster/data/redis-6379
# 日志文件
logfile /usr/local/redis-cluster/log/redis-6379.log
# 端口号
port 6379
# 开启集群模式
cluster-enabled yes
# 集群的配置，配置文件首次启动自动生成
# 这里只需指定文件名即可，集群启动成功后会自动在data目录下创建
cluster-config-file "nodes-6379.conf"
# 请求超时，设置10秒
cluster-node-timeout 10000
2、启动节点
sudo redis-server conf/redis-6379.conf
3、集群中各个节点握手通信，组成集群，握手命令 cluster meet {ip} {port}。握手成功后该状态通过Gossip协议在集群中传播，其它节点就会自动发现新节点并发起握手，最后所有节点都彼此感知并组成集群)
127.0.0.1:6379> cluster meet 127.0.0.1 6378
127.0.0.1:6379> cluster meet 127.0.0.1 6377
127.0.0.1:6379> cluster meet 127.0.0.1 6376
127.0.0.1:6379> cluster meet 127.0.0.1 6375
127.0.0.1:6379> cluster meet 127.0.0.1 6374
4、分配哈希槽，总共有16384个槽位，每个节点实例分配了一定数量的哈希槽
redis-cli -p 6379 cluster addslots {0..5461}
redis-cli -p 6378 cluster addslots {5462..10922}
redis-cli -p 6377 cluster addslots {10922..16383}
5、三个主节点分配完槽位后，每个主节点挂载相应的从节点，用于紧急情况下故障转移。从节点负责复制主节点槽信息和业务数据
# 进入从节点客户端
redis-cli -p 6376
127.0.0.1:6376> cluster replicate 7d480c106752e0ba4be3efaf6628bd7c8c124013（6379主节点的实例ID）
6、执行命令 cluster slots，查看集群各个节点的槽位分布
Redis Cluster集群采用分片，虽然每个实例只有部分的槽位数据，但是整个槽位分布会彼此间同步，有点类似病毒扩散。
最后，每个实例都有了全部的slot哈希槽与实例的映射关系。
应用启动后，客户端与Redis建立关联，会从一台Redis实例拉取全部的槽位映射关系，并缓存在本地。
当接到key操作命令时，先计算key的哈希槽，然后将命令发送给对应的Redis实例，从而完成了分布式路由逻辑。
当然，也有特殊情况发生，比如集群扩容、缩容，会打乱原有的哈希槽分布
如果slot与实例的映射关系发生了变化，客户端要如何处理？
没关系，Redis 官方也想到这个问题
当客户端执行一个key命令时，如果指向的实例位置已经变化，会响应 MOVED 结果，里面带有新目标实例的地址。
此时客户端会更新本地缓存，后续对于该槽位的请求直接打到新实例上。
但是如果此时槽位的key较多，部分key还没迁移完，怎么办？
GET Tom哥:key
(error) ASK 6504 127.0.0.1:6379
客户端请求key时，会收到一条 ASK 错误信息。此时，并不会更新客户端本地缓存的哈希槽映射关系。
客户端给新的目标实例发送 ASKING 命令，然后再发送原来的get命令，这一次的命令操作会在新实例上执行，但是仅限这一次。
同一个key下次再操作时，还是路由到老的实例，直到该槽位全部迁移完成。
只要是系统，就有宕机的风险。哨兵模式，通过单独部署哨兵集群，对整个Redis集群进行监控，具体的操作流程之前文章有介绍过。
Redis Cluster 并没有单独部署哨兵节点，而是通过master节点之间的心跳来彼此监控。
简单来说，针对A节点，某一个节点认为A宕机了，那么此时是主观下线。而如果集群内超过半数的节点认为A挂了， 那么此时A就会被标记为客观下线。
一旦节点A被标记为了客观下线，集群就会开始执行故障转移。其余正常运行的master节点会进行投票选举，从A节点的slave节点中选举出一个，将其切换成新的master对外提供服务。当某个slave获得了超过半数的master节点投票，就成功当选。
当选成功之后，新的master会执行slaveof no one来让自己停止复制A节点，使自己成为master。然后将A节点所负责处理的slot，全部转移给自己，然后就会向集群发PONG消息来广播自己的最新状态。
注意：Redis Cluster中的读、写请求都是在master上完成，从节点只是用于数据的容灾备份。