文章目录
1： 为什么 Redis 要分片？
我们知道,一般由于单点故障会造成的问题有三种，分别是 ：
1:单点故障 2：容量有限 3:连接数，CPU压力
而 主从集群可以缓解 1 和 3 ，但是对 2 却有点力不从心
因此，便想到了将 数据分别存在不同的 Redis 实例中，所有实例合起来才是完整的数据
2: 分片集群的方法
方法一：按照业务拆分，人工进行分区，比如一个微服务一个 Redis 实例
方法二：代理方式
数据拆不开（加上代理）：常见的有 twemproxy 和 predixy
2.1：modula: 每一笔数据进行 hash，然后取模，模是 redis 分片数量。（基本没人用）
弊端：取模的值是固定的，影响分布式下的扩展，后面添加 redis 实例，模数值就会变化，但是数据在别的机器上
2.2：random: 随机的数据存放进 redis 实例，但是扔进去了之后，数据找不到了。
使用场景：redis 实例中投共同的 key ,value 倾向于是 list, 另外的客户端做消费，连接 redis 实例，pop出来数据即可。做消息队列
弊端：存进去数据，取拿不出来
2.3：kemata：一致性哈希算法，没有取模。要求 数据 和 设备都要参与计算，抽取成一个环形，哈希环，顺时针方向组织，0-232,0~232-1在零点中方向重合。
思想：设备信息经过哈希，在哈希环上找到一个位置（物理的）；数据经过哈希，也在换上找到一个点，找到距离最近的比他大的物理机，存放进去就好
优点：加节点，的确可以分担其他节点的压力，不会造成全系统洗牌
弊端：1可能出现数据集体往一个redis中存的情况，2新增节点会造成一部分数据不能命中。
问题1——>将redis的ip依次加上十个数字，这样就有十个点，可以解决数据倾斜的问题
问题2——>缓存击穿，压在mysql —>可以尝试每次取离我最近的两个位置
得到结论：分片集群，redis 的连接成本很高，对server端造成的。增加nginx 反向代理服务器，自己不干事，只是把连接 hold 住了，只需要关注代理层的性能就好了
方法三：预分区
1：哈希法:一开始把魔术值设置的较大,比如10个,取模是10,模数值得范围是:0,1…9,中间加一层mapping， 0,1,2,3,4给第一个redis,5,6,7,8,9给第二个redis;如果有新的redis,那么让前两个redis让出一些槽位即可。迁移数据即可，比如3,4,8,9给第三台redis.
2：redis是怎么做的？(无主模型)
客户端get k1,随机连接一台redis,先hash%n,得到槽位，如果当前redis的槽位中有，取数据；否则，因为每个redis都知道其他
redis的槽位，返回客户端，应该去那个redis,进行重定向，重复上述操作。要求每个 redis 有相同的算法，并且知道别的 redis 都持有什么分片
这一篇博客我们来搭建基于 twemproxy 的代理方式的分片集群
3：使用 twemproxy 搭建
GitHub 地址：https://github.com/twitter/twemproxy
也可以直接在 GitHub 上搜 twemproxy
3.1: 克隆 twemproxy 源码
登录 linux 系统，来到存文件的目录，新建 文件夹 twemproxy ，并且通过 git 去下载源码
cd /jqk
mkdir twemproxy
cd twemproxy
git clone https://github.com/twitter/twemproxy.git
注意：git clone 如果失败 yum update nss,升级下版本，中间选y
3.2:安装 automoke 和 libtool
yum install automoke libtool
安装完成后，执行命令
autoreconf -fvi
注意：执行成功，直接到 3.3:安装automoke和libtool
如果执行失败，autoreconf版本太低,需要来到 cd /etc/yum.repo.d/ ，添加一个指向仓库
cd /etc/yum.repo.d/
# 执行命令，添加指向仓库
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
# 清除缓存
yum clean all
来到 twemproxy 的文件夹，寻找 antoconf
yum search antoconf
然后再去安装，并执行命令
yum install autoconf版本号
# 再次执行
autoreconf版本号 -fvi
3.3:编译
命令执行完成后，多了一个 config 文件夹
执行命令
./configure --enable-debug=full
执行完成后，执行 make 命令
make
编译完成后 ，我们进入到 scripts 文件夹，会发现有 nutcracker.init 脚本，我们可以打开看一下
cd scripts/
ls
接下来，我们将这个脚本复制一份到 /etc/init.d 文件夹下，取名叫做 twemproxy，并且让它变绿
# 复制文件到 /etc/init.d 文件夹下，取名叫做 twemproxy
cp nutcracker.init /etc/init.d/twemproxy
cd /etc/init.d/
ls
# 让它变绿，授权
chmod +x twemproxy
接下来。我们在 ./etc 目录下创建 nutcracker 文件夹 ，并来到 twemproxy 源码位置，复制配置文件到此 目录下
# 创建文件夹
mkdir /etc/nutcracker
# 来到 twemproxy 源码路径 src 目录下
cd /jqk/twemproxy/twemproxy/conf
# 复制文件到 nutcracker 目录下
cp ./* /etc/nutcracker/
为了能在 操作系统的任何位置都能使用 nutcracker 命令，我们将源码 src 目录下的 nutcracker 拷贝一份放在 /usr/bin 目录下
cd ../
cd src
cp nutcracker /usr/bin
我们接下来到的 /etc/nutcracker/ 下区修改配置文件，要养成好习惯，修改前先复制一份，后续出险问题可以补救
cd /etc/nutcracker/
# 复制配置文件，做备用
cp nutcracker.yml nutcracker.yml.bak
# 打开配置文件
vi nutcracker.yml
大家看到这个配置文件了，可能就会好奇怎么配置，其实官网上有描述，大家可以参考：https://github.com/twitter/twemproxy
下面我简单的配置一下：
注意：配置的代理端口是 22121，下面要用到的
alpha:
listen: 127.0.0.1:22121
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 127.0.0.1:6380:1
- 127.0.0.1:6381:1
- 127.0.0.1:6382:1
3.4:启动 Redis 服务
按照上次搭建主从集群的模式，启动三台 redis 实例，分别是
6380，6381，6382.
我们来到我们上次存放 redis 配置文件的地方 /usr/local/redis/myconf 下。新创建三个文件夹，分别是
6380，6381，6382.并进入相应的文件夹，手动启动redis 实例
cd /usr/local/redis/myconf
mkdir 6380
mkdir 6381
mkdir 6382
cd 6380
redis-server --port 6380
cd /usr/local/redis/myconf/6381/
redis-server --port 6381
cd /usr/local/redis/myconf/6382/
redis-server --port 6382
3.5:启动代理服务器 twemproxy
在任意页面，启动 twemproxy 代理。
service twemproxy start
启动 twemproxy 的客户端，注意端口是 22121 ,并随意添加一些数据
redis-cli -p 22121
可以观察到：数据可以添加进去，也可以取出来。到此，我们的分片代理集群就搭建完毕了。
3.6:观察数据
当在代理层存数据，然后去 redis 中查看数据的时候，有时候，数据都在一个 redis 实例中，我还以为自己搭建错了，清库了再次尝试，试了好几次，出来了一个不一样的。
代理：
6380：
6381：
6382：
可见，分片代理的服务器是可以工作的。
3.7: 关闭 twemproxy
service twemproxy stop