0、安装前环境准备

① 本篇是基于Linux操作系统中的安装，故先准备一个干净的Linux操作系统，本文中所有的操作基于CentOS8进行安装演示；

② 接下来的演示文本中，红色字体为操作步骤，黑色字体为解释说明。

1、进入到本地twemproxy目录，从Github下载twemproxy

在本地创建twemproxy目录

cd /usr/local/source/

mkdir twemproxy

cd twemproxy/

进入twemproxy在Github上的地址（https://github.com/twitter/twemproxy），复制下载地址

从Github上下载twemproxy至本地

git clone https://github.com/twitter/twemproxy

注：因为我本地的CentOS8没有预安装 [git-core] 软件，所以在使用 git clone 命令前会自动提示你需要安装相关软件，直接安装就可以了。

2、仔细阅读Github上面README.md说明

注：基本Linux系统的软件使用源码安装基本都是一个套路：源码安装上来看的第一个文件就是README。所以，README.md 文件是一个非常非常重要的文件。当你第一次面对一个从来没用安装过的软件时，去读它提供的类 README 文件，在这个文件中会详细描述当前软件的安装步骤，排错过程及各参数的详细意义，一定要仔细研读后再进行软件的安装！

3、根据Github上的README.md说明进行安装

① yum install automake libtool -y

② autoreconf -fvi

注：如果系统自带的Autoconf版本过低的话，此时将会报错：Autoconf version 2.64 or high is required，就需要将Autoconf进行一个升级。如果直接在系统中使用yum search autoconf，不一定能搜索到更高版本的Autoconf，因为使用yum安装的软件来源于仓库，系统自带的仓库版本就偏低，可以使用阿里的仓库就可以搜索到更高版本的Autoconf。

命令执行完之后会在目录下生成configure可执行文件

③ ./configure

④ make

make 编译完以后就会在 src/ 目录下就生成可执行程序

4、配置twemporxy系统服务

进入到源码中的脚本文件夹中：cd scripts/

拷贝初始化文件到系统服务目录下：cp nutcracker.init /etc/init.d/twemproxy

进入到系统服务目录中：cd /etc/init.d/

将拷贝来的文件转换为可执行文件：chmod +x twemproxy

查看执行文件，按照执行文件里的描述创建相关配置文件

vim twemproxy

先创建存放配置文件的目标文件夹

mkdir /etc/nutcracker

相关的配置文件在源码中已经自带，这玩意儿它要不是自带的话，那估计也没几个人能写了

cd /usr/local/source/twemproxy/twemproxy/conf

拷贝所有的配置文件到目标文件夹中

cp ./* /etc/nutcracker/

这个时候再看配置文件，配置文件下面有说这个程序缺少一个路径

而这个路径在它的环境变量path的一个基本路径里面，比如说根目录下的bin目录，或者根目录下的sbin目录等。所以这个时候只需要将刚刚编译完的可执行程序拷贝到 /usr/bin 目录即可

cd /usr/local/source/twemproxy/twemproxy/src/

cp nutcracker /usr/bin/

那么在操作系统的任何位置都可以很方便的使用这个命令

5、修改nutcracker配置文件

还是那句话，根据Github上的README.md说明进行配置文件的修改。

cd /etc/nutcracker/

vim nutcracker.yml

确保负载的这两台Redis实例已经启动

6、启动twemproxy代理

service twemproxy start

使用Redis客户端连接22121监听端口

redis-cli -p 22121

此时连接的就不是某一个具体的实例，既不是6379，也不是6380，而是Twitter的代理实例Twemproxy，可以插入数据，然后具体看数据到底是存在6379还是6380

根据刚刚在配置文件中所设的权重，6379和6380的比例是1:2，也就是说设置了9个数值，那么应该在6379中存储3个，而在6380中存储6个。但是所有的数据都存到6380中，只能说概率学的东西太不靠谱了~~不过这个代理的效果还是显而易见的，对于客户端来说代理后面的机器是透明的，客户端完全不知道后面有多少台机器，客户端只需要负责往你这一个代理里面去怼就行了。

7、分析一波Twemproxy的缺点

我们先在22121上执行一个简单的命令：keys *

会发现这个代理直接报错，因为这个代理后面是多台服务器，真正的数据是存放在代理后面的服务器上，而这些数据都被分置在不同的服务器里。如果代理层这边去循环每一个机器，取出里面的数据，这个成本有点高，所以这个命令直接就不支持了。

同样的，watch命令也不支持

multi 事务命令也不支持

当要开启一个事务的时候，里面有9个Key，而且在不同的节点。曾经我们在讨论Redi事务的时候，是Redis拿着它打一个标记，后面来的命令是不执行的先放在缓冲区里面，直到接收到exec命名的时候再执行。但是现在这个事务中，如果对不同的key进行处理，也就是说你的这个指令发送到不同的节点上，那这些指令就没办法汇集到一起。