1、启动zk:
~/zookeeper-3.4.8/bin/zkServer.sh start
2、启动 dashboard
#start dashboard
/root/proxy_redis/codis-config -c /root/proxy_redis/config.ini dashboard --http-log=/home/logger/codis_dashboard/codis_1.log >> /dev/null &
非常注意一点,dashboard任务不要用kill -9 直接杀掉,这会导致zk中已经注册的节点不能正常处理掉(随着dashboard 关闭而删除掉);
导致的结果就是下次启动dashboard的时候报错,解决方法就删除zk目录里关于dashboard的节点,或者删除所有关于codis的节点。
启动之前需要配置config.ini
用-c 指定配置文件所在位置
用
--http-log 指定dashboard http日志输出文件
这时候查看zk 内的节点:
ls /zk/codis/db_test
db_test 目录下面生成两个节点:migrate_tasks、dashboard
dashboard节点记录的是dashboard的基本信息,ip地址、端口号等等
migrate_tasks节点应该是记录的数据迁移的片(此时只有dashboard运行该想法是猜测,继续往下执行验证一下……)
此时按照官方文档需要初始化slots;
执行初始化slots 命令:
/root/proxy_redis/codis-config -c /root/proxy_redis/config.ini slot init
执行结果:
{
"msg": "OK",
"ret": 0
}
执行成功之后再次查看zk节点有什么变化:
增加了一个slots 节点:
节点下面有1024个子节点,这个应该是 codis 的预分片技术依赖节点了
actions节点:
ActionResponse节点:
上面三个节点都有1024个子节点,另外之前创建的migrate_tasks、dashboard这两个节点都没有发生变化。
这样slots初始化完成
3、启动codis-server
我启动了4个redis 端口号分别是6379、6389;6479、6489两组;
4、添加redis-server group:
./codis-config server add 1 localhost:6379 master
./codis-config server add 1 localhost:6389 slave
也可以在dashboard 中添加
现在打开dashboard就可以看到新添加的redis group了.现在再看一下zk中节点的变化
又多了两个节点 servers 、LOCK
servers节点:
节点下有两个group(我简建了两组redis),
servers子节点group_x:
下面是每个节点的信息,用get 方法查看:
LOCK节点下面是空的也没有数据:
5、 设置 server group 服务的 slot 范围
这个在dashboard中就可以设置
现在再在zk中查看一下节点变化,发现slots节点里的各个子节点根据你设置的服务范围,节点的信息发生了改变:
这里可以看到 group_id=1 我是吧slot_0分配到group1下面的;stat中状态是online;migrate_status这个表示迁移状态 两个参数都是-1表示静止状态。last_op_ts 猜测是最后一次操作的啥东西?(瞎猜……接着继续……)
6、启动 codis-proxy
./codis-proxy -c config.ini -L ./log/proxy.log --cpu=1 --addr=0.0.0.0:19000 --http-addr=0.0.0.0:11000
--cpu 参数 因为codis是go写的,对多核cpu有优化,这里指的是proxy所在服务器可以用多少个核心(作者猜测)
--addr proxy监听地址
--http-addr
codis 官方文档中说刚启动的codis-proxy默认是offline的,但是我这边测试发现第一个proxy默认是online的……
现在完整的单机版codis已经启动了,再看一眼zk的情况:
又多了两个节点proxy,fence
proxy节点:
..
下面保存着每个proxy的信息:
下面保存着每个proxy的信息:
localhost.localdomain这是作者虚拟机的名称…………实在太懒了,没有改主机名称……
节点下保存的是proxy1监听的端口,codis客户端说不定就会从这个节点中拿一个proxy地址来用(这还是猜测……没根据的猜测)
好了,写一个简单的程序测试一下~~~
单个线程set:
20个线程:
测试的时候都是比较短的key和value,而且虚拟机和客户端都在同一台电脑,所结果参考价值不很大……
测试中在20个线程狂奔的情况下kill掉一个proxy没发现客户端报错。由于执行的数据没啥规律所以没测试是否会导致数据丢失。
最后测试了一下数据迁移,还是很好用的,其他问题有待来日再测,今天先到这。