Codis 3.0.3安装搭建
一.基本信息
三台机器：192.168.33.6 192.168.33.19 192.168.33.7 zk1 zk2 zk3 codis-dashboard codis-fe codis-ha codis-proxy1 codis-proxy2 codis-proxy3 codis_group1_M(6379) codis_group2_M(6379) codis_group3_M(6379) codis_group3_S(6380) codis_group1_S(6380) codis_group2_S(6380)
参考文档： https://github.com/CodisLabs/codis/blob/release3.0/doc/tutorial_zh.md (此官方文档安装前必须看) 。 codis版本：3.0.3 版本 https://github.com/CodisLabs/codis/archive/3.0.3.zip go使用版本：go1.6.linux-amd64.tar.gz http://www.golangtc.com/download/
jdk版本：jdk1.7.0_71 zookeeper版本：zookeeper-3.4.8.tar.gz
Codis3.x 由以下组件组成：
Codis Server：基于 redis-2.8.21 分支开发。增加了额外的数据结构，以支持 slot 有关的操作以及数据迁移指令，具体的修改可以参考文档 redis的修改。
Codis Proxy：客户端连接的 Redis 代理服务, 实现了 Redis 协议。除部分命令不支持以外，表现的和原生的 Redis 没有区别（就像 Twemproxy）。 对于同一个业务集群而言，可以同时部署多个codis-proxy实例，不同 codis-proxy 之间由 codis-dashboard 保证状态同步。
Codis Dashboard：集群管理工具，支持 codis-proxy、codis-server 的添加、删除以及数据迁移等操作。在集群状态发生改变时，codis-dashboard 维护集群下所有 codis-proxy 的状态一致性。 对于同一个集群而言，同一个时刻 codis-dashboard 只能有 0个或者1个，所有对集群的修改都必须通过 codis-dashboard 完成。
Codis Admin：集群管理的命令行工具，可用于控制codis-proxy、codis-dashboard状态以及访问外部存储。
Codis FE：集群管理界面。多个集群可以共享同一个前端展示页面，通过配置文件管理后端 codis-dashboard 列表，配置文件可自动更新。
Codis HA：为集群提供高可用，依赖 codis-dashboard 实例，自动抓取集群各个组件的状态，会根据当前集群状态自动生成主从切换策略，并在需要时通过 codis-dashboard 完成主从切换。
Storage：为集群状态提供外部存储，提供Namespace概念，不同集群会按照不同product name进行组织；目前仅提供了Zookeeper 和Etcd两种实现，但是提供了抽象的interface可自行扩展。
相关组件安装配置 #vim /etc/sysctl.conf vm.overcommit_memory = 1
手工执行：echo never > /sys/kernel/mm/transparent_hugepage/enabled 并加到/etc/rc.local中。
注意： 公司的redis有时background save db不成功，通过log发现下面的警告，很可能由它引起的：
[13223] 17 Mar 13:18:02.207 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
内核参数overcommit_memory
它是内存分配策略，可选值：0、1、2。 0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否 则，内存申请失败，并把错误返回给应用进程。 1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。 2， 表示内核允许分配超过所有物理内存和交换空间总和的内存。
什么是Overcommit和OOM
Linux对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存，这种技术叫做Overcommit。当linux发现内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程)，以便释放内存。 当oom-killer发生时，linux会选择杀死哪些进程？选择进程的函数是oom_badness函数(在mm/oom_kill.c中)，该函数会计算每个进程的点数(0~1000)，点数越高，这个进程越有可能被杀死。每个进程的点数跟oom_score_adj有关，而且oom_score_adj可以被设置(-1000最低，1000最高)。
解决方法：
将vm.overcommit_memory 设为1即可，有三种方式修改内核参数，但要有root权限：
（1）编辑/etc/sysctl.conf ，加入vm.overcommit_memory = 1，然后sysctl -p使配置文件生效
（2）sysctl vm.overcommit_memory = 1
（3）echo 1 > /proc/sys/vm/overcommit_memory
二、环境准备
codis集群的搭建，需要zookeeper集群，可以参考这篇文《zookeeper集群搭建》。除了zookeeper集群之外，还需要安装go语言环境，因为codis是基于go语言开发的。
2.1 安装基础依赖 #yum -y install gcc make gcc-c++ automake lrzsz openssl-devel zlib-* bzip2-* readline* zlib-* bzip2-* git #yum -y install nmap unzip wget lsof xz net-tools mercurial
2.2 go语言环境搭建
下载go语言包，由于国内的网站对于一些网址是禁用的，所以还是要自行去网站下载，网址：http://www.golangtc.com/download/，下载完毕后解压到/usr/local如下：
#tar -C /usr/local -xf go1.6.linux-amd64.tar.gz
把go加入到系统的环境变量如下：
#vim /etc/profile
export PATH=\$PATH:/usr/local/go/bin
export GOPATH=/usr/local/go
让刚刚加入的环境变量生效，并查看go是否配置成功，如下：
#source /etc/profile
#go version
3. 安装codis
在/usr/local/go/src/下创建codis的编译安装目录github.com/CodisLabs，并将下载的codis包解压到这个目录下。
#mkdir -pv /usr/local/go/src/github.com/CodisLabs/
#tar -C /usr/local/go/src/github.com/CodisLabs/ -xf /usr/local/src/codis-3.1.tar.gz
#cd /usr/local/go/src/github.com/CodisLabs/
#mv codis-3.1 codis
#cd codis
#make
编译成功后在codis下面的bin目录下会有assets codis-admin codis-dashboard codis-fe codis-ha codis-proxy codis-server redis-benchmark redis-cli version等文件，assets是codis-dashboard http服务需要的前端资源，需要和codis-dashboard放置在同一目录下。
4.1 编辑redis配置文件
每台codis服务器上，要启动两个redis实例（也可以启动多个redis实例），先配置两个实例，从redis实例的配置文件中找到下列参数选项并按如下进行修改：
创建几个数据目录
#mkdir /usr/local/codis
#mkdir /var/log/redis
#vim /usr/local/go/src/github.com/CodisLabs/codis/extern/redis-test/conf /6379.conf
daemonize yes
pidfile /var/run/redis6379.pid
port 6379
logfile /var/log/redis/6379.log
dbfilename dump6379.rdb
dir /usr/local/codis/
配置第二个redis实例6380.conf同上设置。
每台codis服务器上redis配置完毕后，启动redis实例，如下：
#cd /usr/local/go/src/github.com/CodisLabs/codis/bin
#./codis-server ../extern/redis-test/conf/6379.conf &
#./codis-server ../extern/redis-test/conf/6380.conf &
#ps -ef |grep codis-server
4.2 Codis Dashboard
Coddis3.0的dashboard与codis 2.0有所不同，作为集群管理工具，它支持codis-proxy,codis-server的添加、删除以及数据迁移等操作。在集群状态发生改变时，codis-dashboard 维护集群下所有 codis-proxy 的状态一致性。有以下两点注意事项：
l 对于同一个业务集群而言，同一个时刻codis-dashboard只能有0个或者1个；
l 所有对集群的修改都必须通过codis-dashboard完成。
4.2.1 配置dashboard
默认配置文件dashboard.toml可由codis-dashboard生成。
#bin/codis-dashboard --default-config | tee dashboard.toml（就是dashboard.conf）
生成dashboard.toml文件，可自行配置。
# Set Coordinator, only accept"zookeeper"&"etcd"
coordinator_name = "zookeeper"
coordinator_addr = "192.168.33.6:2181" #zookeeper是集群的话就写多个ip和端口用逗号隔开
# Set Codis Product {Name/Auth}
product_name = "codis-demo"
product_auth = ""
# Set bind address for admin(rpc), tcp only.
admin_addr = "0.0.0.0:18080"
coordinator_name 外部存储类型，接受 zookeeper/etcd
coordinator_addr 外部存储地址
product_name 集群名称，满足正则 \w[\w\.\-]*
product_auth 集群密码，默认为空
admin_addr RESTful API 端口
4.2.2 启动dashboard
#nohup bin/codis-dashboard --ncpu=4 --config=dashboard.toml（这里指定dashboard.conf也可以） --log=dashboard.log --log-level=WARN &
#bin/codis-dashboard -h
Usage:
codis-dashboard [--ncpu=N][--config=CONF] [--log=FILE] [--log-level=LEVEL] [--host-admin=ADDR]
codis-dashboard --default-config
codis-dashboard --version
说明：
--ncpu=N 最大使用 CPU 个数
-c CONF, --config=CONF 指定启动配置文件
-l FILE, --log=FILE 设置 log 输出文件
--log-level=LEVEL 设置log输出等级：INFO,WARN,DEBUG,ERROR；默认INFO，推荐WARN
正常关闭dashboard命令： bin/codis-admin --dashboard=192.168.33.6:18080 --shutdown
4.3 Codis Proxy
l 对于同一个业务集群而言，可以同时部署多个codis-proxy 实例；
l 不同 codis-proxy 之间由 codis-dashboard 保证状态同步。
4.3.1 配置proxy
默认配置文件 proxy.toml 可由 codis-proxy 生成。
#bin/codis-proxy --default-config | tee proxy.toml（proxy.conf）
生成proxy.toml可自行配置。
# Set Codis Product {Name/Auth}.
product_name = "codis-demo"
product_auth = ""
# Set bind address for admin(rpc), tcp only.
admin_addr = "0.0.0.0:11080"
# Set bind address for proxy, proto_type can be "tcp","tcp4", "tcp6", "unix" or "unixpacket".
proto_type = "tcp4"
proxy_addr = "0.0.0.0:19000"
# Set jodis address & session timeout.
jodis_addr = ""
jodis_timeout = 10
# Proxy will ping-pong backend redis periodly to keep-alive
backend_ping_period = 5
# If there is no request from client for a long time, the connectionwill be droped. Set 0 to disable.
session_max_timeout = 1800
# Buffer size for each client connection.
session_max_bufsize = 131072
# Number of buffered requests for each client connection.
# Make sure this is higher than the max number of requests for eachpipeline request, or your client may be blocked.
session_max_pipeline = 1024
# Set period between keep alives. Set 0 to disable.
session_keepalive_period = 60
product_name 集群名称，参考dashboard参数说明
product_auth 集群密码，默认为空
admin_addr RESTfulAPI 端口
proto_type Redis 端口类型，接受tcp/tcp4/tcp6/unix/unixpacket
proxy_addr Redis 端口地址或者路径
jodis_addr Jodis注册zookeeper地址
jodis_timeout Jodis注册sessiontimeout时间，单位second
jodis_compatible Jodis注册 zookeeper 的路径
backend_ping_period 与codis-server 探活周期，单位second，0表示禁止
session_max_timeout 与client 连接最大读超时，单位second，0表示禁止
session_max_bufsize 与client 连接读写缓冲区大小，单位byte
session_max_pipeline 与client 连接最大的pipeline大小
session_keepalive_period 与client 的 tcp keepalive周期，仅tcp有效，0表示禁止
4.3.2 启动proxy
#nohup bin/codis-proxy --ncpu=4 --config=proxy.toml \
--log=proxy.log --log-level=WARN &
codis-proxy启动后，处于 waiting 状态，监听proxy_addr 地址，但是不会accept连接。添加到集群并完成集群状态的同步，才能改变状态为online。添加的方法有以下两种：
l 通过codis-fe添加：通过Add Proxy按钮，将admin_addr加入到集群中；
l 通过codis-admin命令行工具添加，方法如下：
#bin/codis-admin --dashboard=192.168.33.6:18080 --create-proxy -x 192.168.33.6:11080
其中192.168.33.6:18080 以及192.168.33.6:11080 分别为dashboard和proxy的admin_addr 地址。
添加过程中，dashboard会完成如下一系列动作：
① 获取 proxy 信息，对集群name以及auth进行验证，并将其信息写入到外部存储中；
② 同步slots状态；
③ 标记proxy状态为online，此后proxy开始accept连接并开始提供服务。
#./codis-admin --proxy=192.168.33.6:11080 --auth="xxxxx"(有就加，没有就不加) --shutdown
#bin/codis-proxy -h
Usage:
codis-proxy [--ncpu=N][--config=CONF] [--log=FILE] [--log-level=LEVEL] [--host-admin=ADDR]
[--host-proxy=ADDR] [--ulimit=NLIMIT]
codis-proxy --default-config
codis-proxy --version
Options:
--ncpu=N 最大使用 CPU 个数
-c CONF, --config=CONF 指定启动配置文件
-l FILE, --log=FILE 设置 log 输出文件
--log-level=LEVEL 设置 log 输出等级：INFO,WARN,DEBUG,ERROR；默认INFO，推荐WARN
--ulimit=NLIMIT 检查ulimit -n的结果，确保运行时最大文件描述不少于NLIMIT
4.4 Codis FE
4.4.1 集群管理界面
l 多个集群实例可以共享同一个前端展示页面；
l 通过配置文件管理后端codis-dashboard列表，配置文件可自动更新。
4.4.2 配置codis-fe
配置文件codis.json（fe.conf）可以手动编辑，也可以通过codis-admin从外部存储中拉取。
#bin/codis-admin --dashboard-list --zookeeper=192.168.33.6:2181 | tee codis.json
[
{
"name": "codis-demo",
"dashboard": "127.0.0.1:18080"
}
]
4.4.3 启动codis-fe
#nohup bin/codis-fe --ncpu=4 --log=fe.log --log-level=WARN \
--dashboard-list=codis.json --listen=0.0.0.0:18090 & #(这里指定端口号为18090是为了防止和codis-dashboard的端口号18080冲突)
#bin/codis-fe -h
Usage:
codis-fe [--ncpu=N][--log=FILE] [--log-level=LEVEL] --dashboard-list=LIST --listen=ADDR
codis-fe --version
Options:
--ncpu=N 最大使用 CPU 个数
-d LIST,--dashboard-list=LIST 配置文件，能够自动刷新
-l FILE, --log=FILE 设置 log 输出文件
--log-level=LEVEL 设置 log 输出等级：INFO,WARN,DEBUG,ERROR；默认INFO，推荐WARN
--listen=ADDR HTTP 服务端口
打开浏览器，在地址栏里输入http://192.168.33.6:18090，通过管理界面操作Codis。
1、创建组:
输入编号1，点击New Group，第一组创建完成。
2、添加实例
在后面输入组的id号，然后在后面框内输入redis实例所在机器的ip地址和redis实例的端口号，点击Add Server即可添加完成，再添加第二个实例完成后G-1那一列会有向上的箭头，点击后可升为master，点击第二个redis实例中master那一列的 图标即可将此实例设置为slave， 此图标可以将对应的实例从该组中删除，如下两图：
3、对slots进行分组
如下图所示，输入所要分组的slots的起和止的范围，然后输入组ID，点击后面按钮即可。
4、添加管理proxy
如下图所示，在框内输入proxy所对应的ip地址和端口号点击Add proxy即可。
5、数据迁移，写好需要迁移数据的起和止的范围以及组ID，点击后面按钮即可数据迁移；当点击Action Disabled 的Disable Migration后，出现Enable Migration，并勾选Show Actions后，后面显示迁移状态，以及所迁移的slots会显示在 slots图上，如下图：
除了图形界面进行如上操作外，还可以通过命令进行操作。
创建组:
#bin/codis-admin --dashboard=192.168.33.6:18080 --create-group --gid=1 #bin/codis-admin --dashboard=192.168.33.6:18080 --create-group --gid=2
组添加服务器：
#bin/codis-admin --dashboard=192.168.33.6:18080 --group-add --gid=1 \
--addr=192.168.33.6:6379 #bin/codis-admin --dashboard=192.168.33.6:18080 --group-add --gid=1 \
--addr=192.168.33.6:6380
把从库跟主库同步（同一组的两个实例都要执行）： #bin/codis-admin --dashboard=192.168.33.6:18080 --sync-action --create \
--addr=192.168.33.6:6379
#bin/codis-admin --dashboard=192.168.33.6:18080 --sync-action --create \
--addr=192.168.33.6:6380
若从库需要提升为master，操作如下: #bin/codis-admin --dashboard=192.168.33.6:18080 --promote-server --gid=1 \
--addr=192.168.33.6:6380(从库ip和端口)
初始化 slots并设置 server group服务的slot范围((只在一节点执行一次)sid是slot的编号。Codis采用Pre-sharding技术来实现数据的分片, 默认分成1024个slots (0-1023), 对于每个key来说，通过以下公式确定所属的Slot Id : SlotId = crc32(key) % 1024每一个slot都会有一个且必须有一个特定的server group id来表示这个slot的数据由哪个server group来提供。
#bin/codis-admin --dashboard=192.168.33.6:18080 --slot-action --create-range --beg=0 \
--end=300 --gid=1 #bin/codis-admin --dashboard=192.168.33.6:18080 --slot-action --create-range --beg=301 \
--end=601 --gid=2
4.5 Codis HA（可选组件）
注意：Codis HA工具仅仅是Codis 集群HA 的一部分，单独工作能力有限。
l 默认以 5s为周期，codis-ha会从codis-dashboard中拉取集群状态，并进行主从切换；
l codis-ha 在以下状态下会退出：
i．从 codis-dashboard 获取集群状态失败时；
ii．向codis-dashboard发送主从切换指令失败时。
l codis-ha在以下状态下不会进行主从切换：
i．存在proxy状态异常：因为提升主从需要得到所有proxy的确认，因此必须确保操作时所有proxy都能正常响应操作指令；
ii．网络原因造成的master异常：若存在slave满足slave.master_link_status == up，通常可以认为master并没有真的退出，而是由于网络原因或者响应延迟造成的master状态获取失败，此时codis-ha不会对该group进行操作；
n没有满足条件的slave时。提升过程会选择满足slave.master_link_status == down，并且slave.master_link_down_since_seconds最小的进行操作。这就要求被选择的slave至少在过去一段时间内与master是成功同步状态，这个时间间隔是2d+5，其中d是codis-ha检查周期默认5秒。
注意：应用codis-ha时还需要结合对codis-proxy和codis-server的可用性监控，否则codis-ha无法保证可靠性。
需要注意：codis-ha将其中一个slave升级为master时，该组内其他slave是不会自动改变状态的，这些slave仍将试图从旧的master上同步数据，因而会导致组内新的master和其他slave之间的数据不一致。因为redis的slaveof命令切换master时会丢弃slave上的全部数据，从新master完整同步，会消耗资源。因此，当出现主从切换时，需要管理员手动创建新的sync action来完成新master与slave之间的数据同步。
4.5.1 启动codis-ha
#nohup bin/codis-ha --log=ha.log --log-level=WARN --dashboard=192.168.33.6:18080 &
4.5.2 参数说明
#bin/codis-ha -h
Usage:
codis-ha [--log=FILE][--log-level=LEVEL] --dashboard=ADDR
codis-ha --version
Options:
-l FILE, --log=FILE 设置 log 输出文件
--log-level=LEVEL 设置 log 输出等级：INFO,WARN,DEBUG,ERROR；默认INFO，推荐WARN
4.6 Codis Admin（命令行工具）
注意：使用 codis-admin 是十分危险的
4.6.1 codis-dashboard异常退出的修复
当codis-dashboard启动时，会在外部存储上存放一条数据，用于存储dashboard信息，同时作为LOCK 存在。当codis-dashboard安全退出时，会主动删除该数据。当codis-dashboard异常退出时，由于之前 LOCK 未安全删除，重启往往会失败。因此codis-admin提供了强制删除工具：
1．确认codis-dashboard进程已经退出（很重要）；
2．运行codis-admin删除LOCK：
#bin/codis-admin --remove-lock --product=codis-demo --zookeeper=192.168.33.6:2181
通常codis-proxy都是通过codis-dashboard进行移除，移除过程中codis-dashboard为了安全会向 codis-proxy 发送 offline 指令，成功后才会将proxy信息从外部存储中移除。如果codis-proxy异常退出，该操作会失败。此时可以使用codis-admin工具进行移除：
1．确认 codis-proxy 进程已经退出（很重要）；
2．运行 codis-admin 删除 proxy：
先查看proxy状态： #bin/codis-admin --dashboard=192.168.33.6:18080 --proxy-status
#bin/codis-admin --dashboard=192.168.33.6:18080 --remove-proxy \
--token=6a2db3c9ac07ba8857d4bc79ca6d191c --force
选项--force 表示，无论offline操作是否成功，都从外部存储中将该节点删除。所以操作前，一定要确认该 codis-proxy 进程已经退出。
proxy正常关闭： codis-admin [-v] --proxy=ADDR [--auth=AUTH] --shutdown #bin/codis-admin --proxy=192.168.33.6:11080 --shutdown
#bin/codis-admin --proxy=192.168.33.6:11080 --auth="xxxxx" --shutdown
若proxy id在FE上搞乱了，可以找时间从FE上移除所有proxy，然后全部按顺序启动，就会产生正常顺序的proxy id。
Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]
-h <hostname> Server hostname (default 127.0.0.1) --主机ip地址
-p <port> Server port (default 6379) --端口
-s <socket> Server socket (overrides host and port) --如果测试在服务器上可以用socket方式
-a <password> Password for Redis Auth --redis的认证密码
-c <clients> Number of parallel connections (default 50) --客户端连接数
-n <requests> Total number of requests (default 100000) --总请求数
-d <size> Data size of SET/GET value in bytes (default 2) --set、get的value大小
-dbnum <db> SELECT the specified db number (default 0) --选择哪个数据库测试（一般0-15）
-k <boolean> 1=keep alive 0=reconnect (default 1) --是否采用keep alive模式
-r <keyspacelen> Use random keys for SET/GET/INCR, random values for SADD --随机产生键值时的随机数范围
-P <numreq> Pipeline <numreq> requests. Default 1 (no pipeline). --pipeline的个数（如果使用pipeline会把多个命令封装在一起提高效率）
-q Quiet. Just show query/sec values --仅仅查看每秒的查询数
--csv Output in CSV format --用csv方式输出
-l Loop. Run the tests forever --循环次数
-t <tests> Only run the comma separated list of tests. The test --指定命令
names are the same as the ones produced as output.
-I Idle mode. Just open N idle connections and wait. --仅打开n个空闲链接
Examples:
Run the benchmark with the default configuration against 127.0.0.1:6379:
\$redis-benchmark
Use 20 parallel clients, for a total of 100k requests, against 192.168.1.1:
\$redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20 --测试set、get、mset、sadd等场景下的性能
Fill 127.0.0.1:6379 with about 1 million keys only using the SET test:
\$redis-benchmark -t set -n 1000000 -r 100000000 --测试set随机数的性能
Benchmark 127.0.0.1:6379 for a few commands producing CSV output:
\$redis-benchmark -t ping,set,get -n 100000 --csv --使用csv的输出方式测试
Benchmark a specific command line:
\$ redis-benchmark -r 10000 -n 10000 eval 'return redis.call("ping")' 0 --测试基本命令的速度
Fill a list with 10000 random elements:
\$ redis-benchmark -r 10000 -n 10000 lpush mylist __rand_int__ --测试list入队的速度
zk的查看操作
slot: ls /codis3/codis_test/slots
或者连接redis的实例执行slotshashkey （\$key）可以查看此键值在哪个slot上。
proxy:
ls /codis3/codis_test/proxy get /codis3/codis_test/proxy/proxy-ca78ed6ba0d07b86e7f0c1e346f79cba
server: ls /codis3/codis_test/group/group-0001
查询zk中的proxy状态： [zk: 127.0.0.1:2181(CONNECTED) 4] ls /zk/codis/db_hls_prod/proxy [815867a35f921bcc3abb02109cca1f75, 6dd30d40f676564495d56ab16211e039] [zk: 127.0.0.1:2181(CONNECTED) 5] get /zk/codis/db_hls_prod/proxy/9f04676d4e82b2ba7e8f8c3a3faeee28 { "id": 1,
"token": "9f04676d4e82b2ba7e8f8c3a3faeee28" "start_at": "2016-07-01 16:42:39.219656807 +0800 CST",
"admin_addr": "192.168.33.6:11080",
"proto_type": "tcp4",
"proxy_addr": "192.168.33.6:19000",
"product_name": "codis-demo",
"pid": 2572,
"pwd": "/usr/local/go/src/github.com/CodisLabs/codis/bin",
"sys": "Linux linuxcast.net 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux" } cZxid = 0x2000c432b ctime = Fri Jul 01 16:42:42 CST 2016 mZxid = 0x2000c432b mtime = Fri Jul 01 16:42:42 CST 2016 pZxid = 0x2000c432b cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x2550b2029dbbccd dataLength = 167 numChildren = 0
要删除的话：rmr /codis3/codis_test
其他参考：
(2)dashboard提供的api接口 http://debugAddr/setloglevel?level=debug http://debugAddr/debug/vars #主要是获取ops信息还可以设置日志级别，浏览器访问proxy的debug_addr对应地址/debug/vars路径，可以看到每个proxy的qps信息。
(3)codis-proxy的服务日志中产生的信息解释 quit : client主动发的quit指令 EOF : 连接直接断开了，就是proxy从client的tcp读的时候遇到EOF了
codis每次主动关闭client的连接都会打log的，一般来说主要可能有：非法操作、该请求连的底层redis挂了、这个session很久没请求触发了proxy这边的清理逻辑。
session_max_timeout=1800 如果30分钟内没有任何ops 那么codis就主动关闭这个连接。嗯，主要是有人反馈说有时候client主动关了连接，但是proxy这边没收到close的消息，导致proxy最后积累了一大堆连接把资源吃满了。
(4)NaN GB因为redis配置文件中没有设置内存maxmemory参数。
(5)codis中所有的读写操作都是在redis-master上执行的，redis-slave只负责数据的冗余，当master出现down之后可以进行master和slave的切换。
(6)在codis集群中product是用来区分是否为同一个集群的。所以如果是同一个集群，那么dashboard和codis-proxy中的product要设置的一样，否则就面临下面这个问题zk: node does not exist。 codis-proxy配置文件中的proxy_id 是用来区分同一个集群下的不同成员，所以这个参数要唯一。
(7)codis-ha只负责在master挂掉的时候自动选择一个slave提升为master，但没有把剩余的slave重新挂在新的master上，而且也没有确保选择的slave是最优的。
(8)Too many open files：在用python多线程对redis进行压力测试的时候，压力超过4000的时候就出现这种问题。2台codis-proxy支持并发2-3w没有太大的问题。
(10)同一个group中可以实现redis数据的主从复制，但是不同的group中无法实现。如果同一个group中所有的master和slave都挂掉了，那么数据就丢失了，但是如果还查询挂掉的group中的key就会提示错误，并且那个key也就会占用啦，所有的写操作codis-proxy就不会发送到挂掉的group上去了。
(11)同一个Group中的codis-server 实例下，多个slave 是否会分担master的读请求？codis的设计理念是更注重一致性，redis的主从同步不是强一致的，因此codis不支持读写分离。
(12)一个集群中只能有一个dashboard服务处于运行状态，可以有多个dashboard但是同时只能有一个服务处于running状态。
Jodis 与 HA
因为 codis-proxy 是无状态的，可以比较容易的搭多个实例，达到高可用性和横向扩展。对Java 用户来说，可以使用基于Jedis的实现 [Jodis](https://github.com/CodisLabs/jodis) ，来实现 proxy层的HA，它会通过监控zookeeper上的注册信息来实时获得当前可用的proxy列表，既可以保证高可用性，也可以通过轮流请求所有的proxy实现负载均衡。如果需要异步请求，可以使用基于Netty开发的 [Nedis](https://github.com/CodisLabs/nedis)。
对下层的 redis 实例来说，当一个 group 的 master 挂掉的时候，应该让管理员清楚，并手动操作，因为这涉及到了数据一致性等问题（redis的主从同步是最终一致性的）。因此codis不会自动的将某个slave 升级成 master。关于外部 codis-ha工具，这是一个通过codis-dashboard开放的RESTful API实现自动切换主从的工具，该工具会在检测到master挂掉的时候主动应用主从切换策略，提升单个slave成为新的master。
需要注意codis 将其中一个slave升级为master时，该组内其他slave实例是不会自动改变状态的，这些slave仍将试图从旧的master上同步数据，因而会导致组内新的master和其他slave之间的数据不一致。因此当出现主从切换时，需要管理员手动创建新的sync action来完成新master与slave之间的数据同（codis-ha 不提供自动操作的工具，因为这样太不安全了）。
Docker 部署
Codis 3.x 起，开始正式支持Docker部署。这就需要codis-dashboard以及codis-proxy能够外部的 `listen` 地址暴露出来并保存在外部存储中。
+ codis-proxy 增加了 `--host-admin` 以及 `--host-proxy` 参数；
+ codis-dashboard 增加了 `--host-admin` 参数。
以 codis-proxy 的 Docker 为例：
#docker run --name "Codis-Proxy" -d -p 29000:19000 -p 21080:11080 codis-image \
codis-proxy -c proxy.toml --host-admin 100.0.1.100:29000 --host-proxy 100.0.1.100:21080
codis-proxy 在启动后，会使用 `--host-admin` 和 `--host-proxy` 参数所指定的实际地址替换Docker内监听的地址，向codis-dashboard注册。例如使用Jodis 的过程中，客户端就能够通过 `100.0.1.100:29000` 来访问 proxy 实例。codis-dashboard 也是相同的道理，会使用`--host-admin`地址向外部存储注册，这样codis-fe也能通过该地址正确的对codis-dashboard进行操作。具体样例可以参考 `scripts/docker.sh`。
从Codis 2.x 升级
Codis 3.x 修改了codis-dashboard与codis-proxy 之间的通信方式，因此Codis 2.x 并不兼容。但是提供了手动升级方案。
注意1：升级时，需要保证所有slot都处在`online`状态，即没有任何数据迁移操作正在进行。
注意2：升级完成后，需要手动关闭Codis 2.x 的所有proxy和config组件。
step 1. 导出配置文件
#bin/codis-admin --config-dump --product=codis_v2.0 --zookeeper=127.0.0.1:2181 -1 | tee codis_v2.0.json
该命令会从 zookeeper 上拉取 `/zk/codis/db_codis_v2.0` 下全部的文件，并组织成json格式并输出。
选项 `-1` 表示配置文件是 Codis 1.x 版本，缺省是 Codis 3.x 版本。
step 2. 转换配置文件
#bin/codis-admin --config-convert codis_v2.0.json | tee codis_v3.0.json
该命令会将 Codis 1.x 版本的配置文件中有效信息提取出来，并转成Codis 3.x 版本的配置文件并输出。
step 3. 更新配置文件
注意：更新配置文件时，请确保Codis 3.x 中该集群不存在，否则可能导致更新失败或者集群状态异常。
#bin/codis-admin --config-restore=codis_v3.0.json --product=codis_v3.0 \
--zookeeper=127.0.0.1:2181 --confirm
该命令会将 Codis 3.x 版本的配置文件提交到 `/codis3/codis_v3.0` 目录下。选项`--confirm`选项表示确认提交，缺省时该命令仅打印配置文件作为调试。
step 4. 启动 Codis 3.x dashboard 以及proxy
过程参考之前章节。因为集群信息已经存在，所以可以安全启动 codis-dashboard，并逐一添加 codis-proxy 到集群中。
step 5. 关闭 Codis 2.x dashboard 以及 proxy
Codis 3.x 的组件兼容 Jodis 协议
因为Codis 2.x与Codis 3.x在外部存储中的组织结构不同，所以可以安全的`kill`掉全部Codis 2.x组件。
注意：关闭过程请不要使用 `kill -9`，因为旧组件在退出时会自动清理部分注册信息。
欢迎加入 343595434 codis技术交流群，这里有codis作者以及各位技术大牛为你详解最前沿的技术，这里是技术的峰会，我们要让每个人都成为技术霸！
扫一扫
03-03
2914
2914
07-16
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
