目录
Codis 3.x 版本
- 最新 release 版本为 codis-3.2，codis-server 基于 redis-3.2.8
- 支持 slot 同步迁移、异步迁移和并发迁移，对 key 大小无任何限制，迁移性能大幅度提升
- 相比 2.0：重构了整个集群组件通信方式，codis-proxy 与 zookeeper 实现了解耦，废弃了codis-config 等
- 元数据存储支持 etcd/zookeeper/filesystem 等，可自行扩展支持新的存储，集群正常运行期间，即便元存储故障也不再影响 codis 集群，大大提升 codis-proxy 稳定性
- 对 codis-proxy 进行了大量性能优化,通过控制GC频率、减少对象创建、内存预分配、引入
cgo、jemalloc等，使其吞吐还是延迟，都已达到 codis 项目中最佳 - proxy 实现 select 命令，支持多 DB
- proxy 支持读写分离、优先读同 IP/同 DC 下副本功能
- 基于 redis-sentinel 实现主备自动切换
- 实现动态 pipeline 缓存区（减少内存分配以及所引起的 GC 问题）
- proxy 支持通过 HTTP 请求实时获取 runtime metrics，便于监控、运维
- 支持通过 influxdb 和 statsd 采集 proxy metrics
- slot auto rebalance 算法从 2.0 的基于 max memory policy 变更成基于 group 下 slot 数量
- 提供了更加友好的 dashboard 和 fe 界面，新增了很多按钮、跳转链接、错误状态等，有利于快速发现、处理集群故障
- 新增
SLOTSSCAN指令，便于获取集群各个 slot 下的所有 key - codis-proxy 与 codis-dashbaord 支持 docker 部署
Codis 扩容
理论上和部署codis无太大差别，有一些小的事项需要注意
codis 可使用容量计算： 单实例如果是8G的话假设我们有3个group
则 3 * 8G = 24GB
group 数量 * 单实例分配memory = 可用容量
组内可以有多个实例，关系为一个master 多slave模式，默认读写都是从master ，slave只负责同步master的数据，当master 挂了以后通过哨兵重新选举master 进行切换。
扩容机器
| 服务器 | 系统 | 版本 |
|---|---|---|
10.136.47.3 | Centos7 | 3.2.11 |
10.103.17.50 | Centos7 | 3.2.11 |
1. 登陆10.126.174.24(ansiable)服务器，移动到该目录下
|
|
2. 修改ip.txt，将要扩容的服务器ip写入此文件。此处保留server 、proxy 如下
|
|
3. 修改/home/sunwenbo/codis-capacity/ansible-codis/roles/vars/vars.yml 文件
展开源码
| client-output-buffer-limit normal | client-output-buffer-limit slave | client-output-buffer-limit pubsub |
|---|---|---|
| 对于普通客户端来说，限制为0，也就是不限制。因为普通客户端通常采用阻塞式的消息应答模式，何谓阻塞式呢？如：发送请求，等待返回，再发送请求，再等待返回。这种模式下，通常不会导致Redis服务器输出缓冲区的堆积膨胀； | 对于slave客户端来说，大小限制是256M，持续性限制是当客户端缓冲区大小持续60秒超过64M，则关闭客户端连接。 | 对于Pub/Sub客户端（也就是发布/订阅模式），大小限制是8M，当输出缓冲区超过8M时，会关闭连接。持续性限制是，当客户端缓冲区大小持续60秒超过2M，则关闭客户端连接； |
redis的client output buffer limit可以用来强制断开那些无法从redis服务器端读取数据 足够快的客户端。一个常见的案例就是一个Pub/Sub中，消费者的速度无法和消息生产者的 速度相匹配。client output buffer limit可以应用在三类的客户端中：
- 普通client，包括monitor
- slave用来同步master数据的client
- Pub/Sub模式中订阅了至少一个channel或者模式的client
该配置的语法是:
|
|
连接到redis server的客户端，如果它不能快速消费服务端返回给他的数据，其在server 端占用的内存(output buffer size)会越来越多，一旦大小超过hard limit, 或者超过 soft limit一段时间，server端会立即断开该客户端，并且释放该客户端所占用的资源。 例如，若hard limit配置为32M， soft limit配置为10M/10s，一旦output buffer使用 的内存到达30M，或者连续超过10M的时间维持10s，那么客户端的连接会被立刻断开。
默认情况下，对普通客户端的output buffer size不设置限制，因为server只有在其请求 数据的时候才会发送；只有异步客户端请求数据比接收快的时候，才会产生out buffer size膨胀的问题。对于用作pubsub和slave的客户端，由于server会主动把数据推送给 它们，需要设置output buffer size的限制。
可以通过将hard limit/soft limit都设置为0的方式禁用该配置项，如：
|
|
4. 执行扩容命令，ansiable无返回报错，则认为部署成功
|
|
5. 登陆codis-fe管理页面进行扩容配置
-
5.1 扩容proxy节点，点击New Proxy加新部署的实例加入集群
-
5.2 扩容server节点，新建group，之后将扩容的节点加入group中。 注意：实例加入group规则，不要将同一台机器上的实例加到一个gourp中，防止服务器宕机，实例无法切换角色
6. 手动调整实例角色master、slave
点击Master列底色为红色实例后边的小扳手
这时codis会进行master、slave的角色分配，可以看到实例 10.136.47.3:6381 被认为是实例10.103.17.50:6380的slave，也就是说10.103.17.50:6380为master
默认会将组内的第一行的实例选举为master，为了可以提供高可用和高性能的服务，我们要尽量避免master在同一台机器上。可以通过页面来设置实例的角色如下图
点击PROMOTE，可以使该实例为master，可以看到10.136.47.3:6381 已经来到了group 5 的第一行。
7. 将group中的服务器加入到codis集群，分配Slots
此时我们已经将codis-server部署、创建group、并设置服务器实例master角色的分配，下面需要将扩容的codis实例加入到codis集群，实现扩容
Slots平均分配到每个group，扩容很简单只需要在页面点击Rebalance All Slots 按钮codis就会自动的分配Slots了，可以看到未分配时，我们看到的是codis将1024个槽位分配给之前已经存在的3个group
点击Rebalance All Slots后codis会发现新增了两个组，并划分去槽位分配给group4、group5
点击ok ，codis会将具体的槽位分配group，稍等一会就分配好了，下图为分配槽位后的截图，可以看到已经有5个组了
这时候再看我们新建的group，已经开始同步数据了
执行如下图的两个步骤，将codis server 设置为活跃状态，并点击SYNC进行同步
返回如下页面则扩容成功
Codis 缩容
根据codis github 描述 codis 3.x版本已经废除了codis-config管理工具，使用Codis内置的命令可以进行slot迁移和Codis Dashboard进行管理。
相关资料
https://github.com/CodisLabs/codis/blob/release3.2/doc/redis_change_zh.md
https://github.com/CodisLabs/codis/blob/release3.2/doc/tutorial_zh.md
现将我们扩容的group 5对应的两个实例从集群删除掉
1. codis-fe 管理页面进行缩容
假设我们要删除group 5，可以看到当前给group 5分配的槽位是图中紫色的两个部分（codis 一共有1024个槽位。 0 - 1023）
需要group 5 slots的数据迁移到其他的group ,指定slot big 和slot end to gourp 之后点击Migrate Range，则开始迁移
此时看到group的数据已经少了一大半了。接下来吧剩余紫色的slot槽位迁移到其他gropu
由于刚才我们将888 - 1023 的slot 都迁移到了gourp1 导致group1的内存使用接近满了。注意：这里需要注意的是如果我们要迁移的slot很大的话，要找好资源足够的组去存储，以免数据丢失。
所以把未迁移的slot 迁移到group2
这时再看gourp 5,已经没有数据了
2. 删除codis实例及group
删除实例
删除组 需要注意的是如果要进行缩容的话，一定要先将对应的group的slot进行迁移，否则删除group中master实例的时候会报错。
到这里缩容就完成了
codis bgsave 工作原理
相关参考资料https://www.cnblogs.com/evakang/p/12078919.html
我们把Redis分为三个部分，分别是客户端、主节点以及从节点，如果从节点要同步主节点的数据，它首先会发Sync指令给主节点，主节点收到指令之后会执行BGSAVE命令生成RDB文件，这个RDB文件指的是快照文件，它是Redis两种备份方式的其中一种，另一种叫AOF，它的原理是将所有的写入指令存入文件，mysql的binlog原理是一样的。
如果主节点在生成RDB的过程当中，客户端发来了写入指令，这个时候主节点会把指令全部写入缓冲区，等RDB生成完了，会把RDB文件发送给从节点，最后再把缓冲区的指令发送给从节点。这样就完成了整个的复制。
我们刚才说单纯地做主从是有缺陷的，这个缺陷就是如果我们要存储海量的数据，那么BGSAVE指令生成的RDB文件会非常巨大，这个文件传送给从节点也会非常慢，如果缓冲区命令很多的话，从节点同步数据时也会执行很久，所以，要解决单点问题和海量存储问题，还是要考虑做集群。
codis-admin 常用命令
|
|
1002
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
