目录
(2)codis dashboard(codis config)
单节点redis实例的缺陷:
(1)存储数据量大和高并发的情况下内存容易暴涨
(2)一个redis内存受限,受限内存过大,数据同步全量同步时间过长,会增加同步失败的风险,另一个是redis都是部署在云服务器上的,这个也会受到CPU的使用率影响
redis集群的目的:
将多redis实例cpu计算能力汇聚到一起,完成大数据和高并发量的读写
本质:
codis是一个代理中间件,用的是GO语言开发的,起一个中间代理的作用,能够吧所有的redis实例当成一个来使用,在客户端操作SDK的时候和操作Redis的时候是一样的,没有差别。(无状态)
代理中间件,通过内存保存着槽位和实例节点之间的映射关系,槽位间的信息同步交给zookeeper管理
不支持事务和官方的某些命令,原因是分布多个的redis实例没有回滚机制和WAL,所以是不支持的。
分片原理:
将所有key分成1024个槽,对应的就是redis的集群,codis在内存中维护槽与redis的关系,槽的数目可以被配置,现将key进行CRC32后得到一个32位的数字,然后再hash%1024后得到一个余数,这个值就是这个key对应的槽,这槽后面就是redis的实例。
codis之间的槽位同步:
一个codis节点仅在自己的内存中维护槽位与实例关系,那么操维信息如何在多个codis节点同步?-》使用zookeeper
当codis的codis dashboard改变槽位信息的时候其他codis会监听到zookeeper的变化,即时同步。
codis的扩容:
codis有自动均衡策略,当你新增一个redis节点,codis会在机器空闲的时候观察redis对应的slot数,不平衡自动进行迁移,迁移方式是会在原redis和新redis都保留槽位信息,若要将key打进将要迁移或者正在迁移的旧槽位,此时codis处理机制是现将key强制迁移到新的redis节点,再告诉codis下次有新的key打入槽位,转发到新节点。
codis的牺牲:
codis不支持事务,单个集合总容量不要超过1M否则迁移会有卡顿感,在Codis中增加了proxy当中转层,所以在网络开销上回避单个redis的性能有所下降,所以会有些性能消耗,可以增加proxy数量来避免性能损耗(若是只有一个proxy一般下降20%左右的性能)。
codis四个部分及作用:
(1)codis proxy
客户端连接的redis代理服务,本身实现了redis协议,表现和一个原生的redis没区别,对于一个业务来说,可以部署多个codis-proxy,本身是无状态的。
(2)codis dashboard(codis config)
是codis的管理工具,支持删除添加redis节点,添加删除proxy节点,发起数据迁移等操作,本身自带http server服务,会启动一个dashboard服务,可以直接在浏览器上观察codis集群的运行状态。
(3)codis redis(codis server)
是codis项目维护的一个redis分支,加入了slot的支持和原子的数据迁移指令,codis上层的proxy和config直邮和这个版本的redis交互才能正常使用。
(4)ZooKeeper/Etcd
依赖zookeeper存放数据路由表和codis-proxy节点的元信息,codis-config发送的信息都会通过ZooKeeper同步到各个存活的codis-proxy