codis

git clone https://github.com/CodisLabs/codis.git 1:下载go环境 官网：https://golang.org/doc/install wget https://storage.googleapis.com/golang/go1.6.2.linux-amd64.tar.gz tar -C /usr/local -xzf go1.6.2.linux-amd64.tar.gz cd /usr/local/go cat >> /etc/profile <<EOF export GOROOT=/usr/local/go export GOPATH=/workspace/golang export PATH=\$PATH:\$GOROOT/bin:\$GOPATH/bin export CODIS_HOME=$GOPATH/src/github.com/CodisLabs/codis export GO15VENDOREXPERIMENT=0 EOF source /etc/profile 2:下载安装codis 官网：https://github.com/CodisLabs/codis/blob/master/doc/tutorial_zh.md 根据官网推荐采用这种方式，而不是git clone ...codis go get -u -d

分布式缓存集群方案特性使用场景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）优缺点对比及选型 分布式缓存特性： 1) 高性能:当传统数据库面临大规模数据访问时,磁盘I/O 往往成为性能瓶颈,从而导致过高的响应延迟.分布式缓存将高速内存作为数据对象的存储介质,数据以key/value 形式存储,理想情况下可以获得DRAM 级的读写性能; 2) 动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率; 3) 高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用; 4) 易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护; 5) 分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.最新的Java 数据网格规范JSR

Redis Redis-优势总结 1 性能高,读每秒是11w,写每秒是8w 2 丰富的数据结构,支持string,list,set,hash,sortedset 3 原子性操作,要不全部成功,要不全部失败 4 发布与订阅,完成类似队列功能 5 分布式锁的内在支持 6 高可用,高性能,支持集群,支持哨兵,支持读写分离 Redis-使用场景 数据缓存（商品数据、新闻、热点数据） 单点登录 秒杀、抢购 网站访问排名,排行榜 应用的模块开发 Redis-RESP协议 Redis 的客户端和服务端之间采取了一种独立名为 RESP(REdis Serialization Protocol) 的协议,它的特点是容易实现和解析快,可读性强 在 RESP 中, 一些数据的类型通过它的第一个字节进行判断： 单行回复：回复的第一个字节是 “+” 错误信息：回复的第一个字节是 “-” 整形数字：回复的第一个字节是 “:” 多行字符串：回复的第一个字节是 “$” 数组：回复的第一个字节是 “*” 举例 比如使用set命令, SET simpleKey simpleValue, 3 代表有三个字符串 9 代表有九个字符串 11 代表有十一个字符串 \\r\\n代表空格和换行 *3\\r\\n$3\\r\\nSET\\r\\n$9\\r\\nsimpleKey\\r\\n$11\\r\\nsimpleValue

Codis就是一个Redis代理中间件，其对外协议与Redis协议保持一致，当客户端向Codis发送指令时，Codis负责将指令转发到后面的Redis实例来执行并将返回结果再转回给客户端。 Codis挂接的所有Redis实例构成一个Redis集群，当集群空间不足时，可以通过动态增加Redis实例来实现扩容需求。 问题1：Codis是如何分发客户端请求的呢？？？ 答： 第一步：Codis将所有的key默认划分为1024个槽位(slot)，它首先对客户端传过来的key进行crc32运算计算哈希值，再将 hash后的整数值对1024这个整数进行取模得到一个余数，这个余数就是对应key的槽位。（槽位数量默认是1024，它是可以配置的） 第二步：每个槽位都会唯一映射到后面的唯一一个Redis实例。 问题2：由于Codis也可以组成集群，那如何把集群中某个Coids槽位与key映射关系同步到其他Codis中呢？ 答：这里Codis必须使用一个分布式数据库来实现这个目标，比如：ZooKeeper、etcd等。 问题3：还有个问题就是，假如1024个槽位映射到N个Redis实例，假如现在变成了（N+M）个Redis实例，那1024个槽位映射关系该怎么重写？ 答：通过Codis的SLOTSSCAN指令来扫描1024个槽位所对应的key，然后筛选出符合条件的key

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、引言 Codis是一个分布式 Redis 解决方案，可以管理数量巨大的Redis节点。个推作为专业的第三方推送服务商，多年来专注于为开发者提供高效稳定的消息推送服务。每天通过个推平台下发的消息数量可达百亿级别。基于个推推送业务对数据量、并发量以及速度的要求非常高，实践发现，单个Redis节点性能容易出现瓶颈，综合考虑各方面因素后，我们选择了Codis来更好地管理和使用Redis。 二、选择Codis的原因 随着公司业务规模的快速增长，我们对数据量的存储需求也越来越大，实践表明，在单个Redis的节点实例下，高并发、海量的存储数据很容易使内存出现暴涨。 此外，每一个Redis的节点，其内存也是受限的，主要有以下两个原因： 一是内存过大，在进行数据同步时，全量同步的方式会导致时间过长，从而增加同步失败的风险； 二是越来越多的redis节点将导致后期巨大的维护成本。 因此，我们对Twemproxy、Codis和Redis Cluster 三种主流redis节点管理的解决方案进行了深入调研。 推特开源的Twemproxy最大的缺点是无法平滑的扩缩容。而Redis Cluster要求客户端必须支持cluster协议，使用Redis Cluster需要升级客户端，这对很多存量业务是很大的成本。此外，Redis

什么是redis？ Redis是一种可基于内存亦可持久化的日志型、Key-Value数据库，支持的存储类型非常丰富，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。（具体介绍请参照百度百科） 为什么快？  纯ANSI C编写。  所有数据均存放在内存中，当然不包括持久化。  不依赖第三方类库，没有像memcached那样使用libevent。  Redis多样的数据结构，每种结构只做自己爱做的事，当然比数据库只有Table，MongogoDB只有JSON一种结构快了。 Redis支持的功能：  所有数据都在内存中。  五种数据结构：String / Hash / List / Set / Ordered Set。  数据过期时间支持。  不完全的事务支持。  服务端脚本：使用Lua Script编写，作用类似存储过程。  PubSub：捞过界的消息一对多发布订阅功能，起码Redis-Sentinel在使用它。  持久化：支持定期导出内存的RDB与 记录写操作日志的Append Only File两种模式。  Replication：Master-Slave模式，Master可连接多个只读Slave。  Fail-Over：Redis

测试环境和命令： 阿里云VPC环境， 4 x （1核， 2G ECS) 用于运行codis proxy codis proxy后端slot均衡的接2个或4个阿里云redis实例 内网SLB连接4个codis proxy 只单纯测试单条读写， 命令如下： ./redis-benchmark -a <auth-passwd> -h <slb-addr> -c 64 -n 500000 -P 100 -r 1048576 -d 256 -t get,set 测试结果： Spec. ValueSize(byte) ops(SET) ops(GET) 直连1G redis 256 6.5w 4w codis接2x1G redis 256 12w 8w codis接4x1G redis 256 26w 16w codis接4x1G redis 1024 8w 4w codis接4x1G redis 2048 4w 2w codis接2x2G redis 256 15w 12w 直连8G redis 1024 9w 80w 直连8G redis 2048 4.7w 80w 测试结论： aliyun的低配redis服务器(1G, 2G)， 写入性能明显优于读取性能， 猜测读性能应该是aliyun做的流量限制 aliyun的8G redis比较特殊， 读性能大大提升(80w)，

　　在大数据高并发场景下，单个 Redis 实例往往会显得捉襟见肘。首先体现在内存上，单个 Redis 的内存不宜过大，内存太大会导致 rdb 文件过大，进一步导致主从同步时全量同步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实例内存往往都是受限的。其次体现在 CPU 的利用率上，单个 Redis 实例只能利用单个核心，这单个核心要完成海量数据的存取和管理工作压力会非常大。正是在这样的大数据高并发的需求之下，Redis 集群方案应运而生。它可以将众多小内存的 Redis 实例综合起来，将分布在多台机器上的众多 CPU 核心的计算能力聚集到一起，完成海量数据存储和高并发读写操作。Codis 是 Redis 集群方案之一，令我们感到骄傲的是，它是中国人开发并开源的，来自前豌豆荚中间件团队。绝大多数国内的开源项目都不怎么靠谱，但是 Codis 非常靠谱。有了Codis 技术积累之后，项目「突头人」刘奇又开发出来中国人自己的开源分布式数据库 ——TiDB，可以说 6 到飞起。👍从 Redis 的广泛流行到 RedisCluster 的广泛使用之间相隔了好多年，Codis 就是在这样 的市场空缺的机遇下发展出来的。大型公司有明确的 Redis 在线扩容需求，但是市面上没有 特别好的中间件可以做到这一点。 　　Codis 使用 Go 语言开发，它是一个代理中间件

背景 关于Redis的高可用除了只身的 Sentinel 和 Cluster 之外，还有一个用的比较多的是 Codis ，由于公司的Redis大部分都使用Codis，本文就针对Codis进行相关的安装部署进行说明，来好好的学习Codis。 介绍 Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 ( 不支持的命令列表 ), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。与 Twemproxy 和 Redis Cluster 对比： Codis Twemproxy Redis Cluster resharding without restarting cluster Yes No Yes pipeline Yes Yes No hash tags for multi-key operations Yes Yes Yes multi-key operations while resharding Yes - No( details ) Redis clients supporting Any

摘要： 本文对redis4.0版本的cluster，codis，以及阿里云redis 3种集群进行了对比分析。 1、架构对比 1.1、redis 4.0 cluster redis 4.0版本的集群是去中心化的结构，集群元数据信息分布在每个节点上，主备切换依赖于多个节点协商选主。 redis 提供了redis-trib 工具做部署集群及运维等操作。 客户端访问散列的db节点需依赖smart client，也就是客户端需要对redis返回的节点信息做判断选择路由等操作。例如客户端请求一个节点，如果所请求的key不在该节点上，客户端需要判断返回的move或ask等指令，重定向请求到对应的节点。 1.2、codis codis由3大组件构成： codis-server : 修改过源码的redis, 支持slot，扩容迁移等 codis-proxy : 支持多线程，go语言实现的内核 codis Dashboard : 集群管理工具 提供web图形界面管理集群。 集群元数据存在在zookeeper或etcd。 提供独立的组件codis-ha负责redis节点主备切换。 基于proxy的codis，客户端对路由表变化无感知。客户端需要从codis dashhoard调用list proxy命令获取所有proxy列表，并根据自身的轮询策略决定访问哪个proxy节点以实现负载均衡。 1.3