codis和redis区别（redis和caffeine）

本篇文章给大家谈谈codis和redis区别，以及redis和caffeine对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、redis架构模式（6）数据倾斜
• 2、predixy一款高性能全功能redis代理
• 3、redis架构模式（4） Codis
• 4、细说分布式redis

redis架构模式（6）数据倾斜

数据倾斜通常分为两种情况，一是各实例上面的数据不均匀，个别实例数据量特别多；

二是某个实例上的热点数据多，导致的访问量倾斜。发生了数据倾斜，那么保存了大量

数据或者是保存了热点数据的实例的处理压力就会增大，速度变慢，甚至还可能会引起

这个实例的内存资源耗尽导致宕机风险。

如果某个实例上保存了bigkey，会导致这个实例的数据量及相应的内存资源消耗增加，

bigkey的操作容易导致主线程IO的阻塞，bigkey最好能够从业务层面避免掉，正轿如果是

集合类型的bigkey，建议拆分成多个集合多实例保存，再根据业务逻辑做相应的映射。

solt分配不均，就根据具体的使用的中间件查看slot分布情况进而做具体slot迁移

hashtag指的是对key的部分用{}圈起来，例如dramaId:episode:1232变成

dramaId:episode:{1232},在计算 key 的 CRC16 值时，只对HashTag花括号中的 

key内容进行计算,这有什么用处呢？就是key不一样但是hashtag内容一样的key

会被分配到同一个slot，它主要是用在 Redis Cluster 和 Codis中，支持事务操作

和范围查询。因为 Redis Cluster 和 Codis 本身并不支持跨实例的事务操作和

范围查询，当业务应用有这些需求时，就只能先把这些数据读取到业务层进行事务

处理，或者是逐个查询每个实例，得到范围查询的结果，所以我们可以使用 Hash Tag 

把要执行事务操作或是范围查询的数据映射到同一个实例上，这样就能很轻松实现

事务或范围查询，潜在的风险就是会导致大量的数据被分配到同一实例，导致数据

倾斜和集群负载不均衡，所以迅亮在hashtag和业务上的事务范围查询，得我们自己做

取舍，建议还是避免hashtag

在某个实例上的商品或者某些影视剧集突然火了，那么就导致这个实例的访问量突增，

好在热点数据通常只是读，所以我们可以采用热点数据多副本的方式应对，我们把热点

数据复制多份，然后把key加个前缀，使其分布在不同的slot，查询的时候做好相应逻举昌肆辑，

那么即可把热点数据的压力分摊到多实例上

[img]

predixy一款高性能全功能redis代理

redis作为一款优秀的NoSQL代表软件，正变得越来越流行，虽然Redis很容易就可以启动并使用，但是要想在线上用好它却也并非易事。redis的高可用和可扩展无论是自带的Redis Sentinel还是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，实际上客户端来做这些事情也并不合适，它会让维护变得特别困难。因此在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，可以完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy之前，已经有几款流行的redis代理，它们各具特色。接下来，我们就来比较以下代理：

简单来说，predixy既支持Redis Sentinel也支持Redis Cluster

作为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来我们就来做个简单的评测，测试平台及各代理具体的版本信息如下：

redis-server、各代理、redis-benchmark均在这一台机器上运搏肢行。

redis部署：

以下测试的结果中，横坐标为数据大小、纵坐标为qps或者毫秒。

这里单线程是指四款代理都运行在绝敏单线程下（下同），redis-benchmark默认并发50个客户端连接，每个连接每次发送一个命令收到响应后再发下一个命令。这是很多线上实际的场景。

在吞吐上，四款代理的性能排列的整齐有序，predixy大幅领先于另外三款代理，而twemproxy又以较大优势领先另外两个，剩下的两个codis在数据量小于512的时候稍稍领先cerberus，而当数据量大于512的时候，codis对cerberus的领先越来越大。整体上在数据量达到16KB时，由于redis-benchmark本身成为瓶颈，predixy和twemproxy的SET成绩差不多了。

在延时上，codis由于语言的问题，一直都大于另外三款代理，后续测试也一样。

在有些场景下，客户端可能在处理一个请求时可能需要发起多次redis请求，这时如果把多个redis请求pipeline一起请求的话，会大幅改善性能。本轮测试就来看看当客户端一次发送多个请求时我们各代理表现如何？Redis-benchmark依旧是并发50个连接，但是一次发送20个命令。

在吞吐上，redis-benchmark一次pipeline 20个命令后，各代理的吞吐量全都猛增。predixy更是一骑绝尘，遥遥领先另外三个，而最后看到在GET 4K数量据的时候predixy表现和其它代理差不多是因为对predixy来说，当数据量大于2K时redis-benchmark自身已经成为瓶颈。另外三款代理，在上轮测试中落后的cerberus在本轮测试一开始表现远好过twemproxy和codis，但cerberus还是存在随着数据量变大性能迅速降低的问题。twemproxy和codis在本轮测试中表现基本相当。

在时延上，codis固有的问题表现较差，另外三款在数据量较小时差别较小，而当数据量超过512时，predixy则表现出较明显的优势。

测完了单线程，现在我们开始多线程测试，由于twemproxy不支持多线程，因此twemproxy不参与多线程的测试。考虑到redis-benchmark本身是个单线程程序，在多线基宏世程代理下如果我们再测单个命令的性能，那redis-benchmark很可能就是瓶颈，则无法更明确的看出各代理的性能差异，因此我们直接测试pipeline，还跟上轮一样，50个并发连接，一次发送20个命令。

总体趋势和第二轮单线程pipeline测试一致，predixy在本轮测试中依旧取得了领先，不过在开始阶段cerberus和predixy遥遥领先于codis，cerberus和predixy差距不大。但是随着数据量的变大，cerberus再次显示出了性能急剧降低的问题，到1K以后甚至就比codis差了。

在功能的对比上，predixy相比另外三款代理更为全面，基本可以完全适用原生redis的使用场景。在性能上，predixy在各轮测试中都以较大优势领先。对各代理的总结如下：

redis架构模式（4） Codis

codis是在redis官方集群方案redis-cluster发布之前便已被业界广泛使用的redis集群解决方案。

codis server ：这是进行了二次开发的 Redis 实例，其中增加了额外的数据结构，支持

数据迁移操作，主要负责处理具体的数据读写请求。

codis proxy ：接收客户端请求，并把请求转发给 codis server。

Zookeeper 集群 ：保存集群元数据，例如数据位置信息和 codis proxy 信息。

codis dashboard 和 codis fe ：共同组成了集群管理工具。其中，codis dashboard 负

责执行集群管理工作，包括增删 codis server、codis proxy 和进行数据迁移。

而 codis fe 负责提供dashboard的Web 操作界面，便于我们直接在 Web 界面上进行集群管理

codis proxy本身支持 Redis 的 RESP 交互协议，所以只需和proxy建立连接，就相当于和

整个codis集群建立连接，codis proxy 接收到请求，就会查询请求数据和 codis server 的

映射关系，并把请求转发给相应的 codis server 进行处理。当 codis server 处理完请求后，

会把结果返回给codis proxy，proxy 再把数据返回给客户端。

codis集群喊模兆共有1024个slot，编号从0-1023，可以自定义或者自动均匀分配到各个server上，

使用 CRC32 算法计算数据 key 的哈希值然后对1024取模，得到slot编号，然后通过slot

和server的映射关系请求到具体实例。

Slot 和 codis server 的映射关系称为数据路由表，我们在 codis dashboard 上分配好路由表后，

dashboard 会把路由表发送给 codis proxy，同时，dashboard 也会把路由表保存在

 Zookeeper 中。codis-proxy 会把路由表缓存在本地，当它接收到客户端请求后，直接查询

本地的路由表进而完成请求的转发。

跟redis cluster的区别是，codis的把映射关系存在zookeeper和proxy中，redis cluster

是通过各个实例相互通信进而存在各个实例本地，当实例较多时，可能会受到网络状况

影响而且整个集群的网络资源消耗相较之下也比较大。

codis按照slot粒度进行数据迁移，比如从serverA迁移至serverB，会从A要迁移的slot中

随机选择一个数据，发送给B，A得到确认消息后，删除本地数据。重复这个过程直到

迁移完毕。

迁移方式有两种，一种是同步迁移，一种是异步迁移。

同郑租步迁移时，源server是阻塞的，由于迁移过程中需要码型数据的序列化、网络传输、删除

等等操作，如果是bigkey则会阻塞较长时间。

所以通常采用异步迁移。异步迁移模式下，源server发送完迁移数据之后，就可以继续接受

处理请求，等到目标server返回ack之后，再执行删除操作，这个过程中，为了防止数据

不一致的情况，被迁移的数据是只读模式。

对于bigkey的数据，异步迁移采用拆分指令的方式，对bigkey中的每个元素用一条指令

进行迁移，而不是等待整个数据序列化完毕再迁移，进而避免了需要序列化大量数据而

阻塞的风险，因为整个bigkey的数据是被拆分的，如果迁移期间server宕机，便会破坏

迁移的原子性，所以codis对bigkey的数据设置了一个过期时间，如果原子性遭到破坏，

目标server的数据就会过期后删除以保证迁移的原子性。可以通过异步迁移命令 

SLOTSMGRTTAGSLOT-ASYNC 的参数numkeys 设置每次迁移的 key 数量，以提升

bigkey异步迁移的速度。

最后分享一下我的一些架构设计心得，通过redis cluster和codis的slot设计，把原本

数百上千万的key和实例的映射抽象成slot和实例的映射，大大减少了映射量，进而把

slot和key的映射分担到各个实例中，这种粒度的抽象，值得借鉴，另外codis与redis cluser

不同的是，codis通过zk作为第三方储存系统，保存了集群实例、状态和slot分配等信息，

这样避免了实例间的大量心跳来同步集群状态进而减少实例间的网络通信量，对于实现

大规模的集群是有益的设计，网络带宽可以集中在客户端请求上面，需要注意的是需要保证

zk的通信带宽，毕竟集群的信息同步都交给了zk

细说分布式redis

IT培训数据库教程

细说分布式Redis架构设计和踩过的那些坑

作者:课课家教育2015-12-14 10:15:25

摘要：本文章主要分成五个步骤内容讲解

Redis、RedisCluster和Codis;

我们更爱一搜散御致性;

Codis在生产环境中的使用的经验和坑们;

掘禅对于分布式数据库和分布式架构的一些看法;

Q A环节。

Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正。

细说分布式Redis架构设计和踩过的那些坑_redis 分布式_ redis 分布式锁_分布式缓存redis

一、 Redis，RedisCluster和Codis

世岩Redis：想必大家的架构中，Redis已经是一个必不可少的部件，丰富的数据结构和超高的性能以及简单的协议，让Redis能够很好的作为数据库的上游缓存层。但是我们会比较担心Redis的单点问题，单点Redis容量大小总受限于内存，在业务对性能要求比较高的情况下，理想情况下我们希望所有的数据都能在内存里面，不要打到数据库上，所以很自然的就会寻求其他方案。 比如，SSD将内存换成了磁盘，以换取更大的容量。更自然的想法是将Redis变成一个可以水平扩展的分布式缓存服务，在Codis之前，业界只有Twemproxy，但是Twemproxy本身是一个静态的分布式Redis方案，进行扩容/缩容时候对运维要求非常高，而且很难做到平滑的扩缩容。Codis的目标其实就是尽量兼容Twemproxy的基础上，加上数据迁移的功能以实现扩容和缩容，最终替换Twemproxy。从豌豆荚最后上线的结果来看，最后完全替换了Twem，大概2T左右的内存集群。

Redis Cluster ：与Codis同期发布正式版的官方cl

关于codis和redis区别和redis和caffeine的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。