济南营销型网站建设哪家好,产品介绍网站模板,wordpress主题重命名,深圳福田区有哪些企业Redis集群方案使用建议#xff1a;
Redis cluster#xff1a;除非是1000个节点以上的超大规模集群#xff0c;优先考虑使用Redis clustercodis#xff1a;旧项目如果仍在使用codis#xff0c;可继续使用#xff0c;但也推荐迁移到Redis clustertwemproxy#xff1a;不建…Redis集群方案使用建议
Redis cluster除非是1000个节点以上的超大规模集群优先考虑使用Redis clustercodis旧项目如果仍在使用codis可继续使用但也推荐迁移到Redis clustertwemproxy不建议使用与codis同为proxy方案但不如codistwemproxy不能平滑地扩容客户端分片应当禁止使用因为扩容复杂如果2个服务同时读写其中一个修改了路由另一个不修改会有问题 其中客户端分片、Redis Cluster属于无中心化的集群方案Codis属于中心化的集群方案。
是否中心化是指客户端访问多个Redis节点时是直接访问还是通过一个中间层Proxy来进行操作直接访问的就属于无中心化的方案通过中间层Proxy访问的就属于中心化的方案它们有各自的优劣。 一、客户端分片 我们只需要部署多个Redis节点具体如何使用这些节点主要工作在客户端。
客户端通过固定的Hash算法针对不同的key计算对应的Hash值然后对不同的Redis节点进行读写。 客户端分片需要业务开发人员事先评估业务的请求量和数据量然后让DBA部署足够的节点交给开发人员使用即可。 1、优点
部署非常方便业务需要多少个节点DBA直接部署交付即可剩下的事情就需要业务开发人员根据节点数量来编写key的请求路由逻辑制定一个规则一般采用固定的Hash算法把不同的key写入到不同的节点上然后再根据这个规则进行数据读取。 2、缺点
是业务开发人员使用Redis的成本较高需要编写路由规则的代码来使用多个节点
如果事先对业务的数据量评估不准确后期的扩容和迁移成本非常高因为节点数量发生变更后Hash算法对应的节点也就不再是之前的节点了。 3、一致性哈希
所以后来又衍生出了一致性哈希算法就是为了解决当节点数量变更时尽量减少数据的迁移和性能问题。
这种客户端分片的方案一般用于业务数据量比较稳定后期不会有大幅度增长的业务场景下使用只需要前期评估好业务数据量即可。 二、Redis Cluster方式 Redis cluster是官方支持的Redis集群方案 去中心化架构不依赖外部存储每个节点都有槽位信息、以及一部分数据各节点之间使用gossip协议交互信息划分为16384个slot槽位每个key按照分片规则对key做crc16 % 16384得到slot id每个Redis节点存储了一部分槽位数据各个Redis节点共同分担16384个slot槽位客户端需遵守Redis cluster规范读写数据客户端连接集群时会得到一份集群的槽位配置信息客户端本地缓存了slot到node的映射关系以便直接定位到对应的Redis节点 1、用key计算出slot
通过本地缓存的slot到node映射关系某个slot范围映射到某个node用slot得出node请求对应的node节点如果key对应的槽位在Redis节点存储的各槽位中则查询结果如果key对应的槽位不在Redis节点存储的各槽位中即key所在的槽位不归该节点管理则返回moved 节点 提示客户端再次请求指定的节点并更新本地映射关系如果请求的key对应槽位正在迁移则返回ask 节点 提示客户端再次请求指定的节点主库读写从库用于高可用备份、一般不用来承担读请求主从同步通过指令流、环形数组来做增量同步通过RDB来做全量同步 2、优缺点 优点
官方支持的集群方案能使用最新feature性能好无多余网络开销无一致性问题读写请求都走主节点槽位更精细163842^14相比于codis的1024 缺点
如果是从旧版不支持集群的Redis升级而来需做较大改造把传统的Jedis client需替换成智能客户端来维护key到slot的映射关系如lettuce官方是最小使用原则没有易用的扩容、迁移工具需要寻找社区提供的易用界面或自行研发迁移过程中性能可能受影响有3次请求首次get得到ask返回、再次asking确认指定节点是否有槽位、最后get 3、请求转发
Redis Cluster没有采用中心化模式的Proxy方案而是把请求转发逻辑一部分放在客户端一部分放在了服务端它们之间互相配合完成请求的处理。 Redis Cluster没有了中间的Proxy代理层那么是如何进行请求的转发呢 Redis把请求转发的逻辑放在了Smart Client中要想使用Redis Cluster必须升级Client SDK这个SDK中内置了请求转发的逻辑所以业务开发人员同样不需要自己编写转发规则Redis Cluster采用16384个槽位进行路由规则的转发。 没有了Proxy层进行转发客户端可以直接操作对应的Redis节点这样就少了Proxy层转发的性能损耗。 Redis Cluster也提供了在线数据迁移、节点扩容缩容等功能内部还内置了哨兵完成故障自动恢复功能可见它是一个集成所有功能于一体的Cluster。因此它在部署时非常简单不需要部署过多的组件对于运维极其友好。
Redis Cluster在节点数据迁移、扩容缩容时对于客户端的请求处理也做了相应的处理。当客户端访问的数据正好在迁移过程中时服务端与客户端制定了一些协议来告知客户端去正确的节点上访问帮助客户端订正自己的路由规则。 三、Codis方案 codis是Go语言编写的Redis proxy集群方案 codis-proxy作为上层proxy负责路由请求至底层的Redis分片。client与proxy交互可以把proxy当作普通的Redis实例一样因为codis-proxy实现了Redis协议API保持一致。 Redis分片是一个codis-group包括了多个codis-server其中有1个主节点、n个从节点用来作读写分离主节点承担写请求从节点分摊读请求。各个分片的Redis实例是独立的互不感知。codis-server与普通Redis实例的区别是在Redis的基础上扩展实现了slot槽的功能用于扩容、数据迁移。 分片规则对key做crc32 % 1024强依赖zookeeper来存储节点槽位信息。codis-dashboard、codis-fe是集群运维工具。 1、优点
客户端无需感知背后细节跟Redis单实例无明显区别除部分命令不支持平滑扩容运维操作简单有易于使用的web界面 2、缺点
是在Redis官方未支持集群方案之前的可选方案目前已停止更新proxy会带来额外的网络开销请求链路多了一层读写分离可能出现不一致的问题也需要评估请求读写比需要额外维护zookeeper
