1.1 高可用 - Sentinel

1.2 提升资源限制瓶颈 - 数据分区存储(Partitioning)

1.3 提高网络吞吐
二、客户端分区
存取规则需要统一,需要考虑扩缩容时业务逻辑调整的影响面
业务其实并不清楚 Redis 节点机器的瓶颈
每个客户端都需要连接所有的 Redis 节点
三、代理分区

3.1 Modula [ 根据算法 + 取模存取 ]
通过算法对key进行取模,决定最终需要在哪个节点上进行存取。
缺点:可能会出现数据分布节点不均匀的情况,机器扩缩容时需要调整取模策略
缺点:可能会出现数据分布节点不均匀的情况
3.3 Ketama [ 一致性哈希 ]
一致性哈希解决了简单哈希算法在分布式哈希表中存在的动态伸缩等问题。
优点:增加节点可以分担其他节点存储压力,因为没有取模过程不会影响其他节点的存储策略
缺点:新增节点会造成一小部分数据不能命中(此时应再取附近的2个节点查看数据是否存在)
规划一个哈希环,环上node hash后的槽位为物理节点,其余为虚拟节点
将所有物理节点标记起来
数据(key)加进来时通过hash过后查询该槽位是否为物理节点,如果是虚拟节点,则找寻离它最近的物理节点后存入
四、Redis Cluster(无中心架构)
优点:扩缩容方便,Redis自带了工具与脚本对于Redis cluster架构也有很好的支持
缺点:客户端连接直接压在了实例自身(可以在上层增加 proxy),删除重定向也会造成过多的请求转发与处理流程


五、其他
当使用 Redis cluster 架构时候:
涉及多个 key 的操作通常不会被支持。例如不能对两个集合求交集,因为他们可能被存储到不同的 Redis 实例(KEYS *、WATCH、MULTI...) 同时操作多个 key ,则不能使用 Redis 事务
本文关键字:#Redis集群# #Redis分区#
文章推荐:
技术分享 | TiUP工具 - TiDB集群滚动升级核心流程解析
故障分析 | OceanBase Proxy 无法连接 OBserver 集群
技术分享 | Xtrabackup 不备份 binlog 怎么保证一致性?
转文至此。
以下是个人微信公众号,欢迎关注:

文章转载自戏说数据那点事,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




