本文探讨了单节点Redis存在的问题，包括单点故障、数据容量和连接压力。针对数据容量问题，提出了基于客户端的分片方案，如业务拆分和Hash算法（包括Modula、Random和Ketama一致性Hash），以及通过Proxy实现数据路由。还介绍了Redis Cluster的特点和工作原理，强调了数据加标签以避免跨节点操作。最后，分享了相关面试题和Java核心知识点资源。
一、先谈单节点的 Redis 存在的问题
- 单点故障
- 数据容量问题
- 连接数、请求压力问题
主从+哨兵架构，解决了单点问题和请求压力问题，但是数据容量仍然是 1：1 的克隆数据，数据容量问题依旧存在，数据并没有分摊到各个节点。
二、如何解决单点数据容量问题
A：基于客户端的方案
1.业务拆分数据
从业务的角度不同的模块按约定好的逻辑落入不同的Redis 节点。
比如：评论业务用一个redis阶段，商品信息业务用另外一个节点，购物车用另外一个节点。
2.通过Hash算法路由
- 2.1 Modula：将hash(ID)%redis节点数
弊端：redis节点数改变的话，数据就分配规则就被打破了。
- 2.2 Random：随机分配
使用场景：消息队列。
数据随机的落入到不同的节点，对于客户端而言无所谓数据落在那一台节点，只需要知道key就能拿到数据。
- 2.3 Ketama：一致性Hash算法将数据分摊到不同的节点。
规划一个虚拟的环形节点，将节点和数据参与位置分配算法。
优点：增加节点可以分担其他节点的压力，不会造成全局洗牌，原本的数据还在最初规划出的物理节点中。
一致性Hash缺点:
- 击穿的风险，原本数据是在a节点的&
最低0.47元/天 解锁文章
2351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
