标签：hash Redis 扩展 key 数据 节点 客户端
还是有很多问题的，希望以后的自己能够作出解答。
纵向扩展
-
好处： 简单直接
-
坏处： 单机数据过大，fork时可能阻塞主线程过长，成本
横向扩展
需要解决的问题就是数据放在哪里如何分布，客户端怎么知道访问哪里
Redis提供了Redis Cluster方案 如下：
采用Hash槽处理集群与数据的映射关系，默认16384个，根据key用CRC16算法取模。
使用cluster create建立集群时需要指定这台节点关注的hash槽 （所有节点的hash槽之和必须等于16384）
hash槽分配结束后节点之间会同步hash槽信息。每个实例存储一份hash槽节点映射。
- 手动分配Hash槽
负责0～5460个槽
redis-cli -h 172.16.19.1 –p 6379 cluster addslots 0,5460
redis-cli -h 172.16.19.2 –p 6379 cluster addslots 5461,10922
redis-cli -h 172.16.19.3 –p 6379 cluster addslots 10923,16383
-
自动分配Hash槽
CLUSTER MEET <ip> <port>邀请ip:port节点组为集群，Redis会自动分配Hash槽 -
客户端如何知道一个Key在哪个节点？
- 客户端在与任意节点建立连接成功后，节点会把hash槽映射关系发给客户端
- 客户端计算key 的 crc16对 16384取模就可以得到key落在了哪一个实例节点
注意：当节点新增/删除时需要重新分配hash槽，故而数据也需要重新分配
（重新分配怎么做的？有哪些资源开销？分配期间服务是否不可用？）
3. 重新分配后客户端的hash槽映射关系还是旧的就会导致访问到了没有数据的实例。。
Redis Cluster 提供了一种重定向机制：数据可分为俩种：1. 已迁移到新实例 2. 数据还在迁移中。
针对1： 节点没有相应数据，返回（MOVED 槽 key所在节点地址）客户端就可以拿到MOVED去拉取数据了 （怎么发现的是在本库中查一遍还是带了槽过来？）
针对2: 部分数据迁移完成时拉取数据会返回ASK 槽 key所在节点地址消息，标识当前槽在这个节点上，但是槽正在迁移 （如果已经迁移到新的节点那为什么不用MOVED直接去新节点拉取数据，如果还没迁移到为什么不直接返回数据？？还要引入一个ASK操作）
ASK： 不会修改客户端缓存，也就是说下次访问这个槽还是这个节点。
MOVED： 会修改客户端缓存。
标签：hash,Redis,扩展,key,数据,节点,客户端 来源： https://www.cnblogs.com/ccame/p/15700365.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。