codis (分布式 hash 原理)二级分类 二级索引
2016-04-27 18:01
471 查看
原来redis分布式的问题是key是业务端决定的,无限大.
问题: 做不到动态配置一个 key 对应到redis上.
怎么实现呢?
答案:
算法一: 很巧妙的利用了二级分类和二级引用(二级索引) . 将变化的东西转变成不变的.
将所有的key 通过hash变成 1024(可配,初始化,不可变)个slot .
当然这个值可以很大,大的你可以不用担心. 这些元数据的从存储.但是对于数据重 hash 来说就不是那么难了.
这样就可以配置某个slot具体对应到redis实例上.
有效避免了数据出错之后的问题.
缺点: 如果有热点,很有可能还是导致某个 slot 过大.
算法二:
hash 完的值后排序. 把每个 slot 的范围存储在元服务器上(可以是字符串).
类似 mongodb
b) 配置服务器(Config Server)。它存储了所有Shard节点的配置信息,每个chunk的Shard key范围,chunk在各Shard的分布情况以及集群中所有DB和collection的Shard配置信息。
缺点: 只需要 hash 后从元数据数组里找到对应的 slot 即可. 只需消耗比较少的数据.
问题: 迁移的时候不能写. 一个slot迁移完,通知各个dbproxy之前不可服务?
如何实现.
mongodb 的 hash 分片也是用了这个原理. 分片分裂原理?
问题: 做不到动态配置一个 key 对应到redis上.
怎么实现呢?
答案:
算法一: 很巧妙的利用了二级分类和二级引用(二级索引) . 将变化的东西转变成不变的.
将所有的key 通过hash变成 1024(可配,初始化,不可变)个slot .
当然这个值可以很大,大的你可以不用担心. 这些元数据的从存储.但是对于数据重 hash 来说就不是那么难了.
这样就可以配置某个slot具体对应到redis实例上.
有效避免了数据出错之后的问题.
缺点: 如果有热点,很有可能还是导致某个 slot 过大.
算法二:
hash 完的值后排序. 把每个 slot 的范围存储在元服务器上(可以是字符串).
类似 mongodb
b) 配置服务器(Config Server)。它存储了所有Shard节点的配置信息,每个chunk的Shard key范围,chunk在各Shard的分布情况以及集群中所有DB和collection的Shard配置信息。
缺点: 只需要 hash 后从元数据数组里找到对应的 slot 即可. 只需消耗比较少的数据.
问题: 迁移的时候不能写. 一个slot迁移完,通知各个dbproxy之前不可服务?
如何实现.
mongodb 的 hash 分片也是用了这个原理. 分片分裂原理?
相关文章推荐
- 表空间使用率脚本
- Knockout.Validation
- Jmeter入门篇
- 浅谈大型Web系统架构
- 逻辑回归与线性回归
- emmet插件使用(Css)
- Undefined symbols for architecture arm64: (加入opencv框架时)
- Web监听器
- js刷新页面方法大全
- linux 下利用 crontab 备份mysql
- 【转载】<mvc:annotation-driven />注解意义
- 修改tomcat命令窗口的名字
- 使用Nginx绑定域名,代理GitLab
- git rebase简介(高级篇)
- Oracle PL/SQL
- Docker基础技术:AUFS
- AppCan_1_UI基础 常用的样式
- c++作业4
- 谈谈为什么要系统学习算法-开复的一篇文章
- 会话管理