Mycat 分片规则详解--一致性hash分片
- 实现方式:基于hash算法的分片中,算法内部是把记录分片到一种叫做"bucket"(hash桶)的内部算法结构中的,然后hash桶与实际的分片节点一一对应,从此实现了分片、路由的功能,在这种一般结构中,在需要增加分片数量来横向扩容时,由于分片节点和hash桶之间的一一对应,导致算法根据原先的hash桶个数的进行的路由失效,需要根据新的hash桶数目做数据的再平衡才能再次服务,而一致性hash算法是在内部创建了虚拟桶,并维护了虚拟桶和分片之间的关系,在横向扩展的时候可以通过调整虚拟桶和分片之间的关系来进行扩展,并且横向扩展是存在极限值,值等于"虚拟桶倍数×分片节点数"
- 优点:有效解决了分布式数据库的扩容问题
- 缺点:在横向扩展的时候,需要迁移部分数据;由于虚拟桶倍数与分片节点数都必须是正整数,而且要服从"虚拟桶倍数×分片节点数=设计极限",因此在横向扩容的过程中,增加分片节点并不是一台一台地加上去的,而是以一种因式分解的方式增加,因此有浪费物理计算力的可能性。
-
配置示例:
<tableRule name="sharding-by-murmur">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-murmur</algorithm>
</rule>
</tableRule>
<function name="sharding-by-murmur"
class="io.mycat.route.function.PartitionByMurmurHash">
<property name="seed">0</property>
<property name="count">1</property>
<property name="virtualBucketTimes">3</property>
<property name="bucketMapPath">/opt/mycat/bucketMap</property>
</function>
-
相关属性:
- seed:hash 种子值
- count:要分片的数据库节点数据
- virtualBucketTimes:每个实际数据库分片被映射的虚拟节点数量,默认值 160 倍
- bucketMapPath:用于测试时观察物理节点与虚拟节点的分布情况,如果设置了该值,则会将虚拟节点的 murmur hash 值与物理节点额映射按行输出到这个文件(不生效)
本文版权归作者 李雪(博客地址:https://www.cnblogs.wiki)所有,欢迎转载和商用,请在文章页面明显位置给出原文链接并保留此段声明,否则保留追究法律责任的权利,其他事项,可留言咨询。