一 简介:今天咱们来进行测试
二分片规则 sharding-by-murmur
1 table 相关配置
<tableRule name="sharding-by-murmur">
<rule>
<columns>id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
2 function 相关配置
<function name="murmur" class="io.mycat.route.function.PartitionByMurmurHash">
<property name="seed">0</property>
<property name="count">2</property>
<property name="virtualBucketTimes">160</property><!-- 一个实际的数据库节点被映射为这么多虚拟节点，默认是160倍，也就是虚拟节点数是物理节点数的160倍 -->
<!-- <property name="weightMapFile">weightMapFile</property> 节点的权重，没有指定权重的节点默认是1。以properties文件的格式填写，以从0开始到count-1的整数值也就是节点索引为key，以节点权重值为值。所有权重值必须是正整数，否则以1代替 -->
<!-- <property name="bucketMapPath">/etc/mycat/bucketMapPath</property> 用于测试时观察各物理节点与虚拟节点的分布情况，如果指定了这个属性，会把虚拟节点的murmur hash值与物理节点的映射按行输出到这个文件，没有默认值，如果不指定，就不会输出任 何东西 -->
</function>3 属性解析 函数特性设置节点数量
4 个人理解
一致性 hash 预算有效解决了分布式数据的扩容问题(官方文档描述)
1 hash值的生成
哈希算法将任意长度的二进制值映射为固定长度的较小二进制值(经过具体的算法函数)，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式
2 一致性 hash计算方式
1 首先求出memcached服务器（节点）的哈希值，并将其配置到0～2^32的圆（continuum）上。
2 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
3 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2^32仍然找不到服务器，就会保存到第一台memcached服务器上。
根据这里可以看出 hash预先了这么多节点,足够扩展了
3 一致性 hash计算的特点
1 一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。
2 即使很少的服务节点也能做到相对均匀的数据分布(虚拟节点)。
4 举个例子
1 整个空间按顺时针方向组织。0和232-1在零点中方向重合。
2 下一步将各个服务器使用Hash进行一个哈希，具体可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，这里假设将上文中四台服务器使用ip地址哈希后在环空间的位置如下：
3 接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。
4 根据一致性哈希算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。假如 NODEC C down掉 C上的数据会被重定位到Node D,影响只是逆时针方向的第一台
5 测试
1 配置相关测试表
<table name="user" primaryKey="id" dataNode="db1,db2" rule="sharding-by-murmur" />
虚拟节点采用默认就好
2 建立相关表
3 relod @@config;
4 进行测试
