我必须使用 x86 32 位 murmurhash 来确定我在 Kafka 中发送消息的分区。另一个应用程序使用 NodeJS murmurhash.v3() 方法从预期分区获取消息。
我尝试了两种方法:
这是我用来从 Apache java 方法获取值的代码:
int ret = MurmurHash3.MurmurHashV3(key, new Long(KAFKA_PARTITION_SEED).intValue());
注意:目前,KAFKA_PARTITION_SEED = 100 但这只是一个测试值。将来它会是一个 Long 值。
这是我完成的代码,从 NodeJS 转换为 Java :
static int MurmurHashV3(String key, int seed) {
int remainder;
int bytes;
int h1;
int h1b;
int c1;
int c2;
int k1;
int i;
remainder = key.length() & 3; // key.length % 4
bytes = key.length() - remainder;
h1 = seed;
c1 = 0xcc9e2d51;
c2 = 0x1b873593;
i = 0;
while (i < bytes) {
k1 = ((key.charAt(i) & 0xff)) | ((key.charAt(++i) & 0xff) << 8)
| ((key.charAt(++i) & 0xff) << 16)
| ((key.charAt(++i) & 0xff) << 24);
++i;
k1 = ((((k1 & 0xffff) * c1) + ((((k1 >>> 16) * c1) & 0xffff) << 16))) & 0xffffffff;
k1 = (k1 << 15) | (k1 >>> 17);
k1 = ((((k1 & 0xffff) * c2) + ((((k1 >>> 16) * c2) & 0xffff) << 16))) & 0xffffffff;
h1 ^= k1;
h1 = (h1 << 13) | (h1 >>> 19);
h1b = ((((h1 & 0xffff) * 5) + ((((h1 >>> 16) * 5) & 0xffff) << 16))) & 0xffffffff;
h1 = (((h1b & 0xffff) + 0x6b64) + ((((h1b >>> 16) + 0xe654) & 0xffff) << 16));
}
k1 = 0;
switch (remainder) {
case 3:
k1 ^= (key.charAt(i + 2) & 0xff) << 16;
case 2:
k1 ^= (key.charAt(i + 1) & 0xff) << 8;
case 1:
k1 ^= (key.charAt(i) & 0xff);
k1 = (((k1 & 0xffff) * c1) + ((((k1 >>> 16) * c1) & 0xffff) << 16)) & 0xffffffff;
k1 = (k1 << 15) | (k1 >>> 17);
k1 = (((k1 & 0xffff) * c2) + ((((k1 >>> 16) * c2) & 0xffff) << 16)) & 0xffffffff;
h1 ^= k1;
}
h1 ^= key.length();
h1 ^= h1 >>> 16;
h1 = (((h1 & 0xffff) * 0x85ebca6b) + ((((h1 >>> 16) * 0x85ebca6b) & 0xffff) << 16)) & 0xffffffff;
h1 ^= h1 >>> 13;
h1 = ((((h1 & 0xffff) * 0xc2b2ae35) + ((((h1 >>> 16) * 0xc2b2ae35) & 0xffff) << 16))) & 0xffffffff;
h1 ^= h1 >>> 16;
return h1 >>> 0;
}
在这两种情况下,我在尝试获取分区值时都会得到相同的结果。分区值(下表中的 P)是 murmurhash 方法返回值的模 8 (%8)。
这是我得到的结果示例:
key | NodeJS | P | Apache | P | N 到 A | P |相同的
0009B5192951 | 1285784451 | 3 | 1285784451 | 3 | 1285784451 | 3 |真的
0009B5192953 | 2252321193 | 1 | -2042646103 | -7 | -2042646103 | -7 |错误的
0009B5192979 | 973658619 | 3 | 973658619 | 3 | 973658619 | 3 |真的
0009B5192985 | 1359432313 | 1 | 1359432313 | 1 | 1359432313 | 1 |真的
0009B5192987 | 3551230334 | 6 | -743736962 | -2 | -743736962 | -2 |错误的
0009B5192995 | 199863683 | 3 | 199863683 | 3 | 199863683 | 3 |真的
0009B5193001 | 1660947343 | 7 | 1660947343 | 7 | 1660947343 | 7 |真的
0009B5193007 | 1980598253 | 5 | 1980598253 | 5 | 1980598253 | 5 |真的
0009B5203789 | 1358113422 | 6 | 1358113422 | 6 | 1358113422 | 6 |真的
0009B5203791 | 1339226023 | 7 | 1339226023 | 7 | 1339226023 | 7 |真的
如您所见,在某些情况下,Apache murmurhash 方法会返回负值,这不是预期的(我猜)。
谁能告诉我我做错了什么?
最佳答案
有一段时间我在使用 MurmurHash2 时遇到了同样的问题,但事实证明,由于 Java 处理签名的方式,Apache 实现存在漏洞。我建议使用 this反而。
关于node.js - 使用 Apache MurmurHash3.java x86 32 位方法具有负值,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22956872/