Crufty SPL autoloader initialization in init.php should be replaced with PSR-4 Autoloader.

I guess this also implies namespacing the classes.

Here is a fun bug.

In a simulation/test we had 10 nodes added like this:

$hasher->addTargets(['node1:port1', ... 'node10:port10']);

We also set num replicas to 100 but you can reproduce with 64.

Then we tested that 1000 keys looked up a roughly evenly distributed (pass), and that if we remove a node (node4:port4 in our case) they remain even which works fine. We also test that each node retains all of the keys it had originally after one node is removed (as well as something close to 1/N-1 of the 1/N keys the failed host had in the original ring).

This part fails - somehow removing a node (or strictly building same ring without node4 but they should be equivalent), makes some small percentage of keys move which node they are on even if they weren't on the failed node.

After some debugging, I think I can explain this.

When using MD5Hasher you chose to keep hex strings at the ring positions rather than converting back to ints. That in itself is not necessarily wrong, however it falls into a PHP dynamic typing gotcha: the internal positionToTarget lookup ends up looking like this (after sorting):

...
  'ff4a2aff' => 'host7:port7',
  'ff6c8fa3' => 'host5:port5',
  'ff820a72' => 'host5:port5',
  'ffc8b06f' => 'host6:port6',
  'fff31063' => 'host10:port10',
  11023620 => 'host4:port4',
  13715227 => 'host7:port7',
  13952778 => 'host4:port4',
  16385505 => 'host6:port6',
  17878142 => 'host2:port2',
...

i.e. using an all-decimal-digit string as an array key in PHP causes PHP to convert it to an int key which then sorts after all string keys not in natural hex-digit order. Keys that are in these ring segments then move unpredictably between ring reconfigurations because the algorithm is no longer correct and comparisons are not working as expected.

Switching to CRC32Hasher with identical params fixes the issue because those are always integer keys.

2 possible fixes:

1. You //could// do some magic in Flexihash to make this work correctly - it's not really MD5Hasher's fault PHP does funny things with "int-like" strings. For example you could prefix string keys in the array so they look like _ffaabb33, the leading underscore would stop PHP mangling to an int and would keep sort order correct. You'd obviously need to also prepend the hashed key with _ at lookup time etc.
2. Alternatively, you could decide that HasherInterface requires returned values to be ints and no larger than PHP_INT_MAX and fix MD5Hasher to meet this - just need hexdec() around the return statement.

Please let us know which you'd prefer both are simple changes.

Hi, you must include classes before initialize it, becouse users without autoloader couldn't use you great flexihash!

I just got a 20x speedup in my python translation of this code by doing a binary search instead of "iterate over the whole sorted targets list one at a time until we find our first valid target", I suspect that the PHP version could see benefits too :)

shish/flexihash-py@37f5679

Can it be used with Redis for client-side sharding? Has this library some performance impact?

Flexihash tests use SimpleTest, which is abandoned. Porting to PHPUnit shouldn't be terribly hard.

It would be great (and appreciated) if you could create a composer package for this library. Thank you!

• Current version, which has barely been touched for seven years, should be tagged as v1.0.0.
• CHANGELOG.md should be created.
• Future versioning should follow SemVer
  • Changing autoloaders, namespacing etc should be a major release e.g. v2.0.0

This isn't an issue with the library, just a question about how consistent hashing works with weights. If I change the weight of a target by some small amount, let's say out of 10 targets each with a weight of 1, I change the weight of one target to 3. How significantly will the keys be redistributed?