• 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

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.

Why

PHP <= 7.1 and PHPUnit <= 7 are no longer supported.

What to change

• Update Roadmap.
• Use PHPUnit 8 instead of PHPUnit 4.
• PHP 7.2 minimum.
• Enable strict typing mode for all PHP files.

This change is breaking that it's better to release the major version as 3.0.0.

Ref.

https://www.php.net/supported-versions.php

https://phpunit.de/supported-versions.html

• PSR-0 autoloading via Composer.
• Unit tests converted to PHPUnit and benchmark test excluded in phpunit.xml.dist
• Travis CI support.
• Coveralls support.
• PHP Code sniffer phpcs.xml added to ignore class naming until v2.0.0 hits.

I will add a CHANGELOG.md before merging.

switched simple test to relase 1.1.0, changed addTargets function to accept key value array so that now define weight of each individual server, fixed the tests

1 commit in this pull request. I simply updated the repo location for simpletest from /cbosuna/ to /lox/, where there is actually a public repo.

The prevents git from choking on a submodule update, etc.

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?

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 :)

https://github.com/shish/python-flexihash/commit/37f56794903c626726be421cbf2964178866ab91