ahuazhu commented on a change in pull request #1267: 采用java8 hashmap的散列算法
hashcode右移16位后与hashcode异或 散列效果更好
URL: https://github.com/apache/rocketmq/pull/1267#discussion_r294238618
##########
File path:
client/src/main/java/org/apache/rocketmq/client/producer/selector/SelectMessageQueueByHash.java
##########
@@ -25,12 +26,12 @@
@Override
public MessageQueue select(List<MessageQueue> mqs, Message msg, Object
arg) {
- int value = arg.hashCode();
- if (value < 0) {
- value = Math.abs(value);
- }
+ return mqs.get(indexForQueue(mqs.size(), arg));
+ }
- value = value % mqs.size();
- return mqs.get(value);
+ private int indexForQueue(int length, Object key) {
+ int h = (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
+ return h & (length - 1);
Review comment:
Yes, for many scenes, setting the queue number to power of 2 is a best
practice. But Rocketmq did not require the queue number of a topic MUST BE
power of 2 by appointment. I think is not a good choice to break the contract
here.
For the unbalance case you mentioned, my advice is to check if hotspot data
exist.
If you prefer to insist the queue number should be power of 2, adding a
predict check before invoking the Hash algorithm may be a good choice.
:-)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
