Question

我有一个带有2个分片的kinesis流，如下所示：

{
    "StreamDescription": {
        "StreamStatus": "ACTIVE",
        "StreamName": "my-stream",
        "Shards": [
            {
                "ShardId": "shardId-000000000001",
                "HashKeyRange": {
                    "EndingHashKey": "17014118346046923173168730371587",
                    "StartingHashKey": "0"
                },
            {
                "ShardId": "shardId-000000000002",
                "HashKeyRange": {
                    "EndingHashKey": "340282366920938463463374607431768211455",
                    "StartingHashKey": "17014118346046923173168730371588"
                },
        ]
    }
}

发件人方设置一个通常为UUID的分区。它始终位于shard-002之上，这使得系统无法进行负载平衡，因此无法扩展。

作为旁注，kinesis使用md5sum分配记录，然后将其发送到包含其范围内的结果哈希的分片。事实上，当我在我使用的UUId上测试它时，它们总是落在同一个碎片中。

echo -n 80f6302fca1e48e590b09af84f3150d3 | md5sum
4527063413b015ade5c01d88595eec11  

17014118346046923173168730371588 < 4527063413b015ade5c01d88595eec11 < 340282366920938463463374607431768211455

关于如何解决这个问题的任何想法？

Answer 1

首先，请参阅此问答：How to decide total number of partition keys in AWS kinesis stream?

关于你的情况;你有2个分片，但它们的散列键范围不相等。

分区键shard 1包含的数量：

17014118346046923173168730371587 - 0 = 17014118346046923173168730371587

分区键shard 2包含的数量：

340282366920938463463374607431768211455 - 17014118346046923173168730371587 = 340282349906820117416451434263037839868

这两者之间存在很大差异;

17014118346046923173168730371587：17 x 10 ^ 30

340282349906820117416451434263037839868：34 x 10 ^ 37

如果碎片1介于＆＃34; 0 - 170141183460469231731687303715884105727＆＃34;那将是非常棒的。和碎片2介于＆＃34; 170141183460469231731687303715884105728 - 340282366920938463463374607431768211455＆＃34;。

您可能使用过台式机或其他低精度计算器。尝试更好的计算器。请参阅下面的示例;

package com.cagricelebi.kinesis.core.utils;

import java.math.BigInteger;

public class MyCalc {

    public static void main(String[] args) {
        try {

            String num1 = "340282366920938463463374607431768211455";
            String num2 = "-17014118346046923173168730371587";

            String diff = bigCalc(num1, num2, "1", "1");
            System.out.println("result1 : " + diff); // 340282349906820117416451434263037839868

            String optimumHalf = bigCalc(num1, "0", "1", "2");
            System.out.println("result2 : " + optimumHalf); // 170141183460469231731687303715884105727

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * Basic calculator.
     * First adds up first two elements, than multiplies the summation.
     * The result is the division of the multilication to divisor.
     *
     * @param bigInt A
     * @param bigInt2 B
     * @param multiplicator C
     * @param divisor D
     * @return ((A+B)*C)/D
     */
    private static String bigCalc(String bigInt, String bigInt2, String multiplicator, String divisor) {
        BigInteger summation = new BigInteger(bigInt).add(new BigInteger(bigInt2));
        BigInteger multiplication = summation.multiply(new BigInteger(multiplicator));
        BigInteger division = multiplication.divide(new BigInteger(divisor));
        return division.toString();
    }

}

Answer 2

经过几个小时的调查，我发现了根本原因，再次是人为错误。在这里分享解决方案，即使节省别人可以花费的时间也很简单。

问题出现的原因是原始流被拆分的方式。使用一个分片拆分流时，必须计算新子分片的起始哈希键。这个新的哈希键通常位于父分片哈希键范围的中间。

新创建的分片（父分片）将具有以下范围：

0 - 340282366920938463463374607431768211455

天真地，你去你的Windows计算器并复制粘贴这个＆＃34; 340282366920938463463374607431768211455＆＃34;然后除以2。

我错过了很容易被遗漏的问题是Windows计算器实际上在不让你知道的情况下截断了数字。上面粘贴在计算器中的数字现在是＆＃34; 34028236692093846346337460743176＆＃34; 。一旦你将它除以2，你实际上得到的数字与父碎片的范围相比非常小，然后你的记录将不会被分发，它们将转到获得该范围较大部分的碎片。

一旦你将上面的数字改为适用于大数字的计算器，你就可以到达范围的中间位置。我用它来计算范围：https://defuse.ca/big-number-calculator.htm。

在此更改之后，记录完美分布，系统可以很好地扩展。

Kinesis分区键始终位于同一个分片

2 个答案: