Ключ раздела Kinesis всегда находится в одном сегменте

Прежде всего, просмотрите эти вопросы и ответы: Как определить общее количество ключей разделов в AWS kinesis stream?

О вашей ситуации; у вас есть 2 шарда, но их диапазон хеш-ключей не равен.

Количество ключей разделов, которые шард 1 содержит:

17014118346046923173168730371587 - 0 = 17014118346046923173168730371587

Количество ключей разделов, которые шард 2 содержит:

340282366920938463463374607431768211455 - 17014118346046923173168730371587 = 340282349906820117416451434263037839868

Между этими двумя есть большая разница;

17014118346046923173168730371587 : 17 x 10^30

340282349906820117416451434263037839868 : 34 x 10^37

Было бы замечательно, если бы сегмент 1 находился в диапазоне «0–170141183460469231731687303715884105727», а сегмент 2 - в диапазоне «170141183460469231731687303715884105728 - 340282366920938463463374607431768211455».

Вы, вероятно, использовали настольный компьютер или другой калькулятор с более низкой точностью. Попробуйте калькулятор получше. См. Пример ниже;

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();
    }

}

После нескольких часов расследования я обнаружил основную причину - опять же человеческий фактор. Поделитесь решением здесь, даже если это просто сэкономить время, которое кто-то может потратить на него.

Проблема возникла из-за способа разделения исходного потока. Когда вы разделяете поток с одним осколком, вам нужно вычислить начальный хеш-ключ нового дочернего осколка. Этот новый хэш-ключ обычно находится в середине диапазона хэш-ключей родительского сегмента.

Вновь созданный осколок (родительский) будет иметь следующий диапазон:

0 - 340282366920938463463374607431768211455

Так что наивно вы идете к своему калькулятору Windows и копируете, вставляете это "340282366920938463463374607431768211455", а затем делите его на 2.

Проблема, которую я пропустил и которую легко упустить, заключается в том, что калькулятор Windows фактически обрезает число, не сообщая вам об этом. Приведенное выше число, вставленное в калькулятор, теперь будет «34028236692093846346337460743176». Как только вы разделите его на 2, вы фактически получите число, которое очень мало по сравнению с диапазоном родительского осколка, и тогда ваши записи не будут распространяться, они перейдут к осколку, который получил большую часть диапазона.

Как только вы возьмете указанное выше число в калькулятор, адаптированный для больших чисел, вы попадете прямо в середину диапазона. Я использовал это для вычисления диапазона: https://defuse.ca/big-number-calculator.htm.

После этого изменения записи отлично распределяются, и система хорошо масштабируется.