В веб-приложении производителя-потребителя должен быть продуманный процесс создания ключа раздела для осколка потока кинезитов. Предположим, у меня поток кинезий с 16 осколками, сколько ключей разделов я должен создать? Действительно ли это зависит от количества осколков?Как определить общее количество ключей раздела в потоке AWS kinesis?
Partition (или Хэш) Ключ: начинается от 1 до 340282366920938463463374607431768211455. Допустит ~ 34020 * 10^34, я опущу 10^34 для простоты ...
Если у вас есть 30 черепков, равномерно разделена , каждый из них должен содержать 1134 * 10^34 хэш-ключей. Покрытие должно быть таким.
Shard-00: 0 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020
И если у вас есть 3 потребительские приложения (слушающих эти 30 черепков), каждый должен слушать 10 Осколки (оптимальный сбалансированный).
Это также объясняет операции слияния и разделения по потоку.
Shard-31: 0 - 567 Shard-32: 568 - 1134 Shard-01: 1135 - 2268 Shard-03: 2269 - 3402 Shard-04: 3403 - 4536 ... Shard-28: 30619 - 31752 Shard-29: 31753 - 32886 Shard-30: 32887 - 34020
See, осколок-00 больше не будет принимать новые данные. Новые записи, которые помещаются в поток Kinesis с тем же диапазоном ключей раздела (как Shard-00), будут помещены под Shard-31 или Shard-32.
При отправке данных в Kinesis (то есть на стороне производителя) вам не следует беспокоиться о том, «какие данные обходят данные». Отправка случайного числа (или uuid или текущей метки времени в миллисекундах) было бы лучше всего для масштабирования и распределения данных эффективно на осколках. Если вы не беспокоитесь о заказе записей в одном осколке, лучше выбрать случайное число/постоянно меняющийся ключ раздела для запроса put_record.
В Java вы можете использовать «putRecordsRequestEntry.setPartitionKey(Long.toString(System.currentTimeMillis()))» или «putRecordRequest.setPartitionKey(Long.toString(System.currentTimeMillis()))» могут быть примерами.
У нас возникла плохая ситуация с ** timestamp **. В milisecond различиях текущая временная метка как ключ раздела не работает должным образом. Таким образом, мы изменили его с помощью ** uuid **. –
Это полностью зависит от варианта использования. Все, что вам нужно, это убедиться, что все соответствующие данные поступают в один осколок, чтобы можно было агрегировать данные для ключа, если это необходимо.
Если у вас нет этого требования, используя любой случайный ключ, все должно быть в порядке.
Взгляните на этот вопрос, возможно, это поможет; http://stackoverflow.com/a/31377161/1622134 – az3