У меня есть таблица DynamoDB, содержащая пары ключ-значение, которые будут прочитаны рядом приложений. При запуске каждое приложение будет читать всю таблицу и кэшировать ее в памяти.
Проблема, которую я пытаюсь решить, заключается в том, чтобы заставить приложения обновлять свой кеш, если один или несколько элементов в таблице DynamoDB были изменены.
Потоки DynamoDB изначально казались правильным подходом к решению проблемы. Я реализовал потребителя с помощью клиентской библиотеки Kinesis (KCL) в соответствии с рекомендациями AWS. Однако при его реализации я столкнулся с некоторыми проблемами, которые заставляют меня поверить, что я на ложном пути. Конкретно:
Когда я создаю нового потребителя с помощью KCL, он создает новую таблицу DynamoDB для управления арендой и контрольными точками, так что при перезапуске приложения KCL знает, какие записи были использованы, а какие нет. Это не то, что мне нужно для решения этой проблемы. Любые записи потока, которые создаются, когда приложение находится в автономном режиме, не имеют значения, поскольку вся таблица читается при запуске приложения.
Одновременно работают несколько экземпляров одного и того же приложения. Каждого из них нужно уведомлять об обновлениях таблиц. Чтобы реализовать это в KCL, мне нужно присвоить каждому из них уникальное имя приложения. В противном случае они будут использовать общую таблицу аренды, и только одно из приложений получит уведомление. Одна таблица для каждого экземпляра приложения кажется неправильной. Также мне понадобится что-нибудь для удаления неиспользуемых таблиц.
Я также реализовал это, используя вместо этого низкоуровневый API. Это отлично работает, когда есть один осколок. Однако моя реализация не обрабатывает повторное сегментирование, как KCL, поэтому она слишком хрупкая. Кажется неправильным реализовывать обработку повторного шардинга для простой проблемы, которую я пытаюсь решить.
Я начинаю рассматривать другие решения, например:
Реализация лямбда-функции, которая запускается при обновлении таблицы. Функция отправляет уведомление в тему соцсети. Потребители создают подписки SQS по теме и получают уведомления через это. На мой взгляд, в этом решении слишком много движущихся частей.
Сделайте так, чтобы приложения периодически перечитывали всю таблицу и сами определяли, были ли внесены изменения. Это решение кажется немного примитивным, но кажется самым простым.
Все решения, которые я рассмотрел до сих пор, имеют довольно существенные недостатки. Что мне не хватает?
