Несколько потоков Попытка записи в одно и то же хранилище данных No-Sql одновременно - PullRequest
Новая
       27

Несколько потоков Попытка записи в одно и то же хранилище данных No-Sql одновременно

0 голосов
/ 11 июня 2018

У нас есть внутреннее хранилище данных no-sql для нашей компании.Я предоставляю хранилище Key-Value.Значение имеет формат JSON.Я буду называть его XYZ DataStore.

Постановка проблемы:

У меня есть приложение, которое порождает 10-15 потоков одновременно.Каждый поток отвечает за одновременную запись в один и тот же XYZ.Хотя записи, являющиеся PUT, различны (имеется в виду разные ключи).Созданный XYZ Rest Client одноэлементный, то есть все потоки используют один одноэлементный клиент.(Я использую Spring Bean для создания одноэлементного клиента).

Замечание: только один поток может поместить записи в XYZ.Другие потоки вообще не могут писать в sable, даже после задержки.

Как я могу обработать эту параллельную запись в XYZ?Каков предпочтительный способ?

Я могу добиться этого следующим образом:

  • Реализовать блокировку на PUT API на моем конце, и даже если параллельные потоки пытаются писать,с одним потоком он должен быть в состоянии ждать, пока не будет снята блокировка.

    • Я не уверен, как это реализовать.Если у кого-то есть указатели, это будет здорово.

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

    • Здесь я буду использовать java.util.concorrent.BlockingQueue для чтения и записи в очереди, используемой потоками потребителя и производителя.Это правильный путь?

Может кто-нибудь подсказать мне, какой способ лучше всего сделать это?

Кстати, приложение построено на Java с использованием Spring Framework.

TIA

1 Ответ

0 голосов
/ 12 июня 2018

Даже синглтон также гарантирует, что вы ничего не разделяете между потоками, и каждый метод в этом классе является отдельным, только тогда вы можете очень хорошо установить это как синглтон и не беспокоиться о блокировке, так как это будет вызов метода, так что каждый потокпросто вызовет этот метод.вот и все.Здесь вы знаете, что каждая транзакция не выполнена или не основана на ответе метода, поэтому вы решаете, является ли транзакция успешной, или повторно инициируете ее для дальнейшего использования.Задержка не требуется.

В системе массового обслуживания вы, вероятно, считаете, что DeQueue намного лучше в параллельном пакете.увидеть несколько примеров и реализовать это.Это также эффективно, но здесь вы разделяете очередь между несколькими потоками.Вы не будете чувствовать эту медлительность, но здесь происходит обмен опытом.Здесь нет такой транзакции передается для заданных значений или нет.Одна вещь, которую мы можем сделать после успешного завершения, только мы можем исключить значение, в противном случае просто сделаем просмотр один.если сохранить не удается, перейдите в отдельную очередь для последующего использования.это еще одно прощение для нас.Задержка не требуется.

...