Comments 13
Все перечисленные системы накладывают ряд ограничений связанных с парадигмой Map Reduce.
В случае же с набором, описанным в статье, таких ограничений нет.
Я бы, даже, сказал что это совершенно разные подходы к решению совершенно разных задач :)
Например, у вас есть сервер и 1000 бакноматов, вам нужно чтобы все они дождались инициализации сервера.
Очень простое, с точки зрения дизайна, решение (в одну строку!):
Вы можете на каждом из них ждать latch.await(), а на сервере сделать latch.countDown().
В случае же с набором, описанным в статье, таких ограничений нет.
Я бы, даже, сказал что это совершенно разные подходы к решению совершенно разных задач :)
Например, у вас есть сервер и 1000 бакноматов, вам нужно чтобы все они дождались инициализации сервера.
Очень простое, с точки зрения дизайна, решение (в одну строку!):
Вы можете на каждом из них ждать latch.await(), а на сервере сделать latch.countDown().
Я говорю не про вычисления, а именно про операции над данными.
А операции бывают разные,
Например, возьмем, все те же, 1000 банкоматов и раз в час нужно разыграть приз — первый кто оплатит на сумму больше тысячи — победитель.
Подвох в том, что человек должен узнать что он победитель сразу после завершения операции,
Возможны ли подобные гарантии/способы синхронизации на описанных технологиях?
А операции бывают разные,
Например, возьмем, все те же, 1000 банкоматов и раз в час нужно разыграть приз — первый кто оплатит на сумму больше тысячи — победитель.
Подвох в том, что человек должен узнать что он победитель сразу после завершения операции,
Возможны ли подобные гарантии/способы синхронизации на описанных технологиях?
Да, продолжим с 1000 банкоматов.
С каждого из них может поступить запрос на перевод денег, но заранее известно что можно совершать не более 20 переводов одновременно (ограничение в договоре с платежной системой).
Представим также, что сервер у нас не один, а 10 и к каждому из них приписано по 100 банкоматов.
вариант
semaphore.acquire();
doPayment(acc1, acc2, amount);
semaphore.release();
позволит ограничить нагрузку на платежную систему в соответствии с условиями договора в рамках всей системы.
С каждого из них может поступить запрос на перевод денег, но заранее известно что можно совершать не более 20 переводов одновременно (ограничение в договоре с платежной системой).
Представим также, что сервер у нас не один, а 10 и к каждому из них приписано по 100 банкоматов.
вариант
semaphore.acquire();
doPayment(acc1, acc2, amount);
semaphore.release();
позволит ограничить нагрузку на платежную систему в соответствии с условиями договора в рамках всей системы.
Если кратко, то — размер кластера не важен, чем больше диапазон значений, выделяемых на один локальный экземпляр IgniteAtomicSequence, тем быстрее, стремясь с скорости простого чтения из памяти.
Размер кластера не имеет значения, т.к. состояние будет хранится всего на 2-х node (Primary и Backup).
Важно лишь — сколько будет запросов на изменение состояния в рамках одного кластера в единицу времени.
Если диапазон значений, выделяемых на одну node, большой — то запросов будет мало, как следствие — не будет контеншена на глобальном изменении состояния IgniteAtomicSequence и получение нового диапазона будет занимать минимум времени.
Итого, размер кластера не важен, а увеличение числа «клиентов» всегда можно компенсировать увеличением диапазона выделяемых значений.
Размер кластера не имеет значения, т.к. состояние будет хранится всего на 2-х node (Primary и Backup).
Важно лишь — сколько будет запросов на изменение состояния в рамках одного кластера в единицу времени.
Если диапазон значений, выделяемых на одну node, большой — то запросов будет мало, как следствие — не будет контеншена на глобальном изменении состояния IgniteAtomicSequence и получение нового диапазона будет занимать минимум времени.
Итого, размер кластера не важен, а увеличение числа «клиентов» всегда можно компенсировать увеличением диапазона выделяемых значений.
Подробнее как это работает я планирую рассказать в следующей статье, но, вкратце:
Допустим, есть 10 локальных экземпляров IgniteAtomicSequence (по одном у и тому же имени, т.к. привязанные к одному глобальному состоянию).
При создании каждого экземпляра ему выделается, допустим, 100 идентификаторов.
Итого, первому дают номера с 0 по 99, второму с 100 до 199 и т.д.
Глобально хранится информация что было выдано 1000 идентификаторов, т.е. не сколько реально было запрошено, а сколько доступно к выдаче (или уже было выдано) на всех локальных экземплярах.
И, когда, какой то из локальных экземпляров выдает все свои 100 — он запрашивает новые 100 и глобально фиксируется что было выдано не X, а X+100 (например 1000 -> 1100).
Для каждого следующего случая окончания диапазона ситуация повторяется.
Единственным минусом подобной имплементации выступает сложность определения сколько идентификаторов реально используется, а сколько томится в ожидании, но уже отмечено как выданные.
Допустим, есть 10 локальных экземпляров IgniteAtomicSequence (по одном у и тому же имени, т.к. привязанные к одному глобальному состоянию).
При создании каждого экземпляра ему выделается, допустим, 100 идентификаторов.
Итого, первому дают номера с 0 по 99, второму с 100 до 199 и т.д.
Глобально хранится информация что было выдано 1000 идентификаторов, т.е. не сколько реально было запрошено, а сколько доступно к выдаче (или уже было выдано) на всех локальных экземплярах.
И, когда, какой то из локальных экземпляров выдает все свои 100 — он запрашивает новые 100 и глобально фиксируется что было выдано не X, а X+100 (например 1000 -> 1100).
Для каждого следующего случая окончания диапазона ситуация повторяется.
Единственным минусом подобной имплементации выступает сложность определения сколько идентификаторов реально используется, а сколько томится в ожидании, но уже отмечено как выданные.
Sign up to leave a comment.
Распределенные структуры данных [часть 1, обзорная]