2015-02-19 2 views
1

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

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

Идея этого слайда заключается в том, что при использовании NoSQL + Distributed Cache вы получите проблемы с синхронизацией, это означает проблемы согласованности данных. Вам необходимо синхронизировать распределенный кеш с NoSQL db.

Вопрос: Какие решения/методы уже существуют для такого случая, кроме IMDG? Это может быть как структурами, так и/или передовой практикой. Существуют ли какие-либо конкретные распределенные кэши, которые решают эту проблему?

Вопрос2 [обновлено]: Каковы причины, по которым мы пишем в базу данных NoSQL вместо кеша? Это транзакции, возможность отказа узла или что-то еще?

P.S. Это не мой слайд, и автор заявил, что это отличный вариант для IMDG.

enter image description here

ответ

2

вам действительно нужно распределенный кеш ли? Решения NoSQL по своей природе очень эффективны, приближаясь к работе автономных кэшей (например, memcached).

Я могу получить ~ 10 мс время доступа из Кассандры, что не намного медленнее, чем большинство кешей.

Готов поспорить, что к тому моменту, когда вы нанесли накладные расходы на проверку кеша и сетевые накладные расходы на пропущенные кеш-хиты, вам будет лучше отправиться прямо в вашу базу данных.

Вы все еще можете использовать кеши для вещей, которые менее временны, например, типы номеров, цены и т. Д.

+0

благодарит за ответом! Можете ли вы объяснить свое последнее заявление? Почему я должен использовать кеши для комнат, цены и т. Д., Но не для отелей? Также вы можете попробовать ответить на второй вопрос (я только что добавил) –

+0

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

+0

Кэши - это кеши, а не хранилища данных. В кеше нет требования для таких вещей, как постоянная долговечность (выживание в случае сбоя и т. Д.). Это даже не требует временной долговечности. Обычно они фиксированного размера и не могут хранить больше, чем этот размер. Теперь вы можете (и многие люди) использовать хранилища данных в качестве кешей, но кэширование - это описание операции, а не технологии. Но, как правило, технология кэширования не обеспечивает долговременные или последовательные чтения/записи. Они жертвуют этим ради скорости, которая является их целью. –

Смежные вопросы