Кэширование в сервис-ориентированной архитектуре

Question

В распределенной системной среде у нас есть служба RESTful, которая должна обеспечивать высокую пропускную способность чтения при низкой задержке. Из-за ограничений в технологии базы данных и учитывая ее систему с высокой прочностью, мы решили использовать MemCached. Теперь в SOA есть, по крайней мере, 2 варианта расположения кэша, в основном клиент ищет в кэше до вызова сервера и клиента, который всегда вызывает сервер, который ищет кеш. В обоих случаях кеширование выполняется на распределенном сервере MemCached.

Вариант 1: Клиент -> RESTful Сервис -> Memcached -> База данных

ИЛИ

Вариант 2: Клиент -> Memcached -> RESTful Сервис -> База данных

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

Answer 1

Я видел

Вариант 1: Клиент -> RESTful Service -> Cache Сервер -> База данных

работает очень хорошо. Плюсы IMHO - это то, что вы можете работать и использовать этот слой таким образом, чтобы вы могли «освободить» часть нагрузки на БД. Предполагая, что у ваших конечных пользователей может быть много подобных запросов, и после того, как Клиент сможет решить, какое хранилище необходимо зарезервировать для кеширования. Также как часто его очищать.

Answer 2

Я предпочитаю вариант 1, и в настоящее время использую его. Таким образом легче контролировать нагрузку на БД (так же, как упоминалось @ekostatinov). У меня много данных, которые требуются для каждого пользователя в системе, но данные никогда не меняются (например, некоторые системные правила, типы элементов и т. Д.). Это действительно снижает нагрузку на БД. Таким образом, вы также можете контролировать поведение кеша (например, когда нужно очистить элементы).

Answer 3

Вариант 1 является предпочтительным вариантом, поскольку он делает memcache деталью реализации службы. другой вариант означает, что если бизнес меняется, и все не может быть сохранено в кеше (или другом и т. д.), клиенты должны будут измениться. Вариант 1 скрывает все, что находится за интерфейсом службы. Дополнительно вариант 1 позволяет вам развивать сервис по своему усмотрению. например возможно, позже вы думаете, что вам нужна новая технология, возможно, вы решите проблему производительности с БД и т. д. Опять же, вариант 1 позволяет вам делать все эти изменения, не перетаскивая клиентов в беспорядок.

Answer 4

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

Что касается службы REST ful, эта услуга является контейнером бизнес-логики, и она является полномочием данных, поэтому она решает, сколько кэш, срок действия кеша, когда нужно очистить и т. Д. Клиент, потребляющий REST сервис всегда предполагает, что служба предоставляет ему последние данные. И, следовательно, вариант 1 является предпочтительным.

Кто такой клиент в этом случае? Является ли это оболочкой для вашего REST API. Предоставляете ли вы как клиент, так и услугу.