Как кэш LRU вписывается в теорему CAP? - PullRequest
0 голосов
/ 24 февраля 2019

Я размышлял над этим вопросом сегодня.Кэш LRU в контексте базы данных в веб-приложении помогает обеспечить доступность A благодаря быстрому поиску данных, который не требует постоянного доступа к базе данных.

Однако, как кэш LRU на практике остается свежим?Насколько я понимаю, нельзя гарантировать непрерывность C вместе с доступностью A .Как часто используемый элемент, который, следовательно, не истекает из кэша LRU, обрабатывает изменения?Является ли это примером, когда в системе, где требуется C over A , кэш LRU не является хорошим выбором?

1 Ответ

0 голосов
/ 24 февраля 2019

Прежде всего, кэш, слишком маленький для хранения всех данных (где может произойти выселение, и часть LRU является релевантным), не является хорошим примером для теоремы CAP, потому что даже не смотря на непротиворечивость, он не можетдаже обеспечить терпимость к разделу и доступность одновременно.Если запрашиваемые клиентом данные отсутствуют в кэше, а сетевой раздел не позволяет кэшу своевременно получать данные из первичной базы данных, он просто не может дать клиенту своевременный ответ.

Если мы говорим только о данных, фактически находящихся в кеше, мы можем несколько неловко применять теорему CAP только к этим данным.Тогда это зависит от того, как именно этот кеш используется.

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

Таким образом, CAP-интересным случаем является наличие первичной базы данных и кэша на отдельных машинах, соединенных ненадежнымсеть.В этом случае есть две основные возможности: (1) сервер кэширования может отвечать на запросы, не спрашивая первичную базу данных, все ли данные действительны, или (2) он может проверять первичную базу данных при каждом запросе.(1) означает, что последовательность приносится в жертву.Если его (2), существует проблема, с которой должен разбираться дизайн кеша: что кеш должен сообщить клиенту, если он не получит ответ основной базы данных вовремя (из-за раздела, что является некоторой сетевой проблемой)?В этом случае в основном есть только две возможности: он может по-прежнему отвечать кэшированными данными, рискуя стать недействительным.Это приносит в жертву последовательность.Или он может сказать клиенту, что не может ответить прямо сейчас.Это приносит в жертву доступность.

Итак, в итоге

  • Если все происходит на одной машине, теорема CAP не применяется
  • Если данные и кэш связаныненадежной сетью, это не хороший пример теоремы CAP, потому что вы даже не получаете A & P даже без C.
  • Тем не менее, теорема CAP означает, что вам придется пожертвовать C или даже большеA & P, чем та часть, которую кеш не доставит в первую очередь.
  • Чем именно вы жертвуете, зависит от того, как именно используется кеш.
...