Катодий (cathody) wrote,
Катодий
cathody

Сферический хайлоад в вакууме, ч.2

Кэш сферический в вакууме

Итак, как работает сферический кэш в вакууме и для чего он нужен?

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

Сферический кэш в вакууме состоит из двух частей - менеджера кэша и кэш-памяти.



Менеджер кэша работает примерно так:

1) получает запрос на данные, обычно в виде "А отдай-ка нам данные по такому-то ключу, да ещё и вот с такими условиями!"
2) получив запрос, лезет в кэш-память. Если в кэш-памяти есть данные и менеджер считает их свежими, то менеджер просто возвращает их обратно источнику запроса.
3) а вот если данных в кэш-памяти нет, или они, по мнению менеджера, устарели, то он лезет во внешнее хранилище данных (БД или даже в файловую систему - в отдельных сферических highload-ах из кэша отдаются картинки).
4) Если менеджер получает данные о внешнего хранилища, он кладёт их в кэш-память и возвращает данные.
5) А вот если данные получить не удалось... тут стратегии разнятся от "давайте дёргать БД до потери пульса" до "сразу скажем FAIL!".

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

А к чему всё это?

А вот к чему:

Кэш эффективен тогда, когда "промахов" гораздо меньше, чем "попаданий". А система, содержащая кэш, работоспособна только тогда, когда количество промахов в кэше меньше, чем способно в пределе обслужить обслуживаемое кэшом хранилище динамических данных.

С точки зрения highload систем это означает, что если производительность системы в существенной мере зависит от кэша, снимающего нагрузку с динамических хранилищ данных (БД или noSQL, неважно) и по архитектуре системы заранее очевидно, что динамическое хранилище в отсутствие кэша не сможет справится с запланированной (либо уже известной) нагрузкой на highload-сайт, то при вводе в эксплуатацию кэша необходимо его "населить" в достаточном количестве востребованными данными из динамического хранилища до того момента, как основной поток запросов пойдёт через новоявленный кэш.

Если же этого не сделать, то кэш, память которого к моменту введения в строй будет состоять, главным образом, из мнимой части, будет вынужден активно обращаться к базе данных, чтобы превратить мнимую часть в действительную - то есть делать ровно противоположное тому, для чего он предназначен. Иными словами, кэш будет активно DoS-ить (или, если кэш установлен на нескольких серверах, то DDoS-ить) хранилища данных, отчего highload-систему в целом постигнет резкое падение производительности, вплоть до явления внешним клиентам системы сообщений о невозможности найти сайт и о невозможности получить данные от базы и впадении в медитацию.

Кажется, я где-то видел подобное.


Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments