Катодий (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 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 5 comments