Полная Версия: Принципы разработки под высокие нагрузки
| Цитата (Invis1ble @ 19.01.2013 - 23:16) | ||
waldicom
Какие например могут возникнуть проблемы при инвалидации кэша, если используются тэги? Я просто на практике пока не сталкивался, поэтому интересно. |
можно по-подробнее про теги? какую-нить ссылько.
Пока про такое не слышал или употребляю другой термин.
Про ключ (например в redis'е) речь не идет, или?
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Ну право, господа. Мы сейчас про сайты или высоконагруженные системы рассуждаем?
Вы поймите, при высоких нагрузках волей-неволей приходится разносить данные по физическим серверам. И тут как раз начинается достаточно серьёзная проблема с синхронизациями и инвалидациями кэша. Кэш хорош тогда, когда сервер (один, одна связка) работает практически на пределе, и нужно как то попытаться оптимизировать существующие процессы.
А когда начинаются репликации, роутинг и прочая, синхронизировть и управлять кэшем становится той еще каторгой. И уж лучше ну его, до последнего.
На шаредах или на единичных дедиках он спасает. Не надолго)))
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Вы поймите, при высоких нагрузках волей-неволей приходится разносить данные по физическим серверам. И тут как раз начинается достаточно серьёзная проблема с синхронизациями и инвалидациями кэша. Кэш хорош тогда, когда сервер (один, одна связка) работает практически на пределе, и нужно как то попытаться оптимизировать существующие процессы.
А когда начинаются репликации, роутинг и прочая, синхронизировть и управлять кэшем становится той еще каторгой. И уж лучше ну его, до последнего.
На шаредах или на единичных дедиках он спасает. Не надолго)))
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
waldicom
C Redis не работал, к сожалению. Под тегами я подразумеваю некую характеристику кэша, которая определяет его принадлежность к определенной группе данных. Т.е. если у нас меняются некие данные, то ищем кэш, который относится к этим данным и инвалидируем его.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
C Redis не работал, к сожалению. Под тегами я подразумеваю некую характеристику кэша, которая определяет его принадлежность к определенной группе данных. Т.е. если у нас меняются некие данные, то ищем кэш, который относится к этим данным и инвалидируем его.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (twin @ 20.01.2013 - 00:13) |
| Вы поймите, при высоких нагрузках волей-неволей приходится разносить данные по физическим серверам. И тут как раз начинается достаточно серьёзная проблема с синхронизациями и инвалидациями кэша. Кэш хорош тогда, когда сервер (один, одна связка) работает практически на пределе, и нужно как то попытаться оптимизировать существующие процессы. А когда начинаются репликации, роутинг и прочая, синхронизировть и управлять кэшем становится той еще каторгой. И уж лучше ну его, до последнего. |
Ну не совсем так. Возьмем, к примеру, redis (что поделать, я с ним работаю). Тот факт, что у нас приложение запущено на 4 машинах не играет никакой роли, потому что redis запущен на отдельном сервере и слушает по TCP.
Если мы разнесем приложение на еще больше сервером (или сократим из количество), то ничего не поменяется. )
Но сама идея, что инвалидация кеша может стать непростым делом, если это не продуманно сразу - это да.
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
| Цитата (Invis1ble @ 20.01.2013 - 00:13) |
C Redis не работал, к сожалению. Под тегами я подразумеваю некую характеристику кэша, которая определяет его принадлежность к определенной группе данных. Т.е. если у нас меняются некие данные, то ищем кэш, который относится к этим данным и инвалидируем его. |
ммм, интересно. Я почитаю сначала и скажу, про что думал я.
Но на первый взгляд речь идет о чем-то большем, чем просто ключ кеша.
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
waldicom
я наверное не совсем удачно выразился, здесь подробней сама идея тегирования описана (технологии реализации идеи вторичны, конечно же. важен сам принцип).
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
я наверное не совсем удачно выразился, здесь подробней сама идея тегирования описана (технологии реализации идеи вторичны, конечно же. важен сам принцип).
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
twin
| Цитата |
| Вы поймите, при высоких нагрузках волей-неволей приходится разносить данные по физическим серверам. И тут как раз начинается достаточно серьёзная проблема с синхронизациями и инвалидациями кэша. Кэш хорош тогда, когда сервер (один, одна связка) работает практически на пределе, и нужно как то попытаться оптимизировать существующие процессы. |
Ну так надо сразу при проектировании системы закладывать в нее возможность горизонтального масштабирования и именно в код системы. Репликация и прочие вещи это просто костыли. Я уже писал про уход от любых JOIN, эта практика поможет в дальнейшем вынести отдельные таблицы в отдельные БД на других серверах и соответственно при грамотной реализации кеширования данных из этих таблиц кеш так же может быть вынесен на отдельные сервера. Вот вам и горизонтальное масштабирование.
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Здесь расположена полная версия этой страницы.