Представете си, че сме направили в сайта. Процесът е завладяваща и много доволен да видя как броят на посетителите се увеличава.
На върха на тази неизправност на сървъра и не могат да издържат на все по-нарастващото натоварване. Вместо придобиване на нови клиенти и / или редовни посетители, са оставени без нищо, и, освен това, с празна страница.
Всички ваши усилия за възобновяване на работата на безплодно - дори и след рестартиране, сървърът не може да се справи с наплива от посетители. Губите трафика!
Никой не може да предскаже проблемите на трафика. Много малко хора се занимават с дългосрочно планиране при работа по проекти потенциално високодоходни да отговарят на определените срокове.
Как тогава да се избегнат всички тези проблеми? За да направите това, вие трябва да реши два проблема: оптимизиране и мащабиране.
оптимизация
На първо място, е необходимо да инсталирате най-новата версия на PHP (в момента на версия 5.5, използва OpCache), индекс на базата данни и да кешира статично съдържание (рядко смяна на страниците, като се За. Въпроси и така нататък).
Оптимизация засяга не само кеширането на статични ресурси. Също така е възможно да се инсталира допълнително не-Apache-сървър (например, Nginx), специално проектиран да се справя статично съдържание.
Идеята е следната: да поставите Nginx в предната част на Apache сървър (Ngiz ще -server на интерфейса, както и Apache - гръб) и го инструктира да прихване искания до статичните ресурси (т.е. * .jpg * .png * ... mp4. * .html ...) и техните услуги, без да изпрати искането до Apache.
Тази схема се нарича обратна прокси (това често се споменава заедно с балансиране на натоварването технология, на които бяха обсъдени по-долу).
мащабиране
Има два вида увеличение - хоризонтални и вертикални.
Ние казваме, че сайтът може да се надгражда, тъй като може да издържи на увеличеното натоварване без да се изисква промяна в софтуера.
мащабиране
Представете си, че имате уеб сървър за уеб приложението. Този сървър е със следните характеристики 4GB RAM. i5 CPU и 1TB HDD.
Той е добре за изпълнението на задачи, възложени му, но за да се справят по-добре с нарастващия трафик, вие решавате да замени RAM 4GB при 16 GB, инсталирате новата i7 процесор и добавяне на хибриден автомобил PCIe SSD / HDD.
Сървърът е превърнал по-мощен и е в състояние да издържат на увеличеното натоварване. Това е, което е известно като вертикално мащабиране, или "дълбоко увеличение" - можете да подобрят работата на машината, за да го направи по-силен.
Това е добре показано на фигурата по-долу:
хоризонтално мащабиране
От друга страна, ние сме в състояние да произвежда хоризонтално мащабиране. В примера по-горе, цената на желязо ъпгрейд е малко вероятно да бъде по-малка от стойността на първоначалните разходи за закупуване на сървърния компютър.
Това е един много финансово скъпо и често не дава ефект, който очакваме - голяма част от проблемите, свързани с мащаба паралелно изпълнение на задачи.
Ако броят на CPU ядра не е достатъчно, за да изпълни съществуващите потоци, че няма значение колко мощен набор CPU - сървърът все още ще работи бавно и принуди посетителят да чака.
Увеличаване на включва изграждането на клъстери от машини (често доста тънка), свързани заедно за да служи на сайта.
В този случай, се използва стабилизатор натоварване (натоварване стабилизатор) - машина или програма, която прави това, което определя кои клъстер трябва да бъдат изпратени, след като искането.
Една машина в клъстера автоматично ще споделя задачата между тях. В този случай, на честотната лента на вашия сайт увеличава с един порядък в сравнение с вертикалната мащабирането. Това е също така известен като "мащабиране ширина."
Има два вида на разпределение на натоварването - хардуер и софтуер. Balancer софтуер е инсталиран на един обикновен апарат и получава всички входящи трафик чрез маршрутизиране към съответния манипулатор. Като стабилизатор софтуер натоварване може да изпълнява, например, Nginx.
Той взема искания за статични файлове и да ги обслужва самостоятелно, без да натоварва това Apache. Друга популярна софтуерна програма за балансиране е калмари. които да използвам в моята фирма. Тя осигурява пълен контрол над всички възможни въпроси по един много удобен интерфейс.
Хардуер балансьори е отделна специална машина, която изпълнява изключително задачата за балансиране, и които, като правило, не задавайте на друг софтуер. Най-популярните модели са предназначени да се справят с огромното количество трафик.
Когато хоризонталната скала, се случва следното:
Имайте предвид, че двете обсъдени начините да се мащабират не са взаимно изключващи се - можете да подобрите характеристиките на хардуерните машини (наричани още възли - възли), използвани в мащаб система ширина клъстер.
В тази статия ще се фокусира върху мащабиране навън, тъй като в повечето случаи е за предпочитане (и по-малко ефективен), въпреки че е по-трудно да се прилагат от техническа гледна точка.
Трудности при обмен на данни
Има някои хлъзгави моменти, които възникват, когато мащабиране PHP-приложения. Забавянето тук е базата данни (ще говорим повече за това във втората част на тази серия).
Постоянен стабилизатор натоварване
Постоянни натоварване балансиращи магазини, където се обработват предишното искане на клиента и, когато бъдете подканени, изпраща искане до едни и същи.
Например, ако бях на посещение в нашия сайт и да влезете в системата там, а след това балансьор на товара пренасочвания ми каже, от SERVER1. си спомня за мен там и следващия път, когато щракнете, аз ще пренасочени към server1. Всичко това е напълно прозрачен за мен.
Но какво, ако server1 падне? Естествено, всички данни на сесията ще бъдат загубени, а аз трябва да се логнете отново на нов сървър. Това е много неприятно за потребителя. Нещо повече, това е допълнително натоварване на балансьор натоварване: той ще трябва не само да се пренасочи хиляди хора от друга сървър, но не забравяйте, където той ги пренасочи.
Това става още безизходица. Какво става, ако единственият балансьор натоварване се провали и цялата информация за местоположението на сървърите на клиентите ще бъдат загубени? Кой ще управлява балансирането? Сложната ситуация, не е тя?
Разделяне местно данни
Разделяне на сесии на данни в рамките на един клъстер определено изглежда добро решение, но това изисква промяна в архитектурата на приложението, въпреки че си струва, защото гърлото на бутилката става богат. Падането на един сървър вече не е фатално влияние върху цялата система.
Известно е, че данните за сесията се съхранява в свръхглобална на PHP масив $ _SESSION. Също така, не е тайна, че масива $ _SESSION, съхранена на твърдия диск.
Съответно, тъй като устройството принадлежи към определена машина, а други нямат достъп до него. Тогава как да се организират, за да го споделя с няколко компютъра?
Имайте предвид, че администраторът на този сесия в PHP може да се замени - можете да определите своя клас / функция за управление на сесиите.
Използване на база данни
Използването на собствения си сесия манипулатор, можем да бъдем сигурни, че цялата информация за заседанията се съхраняват в базата данни. Базата данни трябва да бъде на отделен сървър (или клъстер в собствената си). В този случай е равномерно натоварено сървър, ще се занимава само с обработка на бизнес логиката.
Макар че този подход работи достатъчно добре в случай на тежък трафик, базата данни не е просто уязвим място (да го загуби, но и всичко останало), тя ще бъде много приложения, поради необходимостта да се четат и пишат за сесиите.
Това става друг ограничаващ фактор в нашата система. В този случай, можете да кандидатствате мащабиране ширина, което е проблематично, когато се използва традиционен MySQL тип база данни. Postgre и други подобни (този проблем ще бъде описан във втората част на цикъла).
Използване на споделена файлова система
Можете да конфигурирате мрежова файлова система, която ще се прилага за всички сървъри, и да работите с сесии данни. Така че не трябва да правиш. Това е доста неефективен подход, при който вероятността от загуба на данни, в допълнение, тя работи много бавно.
Ако все пак искате да приложи вариант с обща файлова система, а след това има много по-добро решение - GlusterFS.
Можете да използвате Memcached за съхранение на данни на сесии в RAM. Това е един много опасен начин, че данните на сесията ще бъдат презаписани, веднага след като дисково пространство.
Всяка последователност отсъства - на входните данни ще се съхраняват толкова дълго, колкото Memcached -server бягане и има достатъчно свободно място за съхранение на данните.
Може да се изненадате - не разполагат с отделна памет за всяка машина? Как да се прилага този метод, за да клъстер? Memcached има способността да се интегрират почти цялата налична RAM на няколко машини в едно хранилище:
Колкото повече машини, които имате на разположение, толкова по-голям от размера на установения споделеното хранилище. Не е необходимо ръчно да разпредели памет вътре в магазина, но можете да управлявате този процес, като посочва колко памет може да се различава от всяка машина за създаване на общо пространство.
По този начин, необходимото количество памет е на разположение на компютри за своите собствени нужди. Останалата част се използва за съхраняване на сесията данните на цялата клъстера.
В брой, в допълнение към заседанията могат да получат, както и всички други данни по Ваш избор, най-важното, за да има достатъчно свободно място. Memcached е идеалното решение, което е широко разпространено.
Използвайте този метод, в PHP-приложения е много лесно: трябва да промените стойността в php.ini файла:
преразпределяне на клъстера
Redis не е SQL хранилище за данни, разположен в основната памет, като Memcached. но има една последователност и поддържа по-сложни типове данни, отколкото просто струни PHP масив под формата на двойки «ключ => стойност».
Това решение не поддържа клъстери, така че изпълнението на нейната хоризонтална система мащабиране не е толкова просто, колкото изглежда на пръв поглед, но това vypolnyaema. В действителност, алфа версията на версията на клъстер е сега и можете да го използвате.
REDIS в сравнение с разтвори като Memcached. това е кръстоска между редовна база данни и Memcached.
- ZSCM от Zend - добра алтернатива, но това изисква инсталирането на Zend сървър на всеки възел в клъстера;
- Други от SQL съхранение и кеширане система също е доста ефективна - Прочетете Scache. Касандра или Couchbase. те са бързи и надеждни.
заключение
Както можете да се разбере от горното, хоризонталната мащабирането на PHP приложения, не е пикник в края на седмицата.
Има много препятствия, как да се реши, че доста тривиално и имат своите предимства и недостатъци. В допълнение, по времето, когато трафикът се увеличава до критично ниво, на плавен преход за извършване вече, обикновено е невъзможно.
Превод на статията «Хоризонтална Свиване на PHP приложения, част 1" е изготвен от екип на приятелски Уеб дизайн проект от А до Я.
Свързани статии