Vízszintes méretezés php-alkalmazások, 1. rész, php
Képzeljük el, hogy mi történt az oldalon. A folyamat volt lenyűgöző és nagyon elégedett, hogy milyen a látogatók számát növeli.
A tetején, hogy a szerver leállt, és nem tudnak ellenállni az egyre növekvő terhelés. Ahelyett, hogy új ügyfelek megszerzése és / vagy rendszeres látogatók, akkor nem maradt semmi, sőt, egy üres oldalt.
Minden erőfeszítést, hogy folytassa a munkát eredménytelen - még egy újraindítás után, a szerver nem tudja kezelni a beáramló látogatók. Elveszíti a forgalmat!
Senki sem tudja megjósolni a közlekedési problémákat. Nagyon kevés ember foglalkozik a hosszú távú tervezést, ha dolgozik az potenciálisan magas megtérülésű projektekre, hogy megfeleljen a meghatározott határidő.
Hogyan, akkor elkerülése érdekében ezeket a problémákat? Ehhez meg kell oldani két problémát: optimalizáló és a méretezést.
optimalizálás
Először is, meg kell frissíteni a legújabb verzióra a PHP (jelenleg 5.5 verzió, használ OpCache), az adatbázis indexelése és a cache statikus tartalom (ritkán változó oldalakat, mint a Névjegy. FAQ, és így tovább).
Optimalizálás nem csak érinti a caching statikus források. Továbbá lehetőség van arra, hogy egy további nem-Apache-szerver (például nginx), kifejezetten kezelni statikus tartalom.
Az ötlet a következő: teszel nginx előtt az Apache-szerver (Ngiz fog -server frontend és Apache - backend), és utasítsa őt, hogy elkapjam kéréseket statikus erőforrások (azaz a * .jpg * .png * ... mp4. * .html ...), és a szolgáltatás nem küld a kérést az Apache.
Ez a rendszer az úgynevezett fordított proxy (gyakran együtt említik terhelés kiegyenlítő technológia, amely az alábbiakban tárgyaljuk).
skálázás
Kétféle zoom - vízszintes és függőleges.
Azt mondjuk, hogy az oldal skálázható, mivel ellenáll a megnövekedett terhelés átalakítása nélkül a szoftver.
arányosan felemel
Képzeljük el, hogy van egy web szerver a webes alkalmazás. Ez a szerver a következő tulajdonságokkal rendelkezik 4GB RAM. i5 CPU és 1TB HDD.
Ő jól teljesítő rábízott feladatokat, hanem azért, hogy jobban megbirkózzanak a növekvő forgalom, úgy dönt, hogy cserélje ki a 4GB RAM 16GB, telepítse az új i7 CPU, és adjunk hozzá egy hibrid jármű PCIe SSD / HDD.
A szerver mára erősebb és képes ellenállni a megnövekedett terhelést. Ez az úgynevezett függőleges méretezést, vagy „mély zoom” - hogy javítsa a teljesítményt a gép, hogy ez erősebb.
Ezt jól példázza az alábbi ábrán:
horizontális skálázás
Másrészt, képesek vagyunk egy vízszintes méretezés. A fenti példában a vas frissítés költség nem valószínű, hogy kevesebb, mint a költsége az eredeti kiadással vásárlására a szerver számítógépen.
Ez egy nagyon pénzügyileg költséges és gyakran nem ad az értelemben, hogy azt várjuk - a legtöbb kapcsolatos problémák méretezés párhuzamos feladatok végrehajtását.
Ha a CPU magokkal nem tesz eleget létező folyamok, nem számít, milyen erős set CPU - a szerver továbbra is működni fog, lassan, és arra kényszeríti a látogatót, hogy várjon.
Skálázása ki magában foglalja az építés klaszterek gépek (gyakran igen vékony), összekapcsolva szolgálni az oldalon.
Ebben az esetben használjon terheléselosztót (terheléselosztót) - gépnek vagy program, amely nem mi határozza meg, amely klaszter egyszer el kell küldeni a kérelmet.
A gép a fürt automatikusan megosztja a feladatot közöttük. Ebben az esetben a sávszélesség webhely növeli egy nagyságrenddel, mint a függőleges méretezést. Ez is ismert, mint „méretezés szélessége.”
Kétféle típusú terheléskiegyenlítők - hardver és szoftver. Kiegyensúlyozó szoftver telepítve van egy közönséges gépet, és megkapja az összes bejövő forgalom routing azt a megfelelő kezelő. Ennek terheléselosztó szoftver tud végezni, például nginx.
Elveszi kérelmeket a statikus fájlokat szolgálja őket a saját, anélkül, hogy terhelné ez az Apache. Egy másik népszerű program az egyensúlyozási Squid. amit használhatok a cég. Ez biztosítja teljes ellenőrzése alatt minden lehetséges kérdésre egy nagyon barátságos felület.
Hardver balancers egy külön speciális gép, amely végrehajtja a kizárólag a feladat kiegyenlítő, és amely, mint általában, nem állítja be a többi szoftver. A legnépszerűbb modelleket úgy tervezték, hogy kezelni a hatalmas mennyiségű forgalmat.
Amikor a vízszintes skála, a következő történik:
Figyeljük meg, hogy a két tárgyalt módon a skála nem zárják ki egymást -, akkor jellemzőinek javítására hardver gépek (más néven csomópontok - node), használják a skálázott szélessége cluster rendszer.
Ebben a cikkben fogunk összpontosítani skálázás ki, mint a legtöbb esetben célszerű (és kevésbé hatékony), bár ez sokkal nehezebben megvalósítható technikai szempontból.
Nehézségek az adatok megosztása
Vannak pillanatok, csúszós merülnek fel, amikor méretezés PHP-alkalmazásokat. A szűk itt az adatbázisban (fogunk beszélni többet erről a második része a sorozat).
Állandó terhelés kiegyenlítő
Állandó terhelés kiegyenlítő üzletek, ahol azt feldolgozzák az előző kérés egy ügyfél, és ha kéri, kérést küld ugyanaz.
Például, ha én meglátogatta honlapunkat, és jelentkezzen be ott, akkor a terhelés kiegyenlítő átirányítások mondjam, a Server1. emlékszik, hogy ott legyek, és a következő alkalommal, amikor rákattint, én átirányítását Server1. Mindez teljesen átlátszó rám.
De mi van, ha Kiszolgalo1 esik? Természetesen az összes munkamenet adatok elvesznek, és azt kell újra bejelentkezni az új szerverre. Nagyon kellemetlen a felhasználó számára. Sőt, ez egy extra terhelést a terhelés kiegyenlítő: akkor nem kell csak átirányítani több ezer ember a másik szerveren, de ne feledje, ahol átirányítja őket.
Ez lesz a másik szűk keresztmetszet. Mi van, ha az egyetlen terhelés kiegyenlítő maga nem működik, és minden információt a helyét az ügyfelek szerverek elvész? Ki fogja kezelni a kiegyenlítő? A bonyolult helyzet, nem?
Válás helyi adatokat
Elkülönítése adatviszonyok egy klaszteren belül mindenképpen úgy tűnik, egy jó megoldás, de ez megköveteli a változást az építészet, a bejelentés, noha ez éri meg, mert a szűk lesz széles. Az esés egyetlen szerver már nem egy végzetes hatást gyakorol az egész rendszert.
Köztudott, hogy a munkamenet adatok tárolása egy PHP tömb szuperglobális $ _SESSION. Továbbá, ez nem titok, hogy a $ _SESSION tömbben tárolt a merevlemezen.
Ennek megfelelően, mivel a meghajtó tartozik egy adott gépen, míg mások nem férnek hozzá. Akkor hogyan kell megszervezni, hogy ossza meg több számítógépen?
Megjegyezzük, hogy a munkamenet kezelő PHP felübírálható - megadhatjuk a saját osztálya / funkció munkamenet-kezelés.
Az adatbázis
Segítségével saját munkamenet-kezelőt, akkor biztosak lehetünk abban, hogy az összes információt az ülések az adatbázisban tárolt. Az adatbázis kell egy külön szerver (vagy fürt saját). Ebben az esetben egységesen leterheltet, csak azokkal a feldolgozó üzleti logika.
Bár ez a megközelítés működik elég jól esetén a nagy forgalom, az adatbázis nem csak egy sebezhető helyen (vesztes, akkor mindent elveszít), akkor egy csomó alkalmazások, mert az kell írni és olvasni session adat.
Ez akkor válik egy szűk rendszerünkben. Ebben az esetben, akkor lehet alkalmazni méretezés szélessége, ami problémás, ha egy hagyományos MySQL adatbázis típus. Postgre és hasonlók (ez a probléma nyilvánosságra a második része a ciklus).
Egy megosztott fájlrendszert
Itt lehet beállítani a hálózati fájlrendszer, amely vonatkozik az összes szerver, és a munka az adatforgalom. Szóval nem kell tennie. Ez elég hatékony megközelítés, amelyben a valószínűsége adatvesztés, továbbá, hogy működik, nagyon lassan.
Ha nem akarjuk, hogy végre egy lehetőség egy megosztott fájlrendszert, akkor van egy sokkal jobb megoldás - glusterfs.
Használhatja memcached tárolni munkamenet adatokat a RAM. Ez egy nagyon biztonságos módon, a munkamenet adatok íródnak felül, amint a lemezterület.
Bármilyen következetesség hiányzik - a bemeneti adatok kerülnek tárolásra, ameddig memcached -server működik, és van elég szabad hely az adatok tárolására.
Lehet, hogy meglepett - nem rendelkezik külön memória minden gép? Hogyan kell alkalmazni a ezt a módszert egy klaszter? Memcached képes integrálni szinte az összes rendelkezésre álló RAM több gép egyetlen adattár:
Minél több gép van a rendelkezésre álló, annál nagyobb a méret a létrehozott megosztott tárhelyet. Nem kell manuálisan a memóriát az üzletben, de lehet kezelni ezt a folyamatot, meghatározva, hogy mennyi memóriát lehet különböztetni minden gép egy közös térben.
Így a szükséges mennyiségű memória áll rendelkezésre a számítógépek a saját igényeinek. A fennmaradó részt a használt munkamenet adatok tárolása az egész klaszter.
Készpénzben, amellett, hogy az ülések kaphat, és minden más adat, amelyet választott, a lényeg, hogy van elég szabad hely. Memcached egy tökéletes megoldás, amely széles körben elterjedtté vált.
Ezzel a módszerrel a PHP-alkalmazások nagyon egyszerű: meg kell változtatni az értéket a php.ini fájlban:
Redis Cluster
Redis nem SQL adattárban található a fő memória, mint a Memcached. de van egy következetesség és támogatja a több összetett adattípusok, mint húrok PHP tömb formájában párok «kulcs => érték».
Ez a megoldás nem támogatja a klaszterek, így a végrehajtása horizontális skálázás rendszer nem olyan egyszerű, mint amilyennek látszik első pillantásra, de vypolnyaema. Tény, hogy az alfa változata a fürt verzió már most, és használhatja azt.
Redis képest megoldások, mint Memcached. ez egy kereszt között a rendszeres adatbázis és Memcached.
- ZSCM származó Zend - egy jó alternatíva, de fel kell szerelni a Zend Server minden csomóponton a fürt;
- Más, mint az SQL tároló és a cache-rendszer is elég hatékony - Read Scache. Cassandra vagy Couchbase. ezek gyors és megbízható.
következtetés
Mint tudod megérteni a fenti, a vízszintes méretezést a PHP-alkalmazások nem piknik a hétvégén.
Van egy csomó akadályokat, hogyan lehet megoldani, hogy a meglehetősen triviális és megvannak az előnyei és hátrányai. Emellett abban az időben, amikor a forgalom növeli a kritikus szintet, a zökkenőmentes átmenet elvégzésére már, általában lehetetlen.
Fordítása a cikk «Vízszintes skálázása PHP alkalmazások, 1. rész" készítettünk egy csapat barátságos Web design projekt tól Z-ig