1. Mi a terheléselosztás
Egy új weboldalnak nem szabad terhelést kiosztani, mert a forgalom nem nagy, így nincs szükség ezekbe a dolgokba. Azonban a weboldal forgalma és forgalma gyors növekedésével egyetlen szerver saját hardveres állapota miatt korlátozódik, és nehéz elviselni ilyen sok látogatást. Ebben az esetben két lehetőség közül választhatsz:
1. Frissítse egyetlen szerver hardverét, dualcoresról négymagosra, növelje a memóriát stb.
2. Növeljék a szerverek számát, hogy megosszuk a szerverek terhét. A hálózati sávszélesség növelésének és a szerver feldolgozási kapacitásának növelésének célja elérésé.
Az első módszer úgy érthető, mint függőleges fejlődés, amely mindig korlátozott. A második módszer a megfelelő megoldás a probléma megoldására
A terheléskiegyenlítési módszerek két irányba oszthatók: az egyik szoftver használata a terheléselosztás eléréséhez, a másik pedig a hardveres terheléselosztás megvalósítása (beleértve a hardver és szoftver kombinálását is)
Szoftvert használunk a terheléselosztás eléréséhez, és a terheléskiegyensúlyozás folyamata is rendszererőforrásokat fogyaszt, növelve a válaszidőt. Például az LVS, nginx, haproxy, apache stb., ezek az alkalmazásalapú terheléskiosztó szoftverek alkalmasak olyan weboldalakra, amelyeknek nincs különösebb látogatottságuk. Ha van egy weboldalad, ahol sok látogató van, mint például a sina és a 163, akkor a hardver használata a terheléselosztáshoz a legnyilvánvalóbb választás.
Számos terheléskiosztó algoritmus létezik, beleértve a terheléselosztást a kérések száma, gyökér IP-címek és forgalom-alapú algoritmusok alapján. Két algoritmust használok gyakran.
Az egyik a kérések számán alapul
A: felismerheti, hogy minden szerver egyenlően megoszthatja az ügyfél kérését, és ha az egyik szerver leáll, az nem okoz rossz hatást.
b. A szerverek közötti állapotot szinkronizálni kell, például a sessioneket, és más módszerekre van szükség ezeknek az állapotoknak a szinkronizálásához.
Az egyik az IP szerint
A: ip_hash algoritmus képes IP-t leképezni egy szerverre, ami megoldhatja a szingolás problémáját
b. A ip_hash rossz része, hogy ha az egyik szerver leáll, az ehhez a szerverhez feltérképezett felhasználók depressziódni fognak.
c, ip_hash könnyen kiegyensúlyozatlan terheléshez vezethet, most a folyamrák kormánya szűri a Google keresőkulcsszavait, gyakran tapasztalhatod, hogy a Google nem tud megnyitni, de egy idő után rendben lesz. Ez lehangolta ezeket a Google-rajongókat, és sok felhasználó külföldre utazott, hogy ügynököt találjon. Ha ez megtörténik, ezek a proxyk ugyanarra a szerverre kerülnek, ami kiegyensúlyozatlan terhelést és akár hibákat is okozhat.
Másodszor, mi az üléstartás és mi a funkciója
A session hold egy olyan mechanizmust jelent a terheléselosztóban, amely biztosítja, hogy ugyanahhoz a felhasználóhoz tartozó hozzáférési kérések ugyanarra a szerverre kerüljenek elosztásra, miközben terheléselosztást végeznek.
Mit csinálnak a session hold, mondj példát
Ha egy felhasználói hozzáférési kérelmet rendelnek az A szerverre, és bejelentkezik az A szerverre, és rövid időn belül ez a felhasználó újabb kérést küld, ha nincs session hold funkció, akkor valószínűleg a B szerverhez van rendelve, jelenleg nincs bejelentkezés a B szerveren, így újra be kell jelentkezni, de a felhasználó nem tudja, hová van rendelve a kérése, a felhasználó úgy érzi, hogy be van jelentkezve, miért kell újra bejelentkeznie, a felhasználói élmény nagyon rossz.
Ha pedig vásárolsz valamit a Taobao-n, a login = "Shoot something=" add address = "to pay" -ből, ez egy folyamatsorozat, amit működési folyamatként is értelmezhetünk, az összes műveleti folyamatsorozatot egy szervernek kell teljesítenie, és a terheléselosztó nem rendelheti meg különböző szerverekre.
A session holdingnak időkorlátja van (kivéve azokat a szervereket, amelyek fix szerverhez vannak leképezve, például ip_hash), és különböző terheléskiosztó eszközök biztosítják ezt a session hold time beállítást, LVS-t, apache stb. Még a PHP nyelv is session.gc_maxlifetime a szekció váratának beállításához
A szekció tartási idejét többet kell beállítani, mint a túlélési idő, ami csökkentheti a szinkronizáció szükségességét, de ezt nem lehet megszüntetni. Szóval a szinkronizáció még mindig el kell végezni.
Harmadszor, a szinkronizáció
Miért a szinkronizáció, azt említették már a session keeping témákban. További információért lásd: Három módja a session szinkronizációnak egy webklaszterben
Egy webklaszterben három szinkronizációs módszer létezik
Webes klaszter után mindenképp először a session szinkronizációt fogod fontolgatni, mert a terheléselosztás után ugyanaz az IP-hozzáférés ugyanahhoz az oldalhoz különböző szerverekhez kerül. Ez a cikk három különböző megoldást kínál a probléma megoldására az adott helyzet szerint:
Először használd az adatbázist a szinkronizációra a szekció
Ezt a módszert nem használtam többszerveres szinkronizációnál, de ha ezt kellene használnom, két módszert gondoltam ki:
1. Használjon alacsony kategóriás számítógépet adatbázis létrehozására, amely tárolja a webszerver ülését, vagy ezt a speciális adatbázist a fájlszerveren építse fel; amikor a felhasználó eléri a webszervert, megkeresi a speciális adatbázist, hogy ellenőrizze a szekció helyzetét a szinkronizáció célja eléréséhez.
2. Ez a módszer az, hogy a tábla, ahol a szekció tárolódik, más adatbázis-táblákkal együtt helyezzük el, ha a mysql is klaszterezett, minden mysql csomópontnak tartalmaznia kell ezt a táblát, és ennek az adattáblának valós időben szinkronizálnia kell.
Magyarázat: Az adatbázis használata az ülések szinkronizálására növeli az adatbázis terhét, amely eleve hajlamos a szűk keresztmetszetekre. A fenti két módszer közül az első jobb, amely függetlenül választja el a táblázatot, ahol a szekció elhelyezkedik, így csökkentve a valódi adatbázis terhét
2. Használjon sütiket a szinkronizációra
A session a szerver oldalon tárolt fájlhelyzet, a cookie pedig a kliens fájlhelyzete, hogyan lehet elérni a szinkronizációt? A módszer nagyon egyszerű: a felhasználó látogatási oldala által generált alkalmat a sütikbe helyezzük, vagyis a sütit használjuk átadóállomásként. Meglátogatod az A webszervert, létrehozol egy alkalmat és beteszed a sütikbe, a hozzáférésed a B webszerverhez van rendelve, ekkor a B webszerver először eldönti, hogy a szervernek van-e ilyen ülés, ha nincs, akkor nézd meg, van-e ilyen ülés az ügyfél sütijében, ha nincs, az azt jelenti, hogy a szekció valójában nincs mentve, ha van ilyen a sükiben, Szinkronizáld a süti sesoinját a B webszerverrel, hogy a szekció szinkronizálható lehessen.
Megjegyzés: Ez a módszer egyszerű és kényelmes a megvalósítása, és nem növeli az adatbázis terhét, de ha az ügyfél letiltja a sütiket, akkor a szekció nem szinkronizálható, ami veszteségeket okoz a weboldalnak; A sütik nem túl biztonságosak, és bár titkosították, még mindig hamisíthatók.
3. Használd a memcache-t a szinkronizációhoz
A Memcache terjeszthető, és e funkció nélkül nem használható szállószinkronizációra. A webszerver memóriáját össze tudja építeni, hogy "mempool" legyen, függetlenül attól, melyik szerver generál sessoint, be lehet helyezni ebbe a "mempoolba", és minden más használható.
Előnyök: az ilyen szinkronizáció nem növeli az adatbázis terhét, a biztonság jelentősen javul a sütik használatához képest, és az ülések memóriába helyezése sokkal gyorsabb, mint a fájlokból olvasás.
Hátrányok: a memcache sokféle tárolóblokk specifikációra osztja a memóriát, vannak blokkok és méretek, így azt is meghatározza, hogy a memcache nem tudja teljesen kihasználni a memóriát, ami memória fragmentációt okoz, ha a tárolóblokk nem elegendő, akkor memória túlcsordulást is eredményez.
Negyedik, összefoglaló
Mindhárom fent említett módszer megvalósítható
Az első módszer, amely a leginkább befolyásolja a rendszer sebességét, nem ajánlott;
A második módszer jó eredményeket hoz, de a biztonsági kockázatok ugyanazok;
A harmadik módszer, szerintem a harmadik a legjobb, mindenkinek ajánlom, hogy használja;
|
Közzétéve 2015. 05. 14. 0:16:44
|
|
|
