1. Kas ir slodzes līdzsvarošana
Jaunai vietnei nevajadzētu būt līdzsvarotai slodzei, jo satiksmes apjoms nav liels, tāpēc nav nepieciešams iesaistīties šajās lietās. Tomēr, strauji pieaugot vietnes trafikam un trafikam, vienu serveri ierobežo savi aparatūras apstākļi, un ir grūti izturēt tik lielu apmeklējumu skaitu. Šajā gadījumā ir divas iespējas, no kurām izvēlēties:
1. Atjauniniet viena servera aparatūru no divkodolu līdz četrkodoliem, palieliniet atmiņu utt.
2. Palieliniet serveru skaitu, lai dalītu serveru slogu. Lai sasniegtu mērķi palielināt tīkla joslas platumu un palielināt servera apstrādes jaudu.
Pirmo metodi var saprast kā vertikālu attīstību, kas vienmēr ir ierobežota. Otrā metode ir pareizā izvēle problēmas risināšanai
Slodzes balansēšanas metodes var iedalīt divos virzienos, viens ir izmantot programmatūru, lai panāktu slodzes līdzsvarošanu, bet otrs ir ieviest aparatūras slodzes balansēšanu (ieskaitot aparatūras un programmatūras apvienošanu)
Izmantojiet programmatūru, lai panāktu slodzes līdzsvarošanu, un slodzes līdzsvarošanas process patērē arī dažus sistēmas resursus un palielina reakcijas laiku. Piemēram, LVS, nginx, haproxy, apache utt., Šī lietojumprogrammu slodzes balansēšanas programmatūra ir piemērota vietnēm, kurām nav īpaši liels apmeklējumu skaits. Ja jums ir vietne ar lielu apmeklējumu skaitu, piemēram, sina un 163, aparatūras izmantošana slodzes līdzsvarošanai ir acīmredzamākā izvēle.
Ir daudz slodzes balansēšanas algoritmu, tostarp slodzes balansēšana, pamatojoties uz pieprasījumu skaitu, saknes IP adresēm un datplūsmas algoritmiem. Ir divi algoritmi, kurus es bieži izmantoju.
Viens ir balstīts uz pieprasījumu skaitu
A, tas var saprast, ka katrs serveris var vienmērīgi koplietot klienta pieprasījumu, un, ja viens no serveriem nedarbojas, tas neradīs sliktu ietekmi.
b. Stāvoklis starp serveriem ir jāsinhronizē, piemēram, sesija, un šo stāvokļu sinhronizēšanai ir nepieciešami citi līdzekļi.
Viens ir saskaņā ar IP
A, ip_hash algoritms var kartēt IP uz serveri, kas var atrisināt sesijas sinhronizācijas problēmu
b. Sliktā lieta ip_hash ir tā, ka, ja kāds no serveriem nedarbojas, lietotāji, kas kartēti uz šo serveri, tiks nomākti.
c, ip_hash var viegli novest pie nelīdzsvarotas slodzes, tagad upes krabju valdība filtrē Google meklēšanas atslēgvārdus, jūs bieži atradīsit, ka Google nevar atvērt, bet pēc kāda laika tas būs labi. Tas padarīja šos Google entuziastus nomāktus, un daudzi lietotāji devās uz ārzemēm, lai atrastu aģentus. Ja tas notiek, šie starpniekserveri tiks piešķirti tam pašam serverim, izraisot nelīdzsvarotu slodzi un pat kļūmi.
Otrkārt, kas ir sesijas turēšana un kāda ir tās funkcija
Sesijas aizturēšana attiecas uz slodzes balansētāja mehānismu, kas nodrošina, ka piekļuves pieprasījumi, kas saistīti ar vienu un to pašu lietotāju, tiek izplatīti vienam un tam pašam serverim, veicot slodzes līdzsvarošanu.
Ko dara sesijas aizturēšana, sniedziet piemēru
Ja lietotāja piekļuves pieprasījums ir piešķirts serverim A un piesakās serverī A, un īsā laika posmā šis lietotājs nosūta citu pieprasījumu, ja nav sesijas aizturēšanas funkcijas, šī lietotāja pieprasījums, visticamāk, tiks piešķirts serverim B, šobrīd serverī B nav pieteikšanās, tāpēc jums ir jāpiesakās vēlreiz, bet lietotājs nezina, kur ir piešķirts viņa pieprasījums, lietotāja sajūta ir tāda, ka viņš ir pieteicies, kāpēc viņam ir jāpiesakās vēlreiz, lietotāja pieredze ir ļoti slikta.
Un, ja jūs kaut ko iegādājaties Taobao, no pieteikšanās = "Šaut kaut ko=" pievienot adresi = "maksāt", tā ir procesu virkne, ko var saprast arī kā darbības procesu, visas šīs darbības procesu sērijas jāpabeidz vienam serverim, un slodzes balansētājs to nevar piešķirt dažādiem serveriem.
Sesijas aizturēšanai ir laika ierobežojums (izņemot serverus, kas ir kartēti uz fiksētu, piemēram, ip_hash), un dažādi slodzes balansēšanas rīki nodrošinās šo sesijas aizturēšanas laika iestatījumu, LVS, apache utt. Pat PHP valoda nodrošina session.gc_maxlifetime sesijas aizturēšanas laika iestatīšanai
Sesijas aizturēšanas laiks ir jāiestata ilgāk par sesijas izdzīvošanas laiku, kas var samazināt nepieciešamību sinhronizēt sesijas, bet to nevar novērst. Tāpēc sesiju sinhronizācija joprojām ir jāveic.
Treškārt, sesijas sinhronizācija
Kāpēc sesijas sinhronizācija, tas ir minēts, runājot par sesijas saglabāšanu. Papildinformāciju skatiet sadaļā Trīs sesiju sinhronizācijas metodes tīmekļa klasterī
Tīmekļa klasterī ir trīs sesiju sinhronizācijas metodes
Pēc tīmekļa klastera veikšanas vispirms noteikti apsvērsiet sesijas sinhronizāciju, jo pēc slodzes balansēšanas dažādiem serveriem tiks piešķirta viena un tā pati IP piekļuve vienai un tai pašai lapai. Tātad šajā rakstā ir sniegti trīs dažādi veidi, kā atrisināt šo problēmu atbilstoši šai situācijai:
Vispirms izmantojiet datu bāzi, lai sinhronizētu sesiju
Es neizmantoju šo metodi, veicot vairāku serveru sesiju sinhronizāciju, bet, ja man bija jāizmanto šī metode, es domāju par divām metodēm:
1. Izmantojiet zemas klases datoru, lai izveidotu datu bāzi, lai saglabātu tīmekļa servera sesiju, vai izveidojiet šo īpašo datu bāzi failu serverī, kad lietotājs piekļūst tīmekļa serverim, viņš dosies uz šo īpašo datu bāzi, lai pārbaudītu sesijas situāciju, lai sasniegtu sesijas sinhronizācijas mērķi.
2. Šī metode ir ievietot tabulu, kurā sesija tiek glabāta kopā ar citām datu bāzes tabulām, ja mysql ir arī sagrupēts, katram mysql mezglam jābūt šai tabulai, un šīs sesijas tabulas datu tabulai jābūt sinhronizētai reāllaikā.
Paskaidrojums: Datu bāzes izmantošana sesiju sinhronizēšanai palielinās datu bāzes slogu, kas pēc būtības ir pakļauta sastrēgumiem. Pirmā no iepriekš minētajām divām metodēm ir labāka, kas atdala tabulu, kurā sesija tiek ievietota neatkarīgi, samazinot slogu reālajai datu bāzei
2. Izmantojiet sīkdatnes sesiju sinhronizēšanai
sesija ir faila situācija, kas tiek saglabāta servera pusē, un sīkdatne ir faila situācija klientā, kā panākt sinhronizāciju? Metode ir ļoti vienkārša, tas ir, ievietot lietotāja apmeklējuma lapas ģenerēto sesiju sīkdatnē, tas ir, izmantot sīkdatni kā pārraides staciju. Jūs apmeklējat tīmekļa serveri A, ģenerējat sesiju un ievietojat to sīkfailā, jūsu piekļuve ir piešķirta tīmekļa serverim B, šobrīd tīmekļa serveris B vispirms spriež, vai serverim ir šī sesija, ja nē, dodieties redzēt, vai klienta sīkfailā ir šī sesija, ja nē, tas nozīmē, ka sesija patiešām nav saglabāta, ja sīkdatnē tāda ir, Sinhronizējiet sīkdatnē esošo sessoin ar tīmekļa serveri B, lai sesiju varētu sinhronizēt.
Piezīme: Šī metode ir vienkārša un ērti īstenojama, un tā nepalielinās datu bāzes slogu, bet, ja klients atspējo sīkdatnes, tad sesiju nevar sinhronizēt, kas radīs zaudējumus vietnei; Sīkdatnes nav īpaši drošas, un, lai gan tās ir šifrētas, tās joprojām var būt viltotas.
3. Izmantojiet memcache, lai sinhronizētu sesijas
Memcache var izplatīt, un bez šīs funkcijas to nevar izmantot sesijas sinhronizācijai. Viņš var apvienot atmiņu tīmekļa serverī, lai kļūtu par "mempool", neatkarīgi no tā, kurš serveris ģenerē sessoin, to var ievietot šajā "mempool", un visu pārējo var izmantot.
Priekšrocības: sesiju sinhronizēšana šādā veidā nepalielina datu bāzes slogu, un drošība ir ievērojami uzlabota, salīdzinot ar sīkdatņu izmantošanu, un sesiju ievietošana atmiņā ir daudz ātrāka nekā lasīšana no failiem.
Trūkumi: memcache sadala atmiņu daudzās specifikācijās atmiņas bloki, ir bloki un izmēri, tādā veidā arī nosaka, memcache nevar pilnībā izmantot atmiņu, radīs atmiņas sadrumstalotību, ja atmiņas bloks ir nepietiekams, tas arī radīs atmiņas pārplūdi.
Ceturtkārt, kopsavilkums
Visas trīs iepriekš minētās metodes ir iespējamas
Pirmā metode, kas visvairāk ietekmē sistēmas ātrumu, nav ieteicama;
Otrajai metodei ir labi rezultāti, bet drošības apdraudējumi ir vienādi;
Trešā metode, es personīgi domāju, ka trešā metode ir labākā, es iesaku visiem to izmantot;
|
Publicēts 14.05.2015 00:16:44
|
|
|
