Krav: Brug Nginx til at bygge en reverse proxy, ansvarlig for at planlægge alle forespørgsler, backenden udvikles af ASP.NET MVC og distribueres til flere forskellige servere, hvilket danner en backend-klyngeSessionsinformation kan ikke deles, hvilket resulterer i, at nogle forespørgsler ikke behandles korrekt。 Følgende problemer vil opstå:
ASP.NET Hjemmesiden kan omtales som følger:
Almindeligt anvendte løsninger er som følger:
Brug databasen til at gemme SESSIONEN
Da hver server skal bruge den samme session, kan vi gemme sessionen i den samme database, hver gang vi tilgår, går vi til databasen for at tjekke, om der er denne session, eller om den er udløbet, og derefter kan vi synkronisere sessionen for flere servere;
Fortjeneste:At bruge denne metode er enkelt, bekvemt og nemt at komme i gang;
Mangel:Brug af databasen til at synkronisere sessioner vil øge databasens IO og øge belastningen på databasen. Samtidig skal hver adgang opsnappe anmodninger og forespørge databasen, hvilket resulterer i et ekstra lag af adgang og spildt session i databasen.
Brug en cache-mekanisme som Memcache eller Redis til at gemme SESSIONEN
Brug af distribuerede caching-mekanismer som memcache eller redis til at gemme sessionsdata er en populær løsning til load balancing og synkrone sessioner i mange store projekter. Princippet er, at projektet bruger memcache- eller redis-cachen samme sted; når brugeren logger ind, vil sessionen blive gemt i cachen, og uanset hvilken server i projektet der tilgås, vil sessionscachen blive hentet fra samme sted, så sessionssynkronisering let kan realiseres;
Fortjeneste:At bruge cache til at synkronisere sessioner vil ikke øge belastningen på databasen, og du behøver heller ikke manuelt at vurdere, om sessionen eksisterer eller udløber, hvilket eliminerer noget forretningslogik.
Mangel:Memcache eller Redis opdeler hukommelsen i mange specifikationer af lagringsblokke, og der findes blokke med størrelse, hvilket også afgør, at Memcache eller Redis ikke kan udnytte hukommelsen fuldt ud, hvilket vil føre til hukommelsesfragmentering, og hvis lagringsblokkene er utilstrækkelige, vil der også opstå hukommelsesoverløb.
Udnyt ip_hash-mønsteret i Nginx
Denne teknik, også kendt som session keeping, er den ip_hash teknologi i nginx, der gør det muligtForespørgsler fra en bestemt IP-adresse er fastgjort til den samme backend-applikationsserver, så en klient og en backend under denne IP kan etablere en stabil session.
(Men der er også en ulempe, hvis operatørens netværk er mere ustabilt og ustabilt,Egress IP er dynamiskJa, der vil være problemer med denne metode. ）
Testmetoden er at åbne to sites baseret på docker,Du skal oprette en ny index.html-fil under henholdsvis /data/testsite/a og /data/testsite/b, kommandoen er som følger:
Adgang via en browser som vist nedenfor:
Hvis du opretter en ny nginx-container baseret på Docker uden at bruge ip_hash teknologi, kan anmodningen sendes til forskellige backend-servere, som vist i figuren nedenfor:
Ved hjælp af ip_hash teknologi skal du oprette en ny /data/testsite/nginx.conf-fil med følgende konfiguration:
Docker Startup-kommandoen er som følger:
（Cookie-baseret sessionsføring, som kan konsulteres i det fastklemte modul, udeladt）
Nginx-konfiguration:Hyperlink-login er synlig.
(Slut)
|
Opslået på 10/01/2023 20.38.39
|
|
|
|
