სესიები Valkey-ში: Express, Django, Laravel, PHP და .NET

სესიების საცავს ერთი საქმე აქვს: ნებისმიერმა პროცესმა, რომელიც მომხმარებელს ემსახურება, სწრაფად იპოვოს ამ მომხმარებლის სესია და დაივიწყოს ის, როცა ვადა გაუვა. როგორც კი მეორე აპლიკაციის პროცესს, მეორე კონტეინერს ან deploy-ს გაუშვებ, რომელიც პირველს ცვლის, პროცესის შიდა სესიები ამ საქმეს ვეღარ აკეთებს - მომხმარებელი ერთ worker-ზე შედის და მომდევნოზე ანონიმურია. Valkey ამას თითქმის კოდის გარეშე ასწორებს: აქ განხილულ ყველა ფრეიმვორკს აქვს სესიების backend, რომელიც Redis-ის პროტოკოლზე საუბრობს, Valkey კი მას უცვლელად საუბრობს.

კონფიგურაცია მოკლე ნაწილია. production-ში იმუშავებს თუ არა, ოთხი პარამეტრი წყვეტს, რომლებსაც ხალხი ტოვებს: გასაღების პრეფიქსი, რომ ორმა აპმა სესიები არ გაიზიაროს, TTL, რომელიც cookie-ს ემთხვევა, eviction პოლიტიკა, რომელიც შესულ მომხმარებლებს არ გადააგდებს, და შენახვა დისკზე, რომ restart-მა ყველა არ გამოაგდოს. ეს პოსტი გაძლევს მომუშავე კონფიგურაციას Express-ისთვის, Django-სთვის, Laravel-ისთვის, სუფთა PHP-ისთვის და ASP.NET Core-ისთვის, შემდეგ კი ამ ოთხ პარამეტრს.

რატომ ეკუთვნის სესიები გაზიარებულ საცავს#

სესია სამ ადგილას შეიძლება ცხოვრობდეს, და თითოეული სადღაც სწორია.

cookie-ს ვარიანტი არასაკმარისად ფასდება. თუ მთელი სესია მომხმარებლის id და CSRF token-ია, ხელმოწერილ cookie-ს სერვერის მდგომარეობა საერთოდ არ სჭირდება. ის კარგი იდეა აღარ არის, როცა სესია იზრდება - cookie-ები დაახლოებით 4 KB-ით შემოიფარგლება, ყოველ მოთხოვნასთან ერთად მოგზაურობს, სურათების მოთხოვნების ჩათვლით, და სერვერის მხრიდან მათი გაუქმება შეუძლებელია. "ყველა მოწყობილობიდან გამოსვლა" სუფთა cookie სესიებით შეუძლებელია, რადგან სერვერზე წასაშლელი არაფერია.

ბაზის ცხრილი მუშაობს, და რამდენიმე ასეულ აქტიურ მომხმარებელზე ყველაფერი რიგზეა. ფასი არის ჩანაწერი ყოველ მოთხოვნაზე, რომელიც სესიას ეხება, და ვადაგასული სტრიქონების გასაწმენდი ამოცანა. Valkey იგივეს აკეთებს ჩაშენებული ვადით: თითოეული სესია ერთი გასაღებია TTL-ით, და სერვერი მას შლის, როცა TTL იწურება. არც garbage collection ამოცანა, არც ფონზე მზარდი ცხრილი.

სანაცვლოდ დამოკიდებულებას იღებ. თუ Valkey მიუწვდომელია, ვერავინ შედის. აპლიკაციების უმეტესობისთვის ეს სწორი გაცვლაა, რადგან Valkey დაახლოებით ყველაზე მარტივი სერვისია, რაც არსებობს, მაგრამ ამის ცოდნა ღირს - და სწორედ ამიტომაა მნიშვნელოვანი კავშირის timeout-ები, რომლებიც ამ პოსტში მოგვიანებით იქნება.

კავშირის მონაცემები, რომლებიც ყველა ფრეიმვორკს სჭირდება#

ქვემოთ მოცემულ ყველა მაგალითს ერთი და იგივე ოთხი მნიშვნელობა სჭირდება: ჰოსტი, პორტი, პაროლი და, სურვილისამებრ, ბაზის ნომერი. ბიბლიოთეკების უმეტესობა მათ ერთი URL-ის სახით იღებს:

redis://:a-long-generated-password@203.0.113.20:6380/0redis://default:a-long-generated-password@203.0.113.20:6380/0

სქემა რჩება redis:// - კლიენტის ბიბლიოთეკებმა არ იციან და არც აინტერესებთ, რომ სერვერი Valkey-ა. ცარიელი მომხმარებლის სახელი ორწერტილის წინ ნიშნავს "ნაგულისხმევ მომხმარებელს", და სწორედ ასე ელოდება ავთენტიფიკაციას სერვერი, რომელიც მხოლოდ requirepass-ით არის დაცული. default-ის მკაფიოდ დაწერა იგივეს აკეთებს კლიენტებთან, რომლებსაც ACL მომხმარებლის სახელების მხარდაჭერა აქვთ. ბოლო რიცხვი ლოგიკურ ბაზას ირჩევს; 0 ნაგულისხმევია.

ეს URL გარემოს ცვლადში ჩადე, არასოდეს რეპოზიტორიაში. გარემოს ცვლადები და საიდუმლოები ფარავს, სად უნდა ცხოვრობდეს ის ყოველი ტიპის ჰოსტზე. სანამ ფრეიმვორკს მიუერთებ, დაამტკიცე, რომ მონაცემები მუშაობს იმ მანქანიდან, რომელიც მათ გამოიყენებს:

$ valkey-cli -h 203.0.113.20 -p 6380 --askpassPlease input password: ****203.0.113.20:6380> PINGPONG

redis-cli იდენტურად მუშაობს, თუ შენს სისტემაზე ის არის. თუ PING აქ ვერ ხერხდება, ფრეიმვორკის ვერანაირი კონფიგურაცია ამას ვერ გაასწორებს - Valkey-ს დაწყება გადის კავშირის შეცდომებს და იმას, რას ნიშნავს თითოეული.

RE:NODE-ზე Valkey გეგმას მოყვება ჰოსტი, პორტი და ამ სერვერისთვის გენერირებული პაროლი, და ის დისკზე ინახავს როგორც AOF-ით, ისე snapshot-ებით, ამიტომ restart მას არ აცარიელებს. ბაზების გეგმებზე proxy slot არ არის: შენი აპლიკაცია პირდაპირ ჰოსტსა და პორტს უკავშირდება, რაც ზუსტად ისაა, რაც სესიების ბიბლიოთეკას სჭირდება.

Express და Node.js#

express-session cookie-სა და სესიის ობიექტს მართავს; connect-redis არის საცავი. connect-redis-ის მიმდინარე ვერსიები სახელიან RedisStore კლასს აექსპორტებენ და ელიან დაკავშირებულ კლიენტს redis პაკეტიდან (node-redis).

$ npm install express-session connect-redis redis

import session from "express-session";import { RedisStore } from "connect-redis";import { createClient } from "redis";const client = createClient({ url: process.env.VALKEY_URL });client.on("error", (err) => console.error("valkey", err));await client.connect();export const sessions = session({  store: new RedisStore({ client, prefix: "shop:sess:" }),  secret: process.env.SESSION_SECRET,  name: "sid",  resave: false,  saveUninitialized: false,  cookie: { httpOnly: true, secure: true, sameSite: "lax", maxAge: 1000 * 60 * 60 * 24 * 7 },});

თითოეული ხაზი კონკრეტულ რამეს აკეთებს:

• `prefix` გასაღებებს სახელთა სივრცეს აძლევს. მის გარეშე ყველა აპი, რომელიც ერთსა და იმავე Valkey-ზეა მიმართული, sess:-ს იყენებს და ისინი ერთმანეთის სესიებს კითხულობენ. ყოველ აპლიკაციას საკუთარი მიეცი.
• `resave: false` აჩერებს ჩანაწერს ყოველ მოთხოვნაზე, როცა არაფერი შეცვლილა. მის ნაცვლად საცავის touch მეთოდი TTL-ს ანახლებს.
• `saveUninitialized: false` ნიშნავს, რომ ვიზიტორი, რომელიც არასოდეს შედის, გასაღებს არ ქმნის. დატოვე true და ყოველი crawler, bot და health check სესიას ქმნის - სწორედ ასე აღწევს სესიების საცავი მილიონ გასაღებს საიტზე ორმოცი მომხმარებლით.
• `maxAge` cookie-ს სიცოცხლის ხანგრძლივობას აყენებს, და connect-redis მას გასაღების TTL-ად იყენებს, ამიტომ ეს ორი ერთმანეთს ვერ დაშორდება.
• `secure: true` cookie-ს მხოლოდ HTTPS-ით აგზავნის. reverse proxy-ის უკან, რომელიც TLS-ს წყვეტს, Express ხედავს უბრალო HTTP-ს და secure cookie-ს დაყენებაზე უარს ამბობს, თუ არ დაამატებ app.set("trust proxy", 1). ეს ერთი გამოტოვებული ხაზი ყველაზე გავრცელებული ხარვეზია "სესიები production-ში არ ჩერდება". Express API-ის deploy proxy-ის დანარჩენ კონფიგურაციას ფარავს.

თუ ძველ კოდზე მუშაობ, დაინახავ const RedisStore = require("connect-redis")(session). ეს factory ფორმა ძველ მთავარ ვერსიებს ეკუთვნის; import-ის სტილი შენს package.json-ში არსებულ ვერსიას მოარგე.

Django#

Django 4.0 და უფრო ახალი ვერსიები Redis cache backend-ით მოდის, ამიტომ redis კლიენტის ბიბლიოთეკის გარდა მესამე მხარის პაკეტი არ გჭირდება. სესიები შემდეგ ქეშს იყენებს.

$ pip install "redis>=5" hiredis

import osCACHES = {    "default": {        "BACKEND": "django.core.cache.backends.redis.RedisCache",        "LOCATION": os.environ["VALKEY_URL"],        "KEY_PREFIX": "shop",        "TIMEOUT": 300,    }}SESSION_ENGINE = "django.contrib.sessions.backends.cache"SESSION_CACHE_ALIAS = "default"SESSION_COOKIE_AGE = 60 * 60 * 24 * 14SESSION_COOKIE_SECURE = TrueCSRF_COOKIE_SECURE = True

Django ქეშზე დაფუძნებულ ორ ძრავს გთავაზობს, და არჩევანს მნიშვნელობა აქვს:

• `backends.cache` სესიას მხოლოდ ქეშში ინახავს. ყველაზე სწრაფია, და სესია ქრება, თუ გასაღები განიდევნა ან სერვერმა ის დაკარგა.
• `backends.cached_db` ბაზაშიც წერს და ქეშიდან კითხულობს. სესიის ყოველი ჩანაწერი ბაზაში ჩანაწერი ჯდება, მაგრამ დაკარგული ქეშის გასაღები ცხრილიდან აღდგება, ნაცვლად იმისა, რომ მომხმარებელი გამოაგდოს.

მუდმივი Valkey-სა და გონივრული eviction პოლიტიკის პირობებში ჩვეულებრივი არჩევანი backends.cache-ა. თუ შენი სესიები ატარებს რამეს, რისი დაკარგვაც ძვირია - ვთქვათ, ნახევრად დასრულებულ checkout-ს - cached_db ფრთხილი არჩევანია. სესიის TTL მოდის SESSION_COOKIE_AGE-დან და არა ქეშის TIMEOUT-დან, ამიტომ ქეშის მოკლე timeout სესიებს არ ამოკლებს.

proxy-ის უკან დააყენე SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https") მხოლოდ მაშინ, თუ proxy ამ header-ს ნამდვილად აყენებს; Django-ს deploy production-ში სრულ სიას შეიცავს.

Laravel#

Laravel Valkey-ს თავისი redis driver-ით ესაუბრება, ნაგულისხმევად phpredis გაფართოებით, ან სუფთა PHP-ზე დაწერილი Predis პაკეტით, თუ გაფართოება არ არის. ყველაფერი .env-შია:

SESSION_DRIVER=redisSESSION_CONNECTION=defaultSESSION_LIFETIME=120REDIS_CLIENT=phpredisREDIS_HOST=203.0.113.20REDIS_PORT=6380REDIS_PASSWORD=a-long-generated-passwordREDIS_DB=0REDIS_CACHE_DB=1

ჯერ შეამოწმე php -m | grep redis. თუ გაფართოება ჩატვირთული არ არის, ან დააყენე, ან გაუშვი composer require predis/predis და დააყენე REDIS_CLIENT=predis. Predis უფრო ნელია, მაგრამ არაფრის კომპილაციას არ საჭიროებს.

SESSION_LIFETIME წუთებშია. Laravel ყოველ გასაღებს პრეფიქსს უმატებს REDIS_PREFIX-ით, რომლის ნაგულისხმევი მნიშვნელობა APP_NAME-ის slug-ია - ამიტომ ორი Laravel აპი ერთი და იმავე APP_NAME-ით ერთ Valkey-ზე სესიის გასაღებებს გაიზიარებს. დააყენე REDIS_PREFIX მკაფიოდ, ან ყოველ აპს სხვა APP_NAME მიეცი.

REDIS_DB-სა და REDIS_CACHE_DB-ს გაყოფა მნიშვნელოვანი ხაზია. Laravel ქეშსა და სესიებს სხვადასხვა ლოგიკურ ბაზაში დებს, რომ php artisan cache:clear-მა, რომელიც ქეშის ბაზას ასუფთავებს, ყველა არ გამოაგდოს. თუ მათ ერთ ნომერში გააერთიანებ, ქეშის რუტინული გასუფთავება მასობრივ გამოსვლად იქცევა. .env-ის შეცვლის შემდეგ გაუშვი php artisan config:clear, ან php artisan config:cache, თუ production-ში კონფიგურაციას ქეშავ - Laravel-ის deploy production-ში ხსნის, რატომ იჭერს ეს ნაბიჯი ხალხს.

სუფთა PHP phpredis-ით#

ფრეიმვორკის გარეშე PHP-ის საკუთარი სესიების დამუშავება შეიძლება Valkey-ზე მიმართო php.ini-ის ორი ხაზით, თუ phpredis გაფართოება დაყენებულია:

session.save_handler = redissession.save_path = "tcp://203.0.113.20:6380?auth=a-long-generated-password&database=2&prefix=shop_sess:"session.gc_maxlifetime = 7200redis.session.locking_enabled = 1redis.session.lock_expire = 30redis.session.lock_wait_time = 50000redis.session.lock_retries = 100

session_start() და $_SESSION შემდეგ ზუსტად ისე მუშაობს, როგორც ადრე. session.gc_maxlifetime გასაღების TTL ხდება და ახლდება ყოველ მოთხოვნაზე, რომელიც სესიაში წერს. სადაც php.ini-ის რედაქტირება არ შეგიძლია, იგივე ორი პარამეტრი შეიძლება დააყენო ini_set()-ით session_start()-მდე.

locking ცალკე აბზაცს იმსახურებს, რადგან ეს ერთადერთი ნამდვილი განსხვავებაა ფაილურ სესიებთან შედარებით. PHP-ის ფაილური handler სესიის ფაილს მთელი მოთხოვნის განმავლობაში ბლოკავს, ამიტომ ერთი მომხმარებლის ორი ერთდროული მოთხოვნა ერთმანეთის მიყოლებით სრულდება. phpredis handler ნაგულისხმევად არ ბლოკავს: ორი პარალელური AJAX გამოძახება თითოეული კითხულობს სესიას, თითოეული ცვლის მას, და მეორე ჩანაწერი ჩუმად გადაწერს პირველს. redis.session.locking_enabled = 1 ფაილური handler-ის ქცევას აბრუნებს. ფასი ისაა, რომ ნელი მოთხოვნა იმავე მომხმარებლის სხვა მოთხოვნებს ბლოკავს, რასაც ფაილური სესიებიც აკეთებდა - და ჩვევა, რომელიც უნდა ისწავლო, არის session_write_close()-ის გამოძახება, როგორც კი სკრიპტი სესიაში წერას დაასრულებს.

ASP.NET Core#

ASP.NET Core-ის session middleware მონაცემებს ინახავს იმ IDistributedCache-ში, რომელიც დარეგისტრირებულია. Redis-ის იმპლემენტაცია ცხოვრობს Microsoft.Extensions.Caching.StackExchangeRedis-ში:

$ dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis

builder.Services.AddStackExchangeRedisCache(options =>{    options.Configuration = builder.Configuration["Valkey:Configuration"];    options.InstanceName = "shop:";});builder.Services.AddSession(options =>{    options.IdleTimeout = TimeSpan.FromMinutes(30);    options.Cookie.HttpOnly = true;    options.Cookie.IsEssential = true;    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;});var app = builder.Build();app.UseSession();

კონფიგურაციის სტრიქონი StackExchange.Redis-ის სინტაქსშია და არა URL: 203.0.113.20:6380,password=...,abortConnect=false. abortConnect=false აპს აძლევს საშუალებას, გაეშვას და ცდა გააგრძელოს, თუ Valkey მცირე ხნით მიუწვდომელია, ნაცვლად იმისა, რომ გაშვებისას ჩავარდეს. InstanceName გასაღების პრეფიქსია.

აქ ორი რამ აბრკოლებს .NET დეველოპერებს. პირველი, ASP.NET Core-ის session ავთენტიფიკაცია არ არის: შესვლის cookie, რომელსაც cookie authentication ან Identity გასცემს, თვითკმარი და დაშიფრულია, და სესიაში საერთოდ არ ცხოვრობს. მეორე, ეს დაშიფვრა Data Protection გასაღებებს იყენებს, რომლებიც ნაგულისხმევად ყოველი ინსტანციის ლოკალურ დისკზე ინახება. გაუშვი ორი ინსტანცია, ან კონტეინერს ხელახლა გაუკეთე deploy, და მომხმარებლები გამოვარდებიან, რადგან ახალი პროცესი ძველ cookie-ს ვერ შიფრავს. გამოსავალი გასაღებების ნაკრების ცენტრალურად შენახვაა, და Valkey ამისთვის ბუნებრივი ადგილია Microsoft.AspNetCore.DataProtection.StackExchangeRedis-ით და PersistKeysToStackExchangeRedis(connection, "DataProtection-Keys")-ით. ASP.NET Core-ის ავთენტიფიკაციის საფუძვლები ამას უფრო დეტალურად განიხილავს.

TTL-ები, eviction და შენახვა: პარამეტრები, რომლებიც წყვეტს, დარჩებიან თუ არა მომხმარებლები შესული#

ზემოთ ყოველი ბიბლიოთეკა სესიის ყოველ გასაღებს TTL-ს უყენებს. სწორედ ეს ხდის Valkey-ს კარგ სესიების საცავად, და სწორედ ამიტომ აქვს სერვერის მხარის ორ პარამეტრს უფრო მეტი მნიშვნელობა, ვიდრე ნებისმიერ კოდს.

eviction პოლიტიკა. როცა Valkey მეხსიერების ლიმიტს აღწევს, maxmemory-policy წყვეტს, რა მოხდება. noeviction-ით ჩანაწერები მეხსიერების ამოწურვის შეცდომით ვარდება: ახალი შესვლები ხმაურით ფუჭდება, არსებული სესიები გადარჩება. allkeys-lru-ით ყველაზე დიდი ხნის გამოუყენებელი გასაღებები იშლება ადგილის გასათავისუფლებლად: ყველაფერი აგრძელებს მუშაობას, და მომხმარებლები, რომლებიც ყველაზე დიდხანს უმოქმედოდ იყვნენ, ჩუმად გამოვარდებიან. volatile-lru-ით ან volatile-ttl-ით კანდიდატები მხოლოდ ის გასაღებებია, რომლებსაც TTL აქვთ - და რადგან ყოველ სესიას აქვს, სწორედ სესიები განიდევნება.

Valkey-სთვის, რომელიც მხოლოდ სესიებს ინახავს, noeviction საკმარისი მეხსიერებით პატიოსანი არჩევანია: იმას, რომ უფრო დიდი გეგმა გჭირდება, შეცდომიდან იგებ და არა მომხმარებლების საჩივრიდან, რომ სულ გამოდიან. თუ იგივე ინსტანცია ქეშსაც ინახავს, ან გაყავი ისინი (მეორე პატარა ინსტანცია იაფია), ან მიიღე, რომ სესიები მეხსიერებისთვის ქეშის ჩანაწერებს ეჯიბრება. Valkey-ს მეხსიერება და eviction პოლიტიკები სრულ ცხრილს შეიცავს.

შეამოწმე, რა გაქვს:

$ valkey-cli -h 203.0.113.20 -p 6380 --askpass CONFIG GET maxmemory-policy$ valkey-cli -h 203.0.113.20 -p 6380 --askpass INFO memory

თუ მართულ ინსტანციაზე CONFIG უარყოფილია, INFO memory მაინც აჩვენებს maxmemory-სა და maxmemory_policy-ს.

შენახვა. სესიების საცავი, რომელიც restart-ზე შიგთავსს კარგავს, ყოველ restart-ზე ყველა მომხმარებელს აგდებს. append-only ფაილით appendfsync everysec-ზე მკაცრი გაჩერება სესიის ჩანაწერების მაქსიმუმ დაახლოებით ერთ წამს კარგავს, რასაც პრაქტიკაში ვერავინ ამჩნევს. Valkey-ს შენახვა: AOF და RDB ხსნის ორ მექანიზმს და რა ღირს თითოეული.

ზომა. ტიპური სესია - მომხმარებლის id, CSRF token, flash შეტყობინება და ცოტა ფრეიმვორკის აღრიცხვა - რამდენიმე ასეული ბაიტიდან რამდენიმე კილობაიტამდეა, პლუს თითო გასაღების ზედნადები. ათი ათასი აქტიური სესია 2 KB-ად დაახლოებით 20 MB-ია. 256 MB გეგმა გაცილებით მეტ სესიას იტევს, ვიდრე საიტების უმეტესობას ოდესმე ექნება; რაც სესიების საცავს სინამდვილეში ავსებს, არის ან saveUninitialized-ის სტილის ანონიმური სესიები, ან აპლიკაციები, რომლებიც სესიაში მთელ ობიექტებს ტენიან - საყიდლების კალათას პროდუქტის მონაცემებით, მომხმარებლის ჩანაწერს უფლებებით - id-ის ნაცვლად. სესიები პატარა შეინახე და დანარჩენი მოძებნე.

გამოცნობის ნაცვლად ნამდვილი რიცხვების ნახვა შეგიძლია:

$ valkey-cli --askpass -h 203.0.113.20 -p 6380 --scan --pattern 'shop:sess:*' | head -3$ valkey-cli --askpass -h 203.0.113.20 -p 6380 MEMORY USAGE shop:sess:Xk2v...$ valkey-cli --askpass -h 203.0.113.20 -p 6380 TTL shop:sess:Xk2v...

გამოიყენე --scan და არასოდეს KEYS ყველაფერზე, რაც ტრაფიკს ემსახურება: KEYS მთელ გასაღებთა სივრცეს ერთი ბლოკირებადი გამოძახებით გადის.

პრობლემების მოგვარება#

მომხმარებლები ყოველი deploy-ის შემდეგ გამოდიან. ან საცავი პროცესის შიდაა (კონფიგურაცია არასოდეს ამოქმედდა - შეამოწმე, ნამდვილად ჩატვირთა თუ არა აპმა Valkey საცავი), ან სესიის საიდუმლო შეიცვალა (Express-ის secret, Laravel-ის APP_KEY, Django-ს SECRET_KEY ან .NET-ის Data Protection გასაღებები), ან Valkey შენახვის გარეშე გადაიტვირთა.

სესიები production-ში საერთოდ არ ჩერდება. secure cookie კავშირზე, რომელიც აპს HTTP ჰგონია. დააკონფიგურირე ფრეიმვორკის trust-proxy პარამეტრი, რომ X-Forwarded-Proto წაიკითხოს. გახსენი ბრაუზერის დეველოპერის ინსტრუმენტები და შეამოწმე, მოდის თუ არა Set-Cookie header და ინახება თუ არა cookie.

შემთხვევითი გამოსვლები დატვირთვისას. eviction. შეხედე evicted_keys-ს INFO stats-ში; თუ იზრდება, სესიები ადგილის გასათავისუფლებლად იშლება. გაზარდე მეხსიერება, ქეში სხვაგან გადაიტანე, ან გადადი noeviction-ზე.

`NOAUTH Authentication required` ან `WRONGPASS`. პაროლი URL-ში აკლია ან არასწორია. პაროლში სპეციალური სიმბოლოები URL-ის შიგნით percent-encoding-ით უნდა იყოს - @ ან / პაროლში პარსინგს ამტვრევს.

ერთი მომხმარებლის მოთხოვნები ნელია, ერთმანეთის მიყოლებით. სესიის locking. PHP-ში სესია ადრე გაათავისუფლე session_write_close()-ით, ან ხანგრძლივი სამუშაო გაიტანე მოთხოვნებიდან, რომლებიც სესიას იჭერენ.

ორი აპი ერთმანეთის სესიებს ხედავს. ერთი პრეფიქსი, ერთი ბაზა. თითოეულს განსხვავებული პრეფიქსი მიეცი.

FAQ#

შემიძლია ერთი Valkey ინსტანცია სესიებისა და ქეშისთვის გამოვიყენო?

კი, თუ მათ პრეფიქსით ან ლოგიკური ბაზით გაყოფ და მიიღებ, რომ მეხსიერებას იზიარებენ. რისკი არის ქეში, რომელიც იმდენად იზრდება, რომ eviction სესიების წაშლას იწყებს. პატარა საიტზე მეტისთვის ორი პატარა ინსტანცია უფრო სუფთაა, ვიდრე ერთი დიდი პოლიტიკით, რომელიც ორივე საქმეს უნდა მოერგოს.

რა ემართება სესიებს, თუ Valkey გაითიშა?

ახალი მოთხოვნები სესიებს ვერ ტვირთავს, ამიტომ მომხმარებლები გამოსულად ჩანან ან შეცდომებს იღებენ, იმის მიხედვით, როგორ ამუშავებს ბიბლიოთეკა წარუმატებელ კავშირს. როცა Valkey ჩართული შენახვით ბრუნდება, მის მიერ შენახული სესიები ისევ იქ არის. დააყენე გონივრული კავშირის timeout-ები, რომ არარსებული Valkey სწრაფად ჩავარდეს და ყოველი მოთხოვნა არ გაჭედოს.

უსაფრთხოა სესიაში პერსონალური მონაცემების შენახვა?

შეინახე რაც შეიძლება ცოტა: id, რომელსაც ეძებ, და არა თვითონ ჩანაწერი. სესიის შიგთავსს Valkey-ში არცერთი ეს ბიბლიოთეკა დისკზე არ შიფრავს, და ნებისმიერს, ვისაც პაროლი აქვს, მისი წაკითხვა შეუძლია. Valkey-ს პაროლს ისე მოეპყარი, როგორც ბაზის პაროლს.

რამდენ ხანს უნდა გრძელდებოდეს სესია?

იმდენად მოკლედ, რამდენსაც შენი მომხმარებლები აიტანენ. ორი საათი უმოქმედობისას ადმინისტრატორის ზონისთვის, ორი კვირა სამომხმარებლო საიტისთვის "დამიმახსოვრე" ველით. გასაღების TTL cookie-ს სიცოცხლის ხანგრძლივობის ტოლი უნდა იყოს; ზემოთ ყოველი ბიბლიოთეკა ამ ორს აკავშირებს, თუ cookie-ს ასაკს დააყენებ და საცავის საკუთარ TTL ოფციას ხელს არ ახლებ.

მჭირდება sticky სესიები load balancer-ზე, თუ Valkey-ს ვიყენებ?

არა. გაზიარებული საცავის აზრიც ესაა: ნებისმიერ პროცესს ნებისმიერი მოთხოვნის მომსახურება შეუძლია. sticky სესიები პროცესის შიდა სესიის მდგომარეობის გვერდის ავლის გზაა, და ისინი ზედმეტი ხდება, როგორც კი სესიები Valkey-ში გადადის.