Redis: როდის გჭირდება და როგორ გაუშვა თვითონ

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

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

რა არის Redis სინამდვილეში#

არა ქეში. ქეში ერთ-ერთი რამაა, რისი აგებაც მისით შეიძლება. Redis არის მეხსიერებაში მომუშავე მონაცემთა სტრუქტურების სერვერი: ინახავს შენს მონაცემებს RAM-ში, სურვილისამებრ დისკზე წერს ასლს და TCP პორტზე 6379 მცირე ტექსტურ პროტოკოლზე ლაპარაკობს. ბრძანებები ტიპიზებულ სტრუქტურებზე მუშაობს და არა გაუგებარ ბლობებზე, და აქედან მოდის მისი სარგებლიანობა.

ბრძანებების შესრულება ერთ thread-ზეა. ამიტომ ყოველი ბრძანება ატომურია შენი ჩარევის გარეშე, სწორედ ამიტომაა ის ასე კარგი მთვლელებსა და საკეტებში - და ამიტომაც ბლოკავს ერთი ნელი ბრძანება სერვერზე ყველაფერს. KEYS * მილიონ გასაღებზე ნელი მოთხოვნა კი არა, მოკლე გათიშვაა. ყოველთვის გამოიყენე SCAN.

მეორე თვისება, რომელიც მას განსაზღვრავს: ყველაფერი მეხსიერებაში ცხოვრობს. დისკი ასლია და არა საცავი. ეს არის როგორც სისწრაფის, ასევე რისკის წყარო, და ამიტომაა "შემიძლია ამის დაკარგვა?" პირველი კითხვა ყველაფერზე, რასაც მასში ჩადებ.

ოთხი საქმე, რომლისთვისაც ღირს დამატება#

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

ქეში იმისთვის, რაც ნამდვილად ძვირია. ძვირი ნიშნავს მოთხოვნას, რომელსაც ინდექსით ვერ აარიდებ, ანგარიშს, რომელიც მილიონ სტრიქონს აჯამებს, ან სხვისი API-ს გამოძახებას, რომელსაც ფულს უხდი. ნიმუში არის cache-aside: ჯერ ქეშში ეძებ, ხოლო miss-ზე მნიშვნელობას ითვლი და ინახავ TTL-ით, რომელზეც დაფიქრდი.

const key = `v1:report:${teamId}:${day}`;let report = await redis.get(key);if (!report) {  report = JSON.stringify(await buildReport(teamId, day));  await redis.set(key, report, "EX", 900);   // 15 minutes}

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

რიგი იმ სამუშაოსთვის, რომელიც მოთხოვნის დროს არ უნდა შესრულდეს. ელფოსტის გაგზავნა, სურათის ზომის შეცვლა, ნელი მესამე მხარის გამოძახება. მოთხოვნა წერს ამოცანას და ბრუნდება; worker პროცესი იღებს მას. BullMQ Node-ზე და Celery ან RQ Python-ზე ყველა Redis-ზე დგას და ყველა აკეთებს განმეორებას, დაყოვნებას და dead-letter დამუშავებას, რასაც სხვა შემთხვევაში ცუდად დაწერდი.

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

შეამჩნიე, რა არ არის ამ დიაგრამაში: არაფერი, რისი დაკარგვაც დაგწყენს. ჭეშმარიტებას მაინც ბაზა ფლობს.

მიზეზები, რომლებიც მიზეზები არ არის#

"ბაზა ნელია." ჯერ გაარკვიე, რატომ. გაუშვი მოთხოვნა EXPLAIN ANALYZE-ით, მოძებნე თანმიმდევრული scan დიდ ცხრილზე, დაამატე ინდექსი და ისევ გაზომე. ინდექსის გარეშე მოთხოვნის ქეშირება მას მალავს, სანამ ქეში ცივი არ გახდება - რაც ხდება deploy-ზე, restart-ზე ან სწორედ იმ მომენტში, როცა ტრაფიკი იმატებს და ყველა miss ერთდროულად მოდის. EXPLAIN ANALYZE-ის წაკითხვა ქეშის მართვაზე იაფი ნაშუადღევია.

"ყველა იყენებს." ყველას ასევე ერთზე მეტი სერვერი, მორიგეობის გრაფიკი და staging გარემო აქვს.

"უფრო სწრაფი იქნება." ლოკალური Redis-ის round trip წამის მეათედებია. ისევე, როგორც primary key-ით ძებნა PostgreSQL-ში თბილი ქეშის დროს. თუ შენი გვერდი 800 ms-ს ითხოვს, ბაზასთან round trip ის 800 ms არ არის.

"საბოლოოდ დაგვჭირდება." მოგვიანებით დამატებას ერთი ნაშუადღევი სჭირდება. ერთი წლის განმავლობაში იმის მართვა, რაც არ გჭირდებოდა, ერთ წელს სჭირდება.

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

რა გაქვს უკვე მის გარეშე#

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

• სესიები ერთ პროცესზე. პროცესის მეხსიერება სწორია და ყველაზე სწრაფი. რამდენიმე პროცესზე ხელმოწერილი cookie, რომელიც თვით სესიას ატარებს, სერვერის მდგომარეობას საერთოდ არ საჭიროებს, ხოლო ბაზაზე დაფუძნებული სესიების ცხრილი ათასობით მომხმარებელს შეუმჩნევლად უძლებს.
• ქეშირება გვერდის წინ. Cache-Control, ETag და სწორად დაკონფიგურირებული ვებ სერვერი მოთხოვნებს შენი აპლიკაციიდან საერთოდ შორს ინახავს, რაც უფრო სწრაფია, ვიდრე ნებისმიერი ქეში, რომელსაც შენი კოდი მიმართავს. HTTP ქეშირების header-ები ახსნილი მნიშვნელოვანს ფარავს.
• პროცესის შიდა ქეში. შეზღუდული LRU აპლიკაციის შიგნით - lru-cache Node-ზე, functools.lru_cache ან cachetools Python-ზე - არაფერი ღირს, ქსელურ გადახტომას არ საჭიროებს და სწორია ყველაფრისთვის, რაც პატარაა, ცხელია და მომხმარებლებს შორის ერთნაირია, მაგალითად კონფიგურაციისთვის ან საძიებო ცხრილისთვის. მისი შეზღუდვა ისაა, რომ ყველა პროცესს საკუთარი ასლი აქვს.
• რიგი PostgreSQL-ში. SELECT ... FOR UPDATE SKIP LOCKED გაძლევს სწორ, ტრანზაქციულ სამუშაო რიგს ცხრილში, და მას აქვს თვისება, რომელიც Redis-ს არა: ამოცანის რიგში ჩადება და მონაცემების commit, რამაც ის გამოიწვია, ერთ ტრანზაქციაში ხდება. წუთში რამდენიმე ასეულ ამოცანაზე ის სრულიად საკმარისია, ფონური ამოცანები პატარა სერვერზე კი ამას გადის.
• Rate limit-ები ვებ სერვერში. limit_req nginx-ში ლიმიტს შენს აპლიკაციამდე ახორციელებს და საცავს საერთოდ არ საჭიროებს.

-- A queue that needs no second serviceUPDATE jobs SET status = 'running', started_at = now()WHERE id = (  SELECT id FROM jobs  WHERE status = 'queued' AND run_after <= now()  ORDER BY run_after  FOR UPDATE SKIP LOCKED  LIMIT 1)RETURNING id, payload;

Redis-ის დაყენება VDS-ზე#

RE:NODE Redis-ს არ ყიდის: ბაზების ხაზი PostgreSQL-ია და MongoDB, ხოლო აპლიკაციის გეგმები შენი რეპოზიტორიიდან start ბრძანებას უშვებს და არა მეორე daemon-ს. ასე რომ Redis არის რაღაც, რასაც მანქანაზე უშვებ, სადაც root გაქვს, ე.ი. VDS-ზე ან dedicated სერვერზე. ეს დაქვეითება არ არის - ერთი Redis ინსტანცია ერთ-ერთი ყველაზე მარტივად სამართავი რამაა, და შენს მანქანაზე მას მხოლოდ loopback ინტერფეისზე შეუძლია მოსმენა, რაც მისი გაფუჭების გზების უმეტესობას აქრობს. სანაცვლოდ მთელ მანქანას იღებ საკუთარ თავზე: patch-ები, firewall, მონიტორინგი და backup-ები, რაც აწონილია პოსტში VDS-სა და გეიმ პანელს შორის არჩევანი.

Debian-ზე ან Ubuntu-ზე:

$ sudo apt update && sudo apt install redis-server$ sudo systemctl enable --now redis-server$ redis-cli pingPONG

დისტრიბუციის პაკეტი კონფიგურაციას /etc/redis/redis.conf-ში დებს, systemd-ით უშვებს redis მომხმარებლით და უკვე localhost-ზე აკავშირებს. თუ უფრო ახალი ვერსია გჭირდება, ვიდრე შენი დისტრიბუცია აწვდის, Redis-ის პროექტი საკუთარ apt და rpm რეპოზიტორიებს აქვეყნებს; მანქანაზე, რომელიც უკვე უშვებს კონტეინერებს, docker run სახელიანი volume-ით ისევე გონივრულია - იხილე Docker VDS-ზე.

პარამეტრები, რომლებიც პირველ დღეს ღირს შეცვალო, ყველა /etc/redis/redis.conf-შია:

bind 127.0.0.1 -::1protected-mode yesport 6379requirepass a-long-random-string-from-a-password-managermaxmemory 512mbmaxmemory-policy allkeys-lruappendonly yesappendfsync everysecsave 900 1save 300 10save 60 10000

შემდეგ ორი ბირთვის პარამეტრი, რომლებზეც Redis საკუთარ ლოგში დაიჩივლებს, თუ გამოტოვებ. Memory overcommit ჩართული უნდა იყოს, თორემ ფონურმა შენახვამ შეიძლება ჩაიშალოს მანქანაზე, სადაც თავისუფალი მეხსიერება ცოტაა; ხოლო transparent huge pages latency-ის ნახტომებს იწვევს.

$ echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-redis.conf$ sudo sysctl -p /etc/sysctl.d/99-redis.conf$ cat /sys/kernel/mm/transparent_hugepage/enabled

restart-ის შემდეგ შეამოწმე ლოგი journalctl -u redis-server-ით და გაასწორე ყველაფერი, რაზეც გაფრთხილებს, იმის ნაცვლად, რომ დატვირთვის დროს შეხვდე. ნებისმიერ ახალ მანქანაზე პირველ საათს უფრო ფართო ჩამონათვალი აქვს - განახლებები, არა-root მომხმარებელი, SSH გასაღებები, firewall - პირველი საათი ახალ VDS-ზე პოსტში, ხოლო შენი აპლიკაციის გვერდით ცოცხლად შენახვა systemd სერვისები შენი აპლიკაციებისთვის არის.

ერთი შენიშვნა სახელზე. Redis-მა 2024 წელს ლიცენზია შეცვალა, ამიტომ არსებობს Valkey როგორც Linux Foundation-ის ფორკი, ხოლო 2025 წელს ლიცენზირება ისევ შეიცვალა. ერთი self-hosted ინსტანციისთვის არაფერი ეს პრაქტიკულად არაფერს ცვლის: Valkey ერთსა და იმავე პორტზე იგივე პროტოკოლით, იგივე ბრძანებებითა და იგივე კონფიგურაციის ფაილით საუბრობს, და შენი კლიენტის ბიბლიოთეკა ვერც კი შეამჩნევს, რომელს დაუკავშირდა.

შენახვა: RDB, AOF და რისი დაკარგვა შეგიძლია#

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

RDB snapshot-ები მთელ მონაცემთა ნაკრებს ერთ ფაილში წერს ინტერვალებით, რომლებსაც ზემოთ მოცემული save ხაზები აკონტროლებს - "900 წამის შემდეგ, თუ ერთი გასაღები მაინც შეიცვალა" და ასე შემდეგ. snapshot პროცესის fork-ით მზადდება, ამიტომ CPU-ში იაფია და შესაძლოა მეხსიერებაში ძვირი: copy-on-write შვილობილს ყველაზე ცუდ შემთხვევაში თითქმის იმდენივე მეხსიერება შეიძლება დასჭირდეს კიდევ ერთხელ. აღდგენა სწრაფია და ფაილის სხვაგან გადაწერა მარტივია.

AOF, მხოლოდ დამატებადი ფაილი, ყოველ ჩამწერ ბრძანებას ჩაწერისთანავე ლოგავს და ლოგს გაშვებისას თავიდან უშვებს. appendfsync everysec ნაგულისხმევი და გონივრული პარამეტრია: მკაცრი გაჩერებისას ერთ წამამდე ჩანაწერის დაკარგვა შეგიძლია. always ყოველ ჩანაწერზე fsync-ს აკეთებს და გაცილებით ნელია. no ბირთვს უტოვებს გადაწყვეტილებას და ათეულობით წამის დაკარგვა შეუძლია.

გაუშვი ორივე. RDB გაძლევს კომპაქტურ ფაილს backup-ად წასაღებად; AOF გაძლევს გაცილებით მცირე დანაკარგის ფანჯარას. არცერთი Redis-ს ჩანაწერების სისტემად არ აქცევს: სუფთა გამორთვა ინახავს, ხოლო kill, დენის გაქრობა ან ბირთვის მიერ პროცესის მეხსიერების ამოწურვისას გაჩერება - არა. ეს იგივე არითმეტიკაა, რაც ნებისმიერ სხვა write-behind საცავზე - მონაცემი, რომელიც უნდა გადარჩეს, იქ უნდა იყოს, სადაც ტრანზაქციამ commit გააკეთა, ხოლო ასლები, რომლებიც უნდა გადარჩეს, მანქანის გარეთ უნდა იყოს, როგორც ბაზის backup-ები და აღდგენა უფრო ვრცლად ამტკიცებს.

მეხსიერება, maxmemory და eviction#

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

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

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

$ redis-cli info memory | grep -E 'used_memory_human|maxmemory_human'$ redis-cli info stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'$ redis-cli --bigkeys$ redis-cli --latency

hit ratio - hit-ები გაყოფილი hit-ებისა და miss-ების ჯამზე - არის რიცხვი, რომელიც გეუბნება, ღირს თუ არა ქეში თავის არსებობად. დაახლოებით 80 პროცენტს ქვემოთ რაღაც არასწორია შენს TTL-ებში ან გასაღებებში. მზარდი evicted_keys ნიშნავს, რომ maxmemory ძალიან დაბალია სამუშაო ნაკრებისთვის, და ეს ნამდვილი სიგნალია, CPU გრაფიკებისგან განსხვავებით. მონიტორინგი, რომელიც რამეს გეუბნება სწორედ ამ ტიპის რიცხვების არჩევას ეხება.

დაცვა და შეცდომა, რომლის გამოც სერვერები მაინინგზე მუშაობს#

ავთენტიფიკაციის გარეშე Redis, რომელიც ინტერნეტიდანაა ხელმისაწვდომი, გაჟონვა კი არა, shell-ია. ბრძანებათა ნაკრები მოიცავს სამუშაო დირექტორიისა და dump ფაილის სახელის შეცვლას, ამიტომ თავდამსხმელს შეუძლია თვითნებური ფაილი დაწეროს Redis-ის მომხმარებლით - კლასიკური ვერსია SSH გასაღებს authorized_keys-ში წერს და შედის. ავტომატური სკანერები ღია ინსტანციებს გამოჩენიდან რამდენიმე წუთში პოულობენ, და რასაც აყენებენ, ჩვეულებრივ მაინერია.

დაცვა მოკლეა და არჩევითი არ არის:

1. მიაბი localhost-ს, თუ სხვა მანქანაზე რაღაცას ის ნამდვილად არ სჭირდება. bind 127.0.0.1 -::1 პაკეტების უმეტესობაში ნაგულისხმევია; ხელს ნუ ახლებ. თუ სხვა ჰოსტმა უნდა დაუკავშირდეს, გამოიყენე კერძო ინტერფეისი ან SSH გვირაბი, არასოდეს საჯარო მისამართი.
2. დააყენე `requirepass` გრძელ შემთხვევით მნიშვნელობაზე და შეინახე შენი აპლიკაციის გარემოში და არა რეპოზიტორიაში - გარემოს ცვლადები და საიდუმლოები ფარავს, სად უნდა ცხოვრობდეს.
3. დახურე პორტი firewall-ზე. ნაგულისხმევად შემომავალი უარყოფილია, გახსენი მხოლოდ ის რამდენიმე პორტი, რომლის გამოქვეყნებაც გინდოდა, და 6379 მათ შორის არ არის. UFW firewall-ის სახელმძღვანელო წესებს შეიცავს.
4. გამოიყენე ACL მომხმარებლები ერთ აპლიკაციაზე მეტისთვის. Redis 6 და უფრო ახალი ვერსიები თითოეულ კლიენტს მომხმარებლის სახელს და შეზღუდულ ბრძანებათა ნაკრებს აძლევს, ამიტომ შენს ვებ აპს CONFIG-ის ან FLUSHALL-ის გამოძახება არ შეუძლია, კომპრომეტირებულიც რომ იყოს.
5. არასოდეს გამოაჩინო reverse proxy-ით. Redis საკუთარ პროტოკოლზე საუბრობს და არა HTTP-ზე, და ვებ სერვერის უკან მოთავსება მას უსაფრთხოს არ ხდის.

protected-mode yes-ის დატოვება სასარგებლო უკანა დაცვაა: პაროლისა და მკაფიო bind-ის გარეშე Redis კავშირებს loopback ინტერფეისის გარდა ყველგანიდან უარყოფს. ეს უსაფრთხოების ღვედია და არა სტრატეგია.

FAQ#

მჭირდება Redis პატარა ვებსაიტისთვის?

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

შეიძლება Redis ჩემი მთავარი ბაზა იყოს?

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

სად გავუშვა Redis, თუ ჩემი ჰოსტი მას არ ყიდის?

მანქანაზე, სადაც root გაქვს: VDS-ზე ან dedicated სერვერზე. დააყენე დისტრიბუციის პაკეტი, მიაბი localhost-ს, დააყენე პაროლი და maxmemory ლიმიტი და შენი აპლიკაცია loopback ინტერფეისით დააკავშირე. ეს ასევე ყველაზე უსაფრთხო ხელმისაწვდომი კონფიგურაციაა, რადგან პორტი საერთოდ არ იხსნება.

Redis თუ Valkey?

self-hosted ერთი ინსტანციისთვის - ორივე. Valkey არის Linux Foundation-ის ფორკი, შექმნილი 2024 წლის ლიცენზიის ცვლილების შემდეგ; ის იგივე პროტოკოლით საუბრობს, იგივე კონფიგურაციის ფაილს იყენებს და იგივე კლიენტებთან მუშაობს. აირჩიე რომელსაც შენი დისტრიბუცია აპაკეტებს და გააგრძელე.

რამდენი მეხსიერება მივცე?

საკმარისი სამუშაო ნაკრებისა და ზედნადებისთვის, და არა უმეტესი მანქანის დაახლოებით ნახევარზე, რადგან ფონური შენახვა პროცესს fork-ავს და ასლს ხანმოკლედ ბევრი დამატებითი მეხსიერება შეიძლება დასჭირდეს. დააყენე maxmemory მკაფიოდ, თვალი ადევნე evicted_keys-ს და გაზარდე, როცა ეს რიცხვი იზრდება.

რატომ ვარდება ჩემი ჩანაწერები მეხსიერების ამოწურვის შეცდომით?

იმიტომ, რომ maxmemory მიღწეულია და პოლიტიკა არაფერს აძევებს. ან პოლიტიკა noeviction-ია, ან ეს volatile-* პოლიტიკაა და შენს გასაღებებს TTL არ აქვს, რაც იგივეა. დააყენე TTL-ები, გადადი allkeys-lru-ზე ან გაზარდე ლიმიტი.