فناوری و زیرساخت → Redis: در حافظه راه حل

Redis: راه حل های در حافظه

1) جایی که ردیس مناسب است

• کش (خواندن از طریق/کنار، TTL، SWR) و جلسات.
• شمارنده ها و سهمیه ها: محدود کردن نرخ، ضد تقلب، محدودیت های مبارزات انتخاباتی.
• مدیران/رتبه بندی (ZSet)، توصیه های «بالا N».
• صف های رویداد/اتوبوس (جریان/PubSub)، صندوق ورودی/صندوق ورودی، retrays.
• Idempotence (کلید با TTL)، de-dup webhooks.
• Geo (جستجوی نزدیکترین نقاط)، Bitmap (پرچم ها، DAU).
• نام های مستعار/نشانه ها و حافظه های مجوز کوتاه مدت.

مهم: برای موجودی نقدی و متغیرهای بحرانی، Redis فقط به عنوان یک شتاب دهنده خواندن یا یک مجله/حافظه پنهان با «منبع حقیقت» در DBMS/Ledger استفاده می شود.

2) ساختار داده ها و زمانی که آنها را اعمال کنید

رشته: مقادیر/شمارنده ('INCRBY')، کلید های idempotent.
Hash: aggregates of profiles/configs، ذخیره سازی اشیاء «سبک».
فهرست: صفهای ساده (اما بدون معناشناسی بازپخش/افست).
مجموعه: عناصر منحصر به فرد، تقسیم بندی.
ZSet: مرتب سازی بر اساس سرعت (تابلوهای راهنما، تقویم TTL - رویدادهای «معوق»).
جریان: صف های پایدار با گروه های مصرف کننده، 'XREADGROUP '/replay - برای webhooks، CDC، retrays.
Geo: 'GEOADD/GEORADIUS' - نزدیکترین نقاط/بازرگانان.
بیت مپ/بیت فیلد: مجموعه ای از پرچم ها (ورود به روز، DAU/WAU).
HyperLogLog: تقریبا منحصر به فرد (UU) در حافظه ارزان است.
بلوم/فاخته (ماژول): چک در دسترس بودن سریع، کاهش «خانم» به منبع.

• RedisJSON (اسناد JSON)، RediSearch (نمایه سازی/جستجو)، RedisBloom (ساختارهای احتمالی)، TimeSeries (metrics/aggregations).

3) کلید، TTL و سیاست های حافظه

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

نسخه ('vN')، فقط شامل ابعاد معنی دار (منطقه/ارز/زبان/مستاجر).
فضاهای کلیدی هر مستاجر را جدا کنید.

• استفاده از یک ماتریس TTL (ثانیه/دقیقه/ساعت)، اضافه کردن لرزش (± 10-20٪) برای جلوگیری از stampede.
• برای کلید های داغ - تازه کردن پیش رو و تک پرواز (به روز رسانی یک رهبر).

• "allkeys-lru/lfu 'is a shared cache without TTL dependency.
• 'volatile-lru/lfu' - فقط کلیدهای دارای TTL.
• «توضیحات» - نوشتن خرابی در سرریز (امن تر برای صف های بحرانی/شمارنده).
• برای اسکریپت انتخاب کنید و همیشه «کلید های اخراج شده» را نظارت کنید.

4) معاملات، خطوط لوله و اسکریپت

خطوط لوله: کاهش RTT، گروه 10-100 تیم.
معاملات (MULTI/EXEC) - خواندن را جدا نکنید، اما دسته ای را به صورت اتمی اجرا کنید.
قفل بهینه: «کلید WATCH» → MULTI/EXEC → بررسی کنید.
اسکریپت های Lua: منطق اتمی در سمت سرور (محدودیت نرخ، قفل، عملیات کامپوزیت).

5) صف و اتوبوس: لیست در مقابل جریان

لیست + 'BRPOP' - ساده، اما بدون گروه های مصرف کننده، افست/پخش، مقاومت ضعیف در برابر قطره.
جریان: «XADD → XREADGROUP → XACK»، نامه مجدد (در N دقیقه گرفته نشده است)، پارتیشن بندی شده توسط کلید. توصیه می شود برای PSP/KYC webhooks, پرداخت معوق/اطلاعیه ها.

صف های اولویت: چندین جریان با اولویت، مصرف کنندگان «مکیدن» از بالا در وهله اول.
وظایف معوق: ZSet که در آن نمره = برچسب زمان ؛ اکنون «ZRANGEBYSCORE» به استریم منتقل شده ≤.

6) در دسترس بودن و مقیاس پذیری بالا

تکرار: master → ماکت (مقیاس خواندن).
Sentinel: استاد اتوماتیک شکست، کشف، URI مشتری.
Redis خوشه: 16384 اسلات sharding، افقی مقیاس کردن. قرار دادن کلیدهایی که از ساختارهای چندگانه در برچسب های هش «{order: 123}» استفاده می کنند.

• برای کش/جلسات - خوشه/ماکت، 'سمت سرویس گیرنده هش' SDK پشتیبانی می شود.
• برای صف/جریان - به حداقل رساندن عملیات شکاف متقاطع; پارتیشن توسط کلید های دامنه.

7) پایداری: RDB، AOF و پشتیبان گیری

RDB (عکس های فوری): سریع تر، مقرون به صرفه تر ؛ خطر از دست دادن آخرین ثانیه/دقیقه.
AOF (مجله): تلفات کمتر ؛ 'everysec/always' حالت. فشرده سازی AOF و بسته بندی دوره ای.
ترکیبی: RDB + AOF → بهبود سریع + تلفات متوسط.
پشتیبان گیری: عکس های فوری و کپی از AOF برای ذخیره سازی شیء ؛ بهبودی را به طور مرتب بررسی کنید.

برای صف های بحرانی/idempotency، AOF 'everysec' + replication را انتخاب کنید.

8) ایمنی و انطباق

AUTH/ACL: نقش ها در هر برنامه، ممنوعیت دستورات «خطرناک» («FLUSHALL»، «KEYS»).
TLS به مشتری-سرور و لینک های بین گره ؛ خروجی ثابت IP.
تقسیم بندی شبکه: زیر شبکه های خصوصی، SG/NACL ؛ دسترسی فقط از خدمات مورد نیاز/فضاهای نام.
اسرار را پنهان نکنید PAN/PII در Redis - فقط نشانه ها/مشتقات.
دستورات کلیدی: اجتناب از «KEYS» - استفاده از «SCAN».

9) قابلیت مشاهده و SLO

• Latency (P95/P99), 'instanant _ ops _ per _ sec', 'connected _ clients'.
• نسبت ضربه، evicted_keys، expired_keys
• حافظه: استفاده شده، نسبت تقسیم بندی، RSS، آمار تخصیص دهنده.
• تاخیر تکرار، فرکانس ها و اندازه های AOF/RDB، زمان چنگال.
• جریان ها: PEL (لیست ورودی های در انتظار)، تاخیر تحویل، تعداد مجدد.

• عملیات Redis P99 ≤ 5-10 ms.
• تخلیه ≤ 1 ٪/ساعت (فضای کش).
• تحویل جریان P99 ≤ 500 мс، نرخ تکرار <2٪.

10) FinOps و برنامه ریزی منابع

حافظه گران است: اندازه گیری $/GB ماه RAM در مقابل صرفه جویی در درخواست به مبدا/DB.
فعالسازی فشردهسازی مقدار> 1-2 KB (CPU را ببینید).
LFU می تواند با حجم کمتری ضربه بزند.
برای تصاویر/حباب های بزرگ - Redis نیست: استفاده از CDN + ذخیره سازی شی.

11) الگوهای برای iGaming/fintech

11. 1 محدود کردن نرخ (Lua)

ایده: 'INCRBY' در کلید پنجره + TTL ؛ Lua به صورت اتمی محدودیت و افزایش را بررسی می کند.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 درخواست idempointence

کلید 'idemp: {request _ id}' با TTL 24h، مقدار - نتیجه/وضعیت. قبل از انجام عملیات، ما برای حضور بررسی می کنیم.

11. 3 مدیران

'ZINCRBY رهبر: بازی: {g} کاربر نمره: {u} →' ZREVRANGE... بدون چشم داشت.
برای N بالا بر اساس منطقه/مستاجر - ZSet فردی یا پیشوند.

11. 4 PSP Webhooks صف

'PSP XADD: webhooks... → گروه مصرف کننده 'XGROUP CREATE psp: webhooks g1 $'.
Retrays of «گیر» messages via PEL scanning ('XPENDING' → 'XCLAIM').

11. 5 پرداخت های معوق

ZSet 'payout: due' (score = epoch) → کارگر به صورت دوره ای موارد تمام شده را به Stream 'payout: exec' با deduplication منتقل می کند.

11. 6 متر ضد انفجار

ترکیبی از 'PFADD' (منحصر به فرد) + 'INCR' (شدت) + برچسب های جغرافیایی/ASN ؛ عوامل برای اعتبار دستی.

12) کار با حافظه و عملکرد

استخر اتصال مشتری ؛ RTT (نگه داشتن زنده) را کاهش دهید.
ترجیح خطوط لوله به یک بسته از دستورات.
به دنبال کلیدهای بزرگ باشید («MEMORY USAGE», «SCAN») - بهتر است اشیاء را تقسیم کنید.
هش با تعداد کمی از زمینه ها مقرون به صرفه تر از بسیاری از کلید های فردی است.
فعال کردن موضوعات io (خواندن سنگین) اگر سود توسط آزمون تایید شده است.
اجتناب از «FLUSHDB/ALL» مکرر در تولید ؛ مدیریت از طریق پیشوندها و 'UNLINK' برای حذف امن.

13) چند مستاجر و انزوا

خوشه های فردی/نمونه ها یا DB منطقی برای هر مستاجر (اگر بار کوچک است).
سهمیه های کلیدی/حافظه، ACL های تقسیم شده.
پیشوندها در کلیدها و معیارها بر پایه فضای نام.

14) قفل کردن و سازگاری

کلید تنظیم val NX PX = ttl - mutex ساده.
Redlock: با دقت استفاده کنید برای معاملات مهم توزیع شده، بهتر است به «منبع حقیقت» (DB/ledger) و عملیات idempointent تکیه کنید.
ترجیح می دهم عملیات اتمی و Lua به جای «طولانی» قفل.

15) ضد الگوهای

ذخیره سازی حباب های بزرگ/تصاویر - اضافه بار RAM و شبکه.
ناورداهای مالی (ترازنامه) فقط در ردیس.
«کلید» و «اسکن جهان» در نوک.
بدون TTL/jitter - dogpile در انقضا.
سیاست «allkeys» در صف های بحرانی → از دست دادن داده ها در فشار.
مخلوط کردن صف، کش و جلسات در یک مورد بدون سهمیه و اولویت.
اسکریپت های Lua که روی کلیدهای اسلات های مختلف در Cluster کار می کنند.

16) چک لیست پیاده سازی

1. تعریف نقش: کش/جلسات، صف/جریان، شمارنده/محدودیت - ارسال به نمونه/خوشه.

2. سیاست maxmemory را برای کار انتخاب کنید ؛ تعیین محدودیتها و نظارت بر اخراجها

3. نامگذاری کلیدی، نسخه های مدار، ماتریس TTL + لرزش ؛ تک پرواز برای کلید های بالا.
4. برای صف - جریان (گروه, retrays, DLQ), برای معوق - ZSet + انتقال.
5. HA: تکرار + سنتینل یا خوشه ردیس ؛ چک کن مشتري شکست خورده.
6. پایداری: RDB/AOF تحت اسکریپت ؛ پشتیبان گیری منظم و تست بازیابی.
7. امنیت: ACL، TLS، شبکه های خصوصی، ممنوعیت دستورات خطرناک.
8. قابلیت مشاهده: تاخیر، ops/sec، حافظه، اخراج، تاخیر تکرار، PEL جریان.
9. FinOps: پروفایل های حافظه، کلید های بزرگ، فشرده سازی، LFU ؛ اجتناب از Redis برای حباب های بزرگ.
10. مستندات الگو (محدودیت نرخ، idemotency، leadboards) و تست بار.

نتیجه گیری

Redis یک «چاقوی سوئیس چند منظوره» سرعت است: کش، صف، شمارنده، رهبران، جغرافیایی و ساختارهای احتمالی. قدرت آن در انتخاب صحیح ساختار داده ها، نظم و انضباط TTL/ناتوانی، اتمی بودن عملیات، و HA/پایداری خوب و قابلیت مشاهده است. از Redis استفاده کنید که در آن میلی ثانیه و RPS بالا مهم هستند، در حالی که باقی مانده های بحرانی (پول، حسابداری) به «منبع حقیقت» - به این ترتیب پلت فرم هر دو سریع و قابل اعتماد باقی خواهد ماند.