اگه این متن رو داری میخونی، حتما می‌دونی ردیس (redis) چیه و باهاش آشنایی..
اینجا راجع به ردیس نمی‌خوام بنویسم؛ می‌خوام از یه الگوی ارتباطی که ردیس ازش پشتیابی میکنه بنویسم.
اسم این الگو پاب سابه!
مثالی که خیلیا درمورد نحوه ی کارکرد این الگوی ارتباطی میزنن، شبیه سازوکاری هست که توی تلگرام میبینیم؛ یه کانال، که فقط اون هایی که داخلش عضون میتونن پیام هاشو ببینن..
خب، تقریبا همینه توی پاب/ساب ردیس، با این تفاوت که وقتی شروع میکنی به گوش دادن یا به عبارتی، سابسکرایب میکنی، پیام ها رو دریافت میکنی و وقتی ارتباطت قطع بشه یا آنسابسکرایب کنی، دیگه پیامی دریافت نمیکنی..
چجوری کار میکنه؟
بیا توی تصویر ببنیم چه شکلیه!
نمای کلی پاب/ساب
پابلیشر(Publisher): یه کلاینت یه پیام روی یه کانال میفرسته.
سابسکرایبر(Subscriber): یه کلاینت به یک یا چند کانال سابسکرایب میکنه
ردیس(Redis): ردیس این وسط پیام ها رو از پابلیشر ها میگیره و به همه ی سابسکرایبر های یک کانال ارسالش میکنه.
در حالت کلی، Pub/Sub یه الگوی ارتباطه که خیلی سبکه و asynchronous عه! معمولا هم برای برنامه های real time استفاده و پیاده سازی میشه.
فواید
مقیاس پذیری: این یه الگوی مقیاس پذیره و چندین پابلیشر و سابسکرایبر میتونن از طریق ردیس با هم در ارتباط باشن
سرعت: پیام ها تو این روش خیلی سریع جابجا میشن(ردیس سریعه 😎)
سادگی: به راحتی قابل پیاده سازیه!
آسینک(Asynchronous): پیام ها بصورت آسینک دریافت و ارسال میشن و کلایت ها رو بلاک نمیکنن!
مثال هایی از موارد استفاده
نوتیفیکیشن درلحظه
اپلیکشین های چت
معماری Event-Driven: پابلیشر ها میتونن یه ایونت به سابسکرایبر ها بفرستن که این میتونه موجب انجام یه اکشن یا عمل بشه
محدودیت های پاب/ساب
ذخیره نشدن: پیام ها توی پاب ساب، ذخیره نمیشن و ردیس صرفا نقش واسط جابجایی رو این بین داره و جایی اونا رو نگه نمیداره!
ترتیب نداشتن: تو پاب ساب، تضمینی وجود نداره که پیام ها به همون ترتیبی که فرستاده شدن، دریافت بشن!
تصدیق!(acknowledgment): تو پاب ساب، تصدیق پیام نداریم به این معنی که تضمینی وجود نداره که پیام شما بعد از ارسال دریافت بشه!
تو این متن کوتاه سعی شد با الگوی پاب ساب یه آشنایی کلی داشته باشیم.
توی نوشته ی بعدی باهم خواهیم دید چطوری میتونیم با استفاده از این الگو، به کاربر نهایی، تو یه معماری میکروسرویس، امکان ارتباط وبسوکت بدیم.
