5 از موارد کارگزاران پیام استفاده کنید. چه زمانی باید در مورد اتخاذ یک کارگزار پیام در سیستم خود در نظر بگیرید؟

  • 2022-02-9

برنامه های مدرن پیچیده تر و پیچیده تر می شوند. عملیات زمان و مصرف منابع ، ارتباط بین چندین سرویس ، پردازش داده های زیادی-این تنها چند مورد از بسیاری از مشکلات است که توسعه دهندگان باید با آن روبرو شوند. خوشبختانه راه حل هایی وجود دارد که می تواند برخی از این چالش ها را ساده کند. یکی از آنها استفاده از کارگزار پیام است.

کارگزار پیام چیست؟✉

یک کارگزار پیام یک قطعه نرم افزار است که خدمات و برنامه ها را قادر می سازد با استفاده از پیام با یکدیگر ارتباط برقرار کنند. ساختار پیام به طور رسمی تعریف شده و مستقل از خدماتی است که آنها را ارسال می کند.

این به برنامه ها اجازه می دهد تا اطلاعات را با یکدیگر به اشتراک بگذارند ، حتی اگر آنها به زبان های مختلف برنامه نویسی نوشته شده باشند!

باحال به نظر می رسد ، درست است؟

کارگزاران پیام چگونه کار می کنند؟🤔

قبل از شروع کار ، می توانیم برخی از مفاهیم اساسی یک کارگزار پیام را بدست آوریم:

  • تولید کننده - برنامه مسئول ارسال پیام. این با کارگزار پیام مرتبط است. در الگوی انتشار/اشتراک (ما به آن حرکت خواهیم کرد) آنها را ناشران خوانده می شوند.
  • مصرف کننده - نقطه پایانی که پیامهایی را که در کارگزار پیام انتظار دارند مصرف می کند. در الگوی انتشار/اشتراک آنها مشترکان نامیده می شوند.
  • صف/موضوع - پوشه ای در سیستم فایل. کارگزار پیام از آنها برای ذخیره پیام استفاده می کند.

دو الگوی توزیع رایج

پیام به نقطه به نقطه

در این الگوی ، رابطه یک به یک بین فرستنده و گیرنده پیام وجود دارد. هر پیام فقط یک بار ارسال و مصرف می شود. ما می توانیم به عنوان مثال از این الگوی استفاده کنیم ، هنگامی که برخی از اقدامات فقط یک بار انجام می شود.

اکنون احتمالاً فکر می کنید: "خوب ، پس تفاوت بین این و برخی از API استراحت چیست؟"وادجواب ساده است. کارگزار پیام تضمین می کند که در صورت عدم موفقیت مصرف کننده ، پیام از بین نمی رود. با خیال راحت در صف کارگزار پیام ذخیره می شود. ما بعداً در مقاله به آن و سایر مزایای کارگزار پیام خواهیم رفت.

message broker example

انتشار/مشترک شدن

این الگوی کمی متفاوت از مدل قبلی است. در اینجا ، فرستنده پیام چیزی در مورد گیرنده ها نمی داند. پیام به موضوع ارسال می شود. پس از آن ، بین تمام نقاط پایانی مشترک در آن موضوع توزیع می شود. این می تواند مفید باشد به عنوان مثالبرای اجرای مکانیسم اعلان ها یا توزیع کارهای مستقل. این راه حل همچنین می تواند منجر به اجرای یک سیستم مبتنی بر معماری مبتنی بر رویداد شود ، که در آن برنامه ها وابستگی کمتری بین یکدیگر دارند.

در این الگوی ، مؤلفه ها به راحتی همراه هستند و وقایع را به یکدیگر منتقل می کنند. این رویدادها پیام هایی هستند که به کارگزار پیام ارسال می شوند.

message broker distribution

البته تغییرات بیشتری در این الگوهای وجود دارد. شما می توانید چندین مصرف کننده را به یک صف متصل کنید. یا می توانید معیارهای بازیابی فقط انواع مطلوب پیام ها را مشخص کنید.

مزایای استفاده از کارگزار پیام چیست؟📈

  • برقراری ارتباط بین خدماتی که ممکن است همزمان اجرا نشوند. تولید کننده می تواند بدون توجه به اینکه مصرف کننده فعال است یا خیر ، پیام ارسال کند. تنها چیزی که نیاز دارد یک کارگزار پیام در حال اجرا است. همین مورد در مورد مصرف کننده نیز صدق می کند.
  • عملکرد سیستم را با معرفی پردازش ناهمزمان بهبود بخشید. کارهای پر مصرف را می توان در فرآیندهای جداگانه توزیع کرد. این باعث می شود برنامه شما را ببندد و تجربه کاربر را افزایش دهد.
  • افزایش قابلیت اطمینان با تضمین انتقال پیام ها. کارگزاران پیام یک مکانیسم مجدد ارائه می دهند. در صورت خرابی مصرف کننده ، می تواند پیام را بلافاصله یا بعد از زمان مشخص شده دوباره تغییر دهد. همچنین از مسیریابی پیام های تحویل داده نشده پشتیبانی می کند-این مکانیزم نامه مرده نامیده می شود.

مضرات استفاده از کارگزار پیام چیست؟📉

استفاده از کارگزار پیام شامل پردازش ناهمزمان است. بنابراین ، مضرات استفاده از آن مربوط به چالش هایی است که ما با استفاده از تماس های ناهمزمان با آن روبرو هستیم.

  • افزایش پیچیدگی سیستم. معرفی یک کارگزار پیام در سیستم شما یک عنصر جدید برای کل معماری سیستم شماست. به همین دلیل ، موارد بیشتری وجود دارد که شما باید در نظر بگیرید ، مانند حفظ شبکه بین مؤلفه ها یا مسائل امنیتی. علاوه بر این ، یک مشکل جدید مربوط به سازگاری نهایی است. برخی از مؤلفه ها تا زمان انتشار و پردازش پیام ها نمی توانند داده های به روز داشته باشند.
  • اشکال زدایی می تواند سخت تر باشد. بیایید بگوییم که شما چندین مرحله از پردازش یک درخواست واحد با استفاده از کارگزار پیام دارید. شما چیزی ارسال می کنید اما اعلان دریافت نکردید. جستجوی علت عدم موفقیت می تواند یک چالش باشد زیرا هر سرویس سیاهههای مربوط به خود را دارد. به خاطر داشته باشید تا در کنار سیستم های پیاده سازی با استفاده از کارگزار پیام ، برخی از امکانات ردیابی پیام را اضافه کنید.
  • در ابتدا یک منحنی یادگیری شیب دار وجود دارد. کارگزاران پیام به عنوان صدای آنها بی اهمیت نیستند. آنها گزینه های تنظیم و پیکربندی زیادی دارند. اندازه صف ها و پیام ها ، رفتار صف ها ، تنظیمات تحویل یا پیام های TTL ، تنها چند مورد از گزینه های بسیاری است که می توانید تنظیم کنید.

چه زمانی باید از کارگزاران پیام استفاده کنید؟

1. کارهای طولانی مدت و API مهم

بگذارید مثالی از تجربه شخصی خود برای شما تعریف کنم. چندی پیش مجبور شدم عملکرد مکانیسم مسئول صادرات داده را بهبود بخشیدم. این توسط درخواست HTTP آغاز شد و زمان زیادی را می برد. علاوه بر این ، کاربران پس از انجام اقدامات ، نمی توانند از برنامه استفاده کنند زیرا منتظر نتیجه صادرات بودند.

همانطور که احتمالاً حدس زده اید ، کارگزار پیام به نجات رسید.

من فقط منطق درخواست را برای ارسال پیام به کارگزار کاهش دادم. صادرات داده ها به عهده مصرف کننده ای بودند که به صورت ناهمزمان اجرا می شد. نتیجه بسیار رضایت بخش بود ، زیرا ما به یک درخواست غیر مسدود کننده رسیدیم. زمان آن از بیش از ده ثانیه به چند ده میلی ثانیه کاهش یافته است! کاربر پس از دریافت اطلاع رسانی در مورد موفقیت توانست فایل را بارگیری کند.

  • زمان و منابع مصرف کننده هستند
  • نیازی به شما نیست که بلافاصله نتیجه عمل را برگردانید

message brokers usage

2. میکروسرویس 🖥 ↔ 🖥

سیستم های بزرگ می توانند از بسیاری از خدمات جداگانه تشکیل شوند. هماهنگی ارتباط بین آنها می تواند چالش برانگیز باشد. راه حلی که در ابتدا ارائه می شود ، ایجاد ادغام با استفاده از API REST است. با این حال ، با افزایش تعداد خدمات در سیستم ، گسترش و حفظ آن می تواند دشوار باشد. علاوه بر این ، اگر یکی از برنامه های شما پایین بیاید و در دسترس نباشد ، چه می شود؟API شروع به بازگشت خطاهای مهم خواهد کرد.

یک گزینه عالی برای ایجاد ارتباطات مبتنی بر رویداد و استفاده از کارگزار پیام به همراه الگوی انتشار/اشتراک است. کارگزار به عنوان یک روتر مرکزی کار می کند. هر سرویس می تواند در انواع پیام های مورد نیاز خود مشترک شود.

این راه حل مزایای زیادی دارد. اگر می خواهید یک برنامه جدید اضافه کنید ، نیازی به گسترش خدمات موجود خود ندارید. اگر برخی از سرویس ها پایین بیایند - آنها پس از راه اندازی مجدد پیام ها را مصرف می کنند.

message broker microservices

3. برنامه های تلفن همراه

این یک مورد استفاده عالی برای کارگزار پیام است. چرا؟از آنجا که تقریباً هر برنامه تلفن همراه دارای اعلان های فشار است. بیایید تصور کنیم که شما در حال تهیه یک برنامه خبری هستید. هر تلفن متصل به شبکه می تواند در موضوع کارگزار پیام مشترک باشد. هر وقت برخی از redactor برخی اخبار را ارسال می کنند - شما در حال دریافت اعلان هستید. بسیار ساده ، اینطور نیست؟

4- سیستم های معامله ای

این کمی با سناریوهای کار طولانی و میکروسرویس ارتباط برقرار می کند ، اما لازم به ذکر است. بعضی اوقات لازم است برخی از اقدامات را به ترتیب خاص انجام دهید.

بیایید بگوییم که شما یک سیستم مانند یوتیوب ایجاد می کنید و می خواهید مکانیسمی برای انتشار یک فیلم جدید داشته باشید. اول ، شما در حال بارگذاری فیلم هستید. پس از آن ، باید اعتبار سنجی ، فشرده سازی شود ، برخی از تصاویر کوچک باید تولید شود. سرانجام ، می توان آن را علنی کرد. هر عملی پس از اتمام کار قبلی باید انجام شود.

برای دستیابی به آن می توانید از کارگزار پیام استفاده کنید. بیایید فرض کنیم که شما خدمات جداگانه ای برای اعتبار سنجی ، فشرده سازی و غیره دارید. هر سرویس می تواند در همان زمان نقش فرستنده و گیرنده را داشته باشد. پس از مصرف کار خود می تواند پیامی را به کارگزار ارسال کند که کار به پایان رسیده است. پس از آن ، سرویس بعدی می تواند فیلم را به دست بگیرد.

message broker systems

5- کنترل فیدهای داده 👮‍♂

اگر می خواهید تعداد برخی از نهادهای موجود در سیستم خود را کنترل و محدود کنید ، می تواند مفید باشد. یکی از ساده ترین سناریوها ، کنترل حد کاربران ثبت شده است. البته می توانید این کار را بدون کارگزار پیام انجام دهید - به عنوان مثال با قفل کردن جداول روی لایه پایگاه داده برای جلوگیری از خطر مسابقه. با کارگزار پیام ساده تر است - شما فقط می توانید پس از هر درخواست ثبت نام ، یک پیام منتشر کنید. مصرف کننده پیام ها را یکی یکی می گیرد. با رسیدن به حد کاربران-می تواند برخی از خطا را برگرداند یا یک ایمیل را به کاربر ثبت نشده ارسال کند.

نمونه هایی از کارگزاران پیام

محبوب ترین کارگزاران پیام RabbitMQ ، Apache Kafka ، Redis ، Amazon SQS و Amazon SNS هستند. هر یک از آنها ابزاری عالی و قدرتمند برای استفاده است. برای برخی از موارد اساسی و بار کم ، تفاوت بین آنها را نمی بینید. با این حال ، وقتی صحبت از مقیاس عملیاتی گسترده و موارد پیشرفته می شود - آنها متفاوت عمل می کنند. ارزش این را دارد که بدانید تفاوت های اصلی چیست.

خرگوش

از گزینه های مسیریابی پیشرفته و پیچیده پشتیبانی می کند. این چهار نوع صرافی را فراهم می کند - این بخشی از کارگزاری است که پیام ها را به صف های مناسب هدایت می کند. بنابراین در مورد RabbitMQ پیام‌ها ابتدا به صرافی‌ها ارسال می‌شوند - نه به صف.

AmazonMQ

نسخه ابری جایگزین RabbitMQ و Apache ActiveMQ ارائه شده توسط خدمات وب آمازون. با مدیریت راه اندازی و نگهداری یک کارگزار پیام برای شما، مسئولیت های عملیاتی شما را کاهش می دهد.

آپاچی کافکا

در ابتدا برای پیگیری فعالیت های وب سایت ایجاد شد. اینها به حجم عظیمی از داده ها برای مدت زمان طولانی نیاز داشتند. و این چیزی است که کافکا در آن خوب است. حتی می توان از آن برای پخش داده ها به سیستم های ذخیره سازی استفاده کرد.

ردیس

همچنین می توان از آن به عنوان واسطه پیام استفاده کرد. این یک ذخیره ساز ساختار داده در حافظه است. به همین دلیل، پیام ها در آنجا تضمین نمی شوند که دوام داشته باشند. اگر سیستمی دارید که به یک کارگزار بسیار سریع نیاز دارد، اما می‌توانید به خودتان اجازه دهید تا داده‌ها را از دست بدهید - می‌تواند انتخاب خوبی باشد.

آمازون SNS

یک سرویس اطلاع رسانی فشار ارائه شده توسط آمازون. می توان از آن در الگوی انتشار-اشتراک و همچنین برای ارسال پیام های فردی استفاده کرد. همانطور که نمونه های قبلی منبع باز بودند - Amazon SNS اینطور نیست. به عنوان بخشی از خدمات وب آمازون در دسترس است. یکی از مزیت های اصلی آن زیرساخت کم هزینه است. همچنین به طور خودکار حجم کاری را در برنامه شما افزایش می دهد.

آمازون SQS

یک سرویس کاملاً مدیریت شده در صف ارائه شده توسط آمازون. همانطور که در مورد Amazon SNS - این بخشی از AWS است. همچنین می توان آن را به طور خودکار به اندازه حجم کار تغییر داد. علاوه بر این - یک ردیف رایگان برای تعداد محدودی صف پیام ارائه می دهد و بسیار مقرون به صرفه است. تفاوت در نحوه کار با Amazon SNS در روش مصرف پیام است. SNS دارای مکانیزم فشار است و پیام‌ها را بدون ذخیره‌سازی مستقیم به مصرف‌کنندگان می‌فرستد. آمازون SQS به نوبه خود دارای مکانیزم کششی است - گیرنده ها باید پیام ها را از صف های SQS به تنهایی بیرون بکشند.

آیا نمی دانید که آیا سیستم شما از کارگزار پیام سود می برد؟🤷

یا شاید شما قبلاً آن را می دانید، اما مطمئن نیستید که از کدام کارگزاری باید استفاده کنید؟مشاوره نرم افزاری رایگان و غیر الزام آور را برنامه ریزی کنید و بیایید در مورد فناوری صحبت کنیم!

چگونه یک کارگزار پیام ساده را با استفاده از خدمات AWS پیاده سازی کنیم؟☁️

message broker meme

بله، می‌توانید قدرت انتشار SNS آمازون را به چندین گیرنده با صف‌های بادوام Amazon SQS ترکیب کنید!

در این مثال، من به شما نشان خواهم داد که چگونه یک واسطه پیام ساده با الگوی انتشار-اشتراک با استفاده از AWS SDK برای PHP ایجاد کنید. البته، می‌توانید این کار را بدون SDK انجام دهید – تمام اقداماتی که ما انجام خواهیم داد، می‌توانید تنها با استفاده از کنسول AWS خود انجام دهید. وقت آن است که مقداری گوشت تکنولوژیکی!

نمای کلی معماری

message broker architecture

چگونه کار خواهد کرد؟

به طور خلاصه - ناشر پیام هایی را به موضوع Amazon SNS ارسال می کند. موضوع تکرار می شود و پیام دریافتی را برای همه مشترکین خود ارسال می کند. در مورد ما - این مشترکین صف های آمازون SQS خواهند بود. هر صف با مشترکی که پیام ها را بیرون می کشد متصل می شود. برای سادگی، ناشر و مشترکین ما اسکریپت های ساده PHP خواهند بود.

این راه حل تضمین می کند که پیام ها را می توان به برنامه هایی که نیاز به اطلاع رسانی فوری برای برخی رویدادها دارند، تحویل داد. آنها همچنین به لطف صف ها پایدار هستند و می توانند در آنجا منتظر بمانند تا برخی از مصرف کنندگان در دسترس باشند.

قبل از شروع کدنویسی، شما نیاز دارید:

  • یک حساب AWS با دسترسی برنامه‌ای
  • برخی از پروژه های PHP که در آن می توانید AWS SDK را نصب کنید

مرحله 1: یک موضوع SNS ایجاد کنید

ابتدا باید یک موضوع SNS با استفاده از SnsClient ایجاد کنید. برای برقراری ارتباط با سرویس AWS شما به مقداری داده نیاز دارد:

  • منطقه ای که می خواهید موضوع SNS خود را در آن داشته باشید
  • نسخه تعیین می کند که کدام عملیات API برای مشتری در دسترس است
  • اعتبارنامه - کلید دسترسی مخفی AWS و شناسه کلید دسترسی AWS شما

در کد بالا، اعتبارنامه ها را به عنوان آرگومان در سازنده به حساب AWS منتقل کردم. به یاد داشته باشید که این فقط برای اهداف نمونه است! رمزگذاری سخت اعتبارنامه ها در برنامه شما می تواند خطرناک باشد. شما می توانید بیشتر در مورد این در اینجا بخوانید .

اکنون می توانید موضوع SNS خود را ایجاد کنید. نامی برای موضوع خود در نظر بگیرید و تابع createTopic SnsClient را فعال کنید. در نتیجه این عملیات، یک شی Aws\Result با اطلاعاتی درباره موضوع جدید ایجاد شده خود دریافت خواهید کرد. شما می توانید داده های واحد را با استفاده از تابع get در شیء نتیجه بازیابی کنید. یک ویژگی TopicArn را ذخیره کنید - بعداً به آن نیاز خواهید داشت.

مرحله 2: ایجاد صف

ایجاد یک صف بسیار شبیه به ایجاد موضوع است. به جای SnsClient و تابع createTopic از تابع SqsClient و createQueue استفاده کنید. برای مراحل بعدی، به URL و ویژگی ARN صف تازه ایجاد شده نیاز دارید. شما می توانید به تعداد دلخواه صف ایجاد کنید - بعداً آنها را به موضوع متصل خواهیم کرد.

مرحله 3: یک خط مشی به صف اضافه کنید

اکنون باید به موضوع ما اجازه دهید پیام هایی را به صف های تازه ایجاد شده خود ارسال کند. AWS از سیاست هایی برای مدیریت مجوزها استفاده می کند. اینها در قالب JSON نشان داده شده اند. برای ایجاد خط مشی خود به موضوع و صف آرن نیاز دارید. آنها به طور منحصر به فرد منابع AWS شما را شناسایی می کنند. شما باید این سیاست را با استفاده از SQSClient و SetqueUeatTributesFunction ، به صف SQS (نه موضوع SNS) منتقل کنید. برای اینکه به کدام صف نیاز داشته باشید که خط مشی اضافه شود ، باید پارامتر صف را تنظیم کنید.

تنظیم این سیاست قابل رد نیست. اگر صف های مربوط به موضوع را مشترک کنید و موضوع برای ارسال پیام اجازه ای نداشته باشید - صف های شما پس از انتشار پیام ها خالی خواهد ماند.

مرحله 4: مشترک شدن در صف

پس از تنظیم خط مشی می توانید صف های خود را در موضوع مشترک کنید. شما باید از Snsclient در اینجا استفاده کنید و عملکرد مشترک آن با تنظیم اشتراک نیاز به انتخاب پروتکل دارد - این نوعی نقطه پایانی است که می خواهید پیام دریافت کنید. آمازون SNS از جمله موارد دیگر از پیامک ، ایمیل یا حتی عملکرد AWS Lambda پشتیبانی می کند. در مورد ما ، این پروتکل SQS خواهد بود ، زیرا ما در حال عضویت در صف هستیم. به عنوان یک نقطه پایانی ، شما باید صف خود را عبور دهید. برای موضوع - همانطور که نام یک استدلال می گوید - موضوع خود را تصویب کنید تا مشتری بداند که کدام موضوع را می خواهید در یک نقطه پایانی جدید مشترک کنید. اگر می خواهید اشتراک ARN را در نتیجه مشاهده کنید - پارامتر ReturnsubScriptionarn را به درست تنظیم کنید.

مرحله 5: انتشار پیام

تنظیم معماری شما کامل است و می توانید به سمت انتشار پیام بروید. خیلی ساده است. تمام کاری که شما باید انجام دهید این است که یک پیام تهیه کنید و با استفاده از Snsclient و عملکرد انتشار آن ارسال کنید. شما باید موضوع ARN را که در آن منتشر می کنید ، عبور دهید و محتوای پیام را ارسال کنید. گزینه های بسیار بیشتری وجود دارد که می توانید قبل از انتشار پیام مانند موضوع ، ویژگی ها و غیره تنظیم کنید ، اما لازم نیست.

پس از اجرای اسکریپت ، برای دیدن صف های خود به پانل AWS خود دسترسی پیدا کنید. می توانید توجه داشته باشید که یک پیام در بین تمام صف های شما مشترک در موضوع شما تکرار شده است.

message broker queues

مرحله ششم: دریافت پیام

اکنون ، هنگامی که پیام های خود را در صف دارید ، می توانید شروع به دریافت آنها کنید. برای این کار ، دوباره از sqsclient استفاده کنید و عملکرد دریافت کننده را با آن تماس بگیرید. تنها پارامتر مورد نیاز صف است. همچنین می توانید چند پیام را که می خواهید بیرون بکشید تنظیم کنید (پارامتر MaxNumberOfMessages) و کدام ویژگی هایی را که می خواهید دریافت کنید. برای هر پیام برگشت ، پاسخ شامل چندین پارامتر است که از این تعداد بیشتر به محتوای پیام و دسته رسید علاقه دارید.

پس از تماس با تابع ReceiveMessage ، هدف AWS \ نتیجه را دریافت خواهید کرد. پیام های شما در پشت کلید پیام ها به عنوان یک آرایه ذخیره می شوند. به یاد داشته باشید که در صورت عدم پیام در صف ، می تواند یک آرایه خالی باشد. هر پیام یک آرایه انجمنی است و باید کم و بیش در تصویر ارائه شده در زیر به نظر برسد. می توانید محتوای پیام را در زیر ویژگی پیام مشاهده کنید ، همچنین تأیید دریافت خود را در زیر ویژگی RecepThandle مشاهده کنید.

message broker receiving messages

هر پیام پس از دریافت آن باید از صف حذف شود. به این دلیل است که AWS پیام حذف نشده را به عنوان دریافت ناکام شمرده می شود. بسته به پیکربندی صف ، می توان آن را مجدداً مجدداً جابجا کرد یا به صف مرده منتقل کرد. برای حذف یک پیام ، باید با عملکرد DeletEmessage تماس بگیرید و ویژگی دریافت شده را با پیام دریافت کنید.

کارگزاران پیام چندان سخت نیستند!

همانطور که مشاهده می کنید ، کارگزاران پیام وقتی می خواهید معماری سیستم خود را بهبود ببخشید ، مفید هستند. امروز آموخته اید:

  • کارگزاران پیام چگونه کار می کنند ،
  • مزایای اصلی و هنگامی که توصیه می شود از آنها استفاده کنید.
  • نحوه اجرای چنین کارگزار پیام توسط خودتان با استفاده از خدمات AWS.

اگر می خواهید در مورد AWS SDK برای PHP اطلاعات بیشتری کسب کنید و تمام گزینه های پیکربندی را ببینید - در اینجا پیوندی به اسناد رسمی وجود دارد. همچنین بسته های اختصاصی برای Symfony و Laravel وجود دارد که شامل SDK است.

ثبت دیدگاه

مجموع دیدگاهها : 0در انتظار بررسی : 0انتشار یافته : ۰
قوانین ارسال دیدگاه
  • دیدگاه های ارسال شده توسط شما، پس از تایید توسط تیم مدیریت در وب منتشر خواهد شد.
  • پیام هایی که حاوی تهمت یا افترا باشد منتشر نخواهد شد.
  • پیام هایی که به غیر از زبان فارسی یا غیر مرتبط باشد منتشر نخواهد شد.