tnfy.link – یک کوتاه کننده دیگر؟

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

سلام، همه!

آغاز

این داستان با یک کار ساده شروع می‌شود: من باید پست‌هایی را ایجاد می‌کردم که حاوی پیوندی به سرویسی باشد که کنترلش نمی‌کردم و تعداد کلیک‌های روی آن پیوند را پیگیری کنم.

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

من همچنین با چندین پروژه منبع باز در GitHub مواجه شدم. اما بعد فکر کردم: من هم یک توسعه دهنده هستم. چرا کوتاه کننده URL خود را ایجاد نمی کنم – ساده، کاربردی و متناسب با نیازهای من؟

از چه چیزی استفاده کنم؟

با داشتن تجربه قبلی با Go and Fiber، انتخاب پشته وب من آسان بود. در ابتدا من آزمایش کردم آنها هستند، اما با محدودیت هایی مانند پشتیبانی محدود از روترهای فرعی مواجه شدم. از آنجایی که پروژه من فقط به چند نقطه پایانی REST نیاز داشت (جایی که Huma برتر است)، تصمیم گرفتم از فیبر خام استفاده کنم.

بعد مسئله ذخیره سازی مطرح شد – برای نقشه برداری پیوندهای کوتاه و بلند و ذخیره آمار. از آنجایی که من قصد نداشتم یک سرویس با ترافیک بالا داشته باشم، می‌توانم از هر راه‌حلی استفاده کنم: RDBMS، NoSQL یا ذخیره‌سازی با ارزش کلید.

من راه حل های خود میزبان را ترجیح می دهم، بنابراین SaaS مانند Firebase از جدول خارج شد. اگر این سری به شما علاقه مند است، من یک پست در مورد روند استقرار می نویسم.

من برای سادگی ارزش قائلم ذخیره‌سازی یک جفت پیوند کوتاه‌مدت مانند یک مورد استفاده «کلید-مقدار» به نظر می‌رسید، بنابراین من آن را انتخاب کردم ردیس.

برخی ممکن است فکر کنند من Redis را برای سرعت آن انتخاب کردم. تا حدی حق با شماست، اما نه کاملاً. بله، Redis سریع است زیرا همه چیز را در RAM ذخیره می کند و تغییر مسیرها در سرویس من کمتر از 1 میلی ثانیه طول می کشد. با این حال، درخواست‌های کاربران همچنان باید به سرور ارسال و از آن خارج شوند، که اغلب 50 تا 100 میلی‌ثانیه یا بیشتر به زمان پاسخ اضافه می‌کند. در بیشتر موارد، مزیت عملکرد Redis برای کاربران نهایی ناچیز است.

توجه: در حالی که زمان پاسخ بر تجربه کاربر تأثیر می گذارد، بر خود سرویس نیز تأثیر می گذارد. زمان پاسخ‌دهی سریع‌تر، مصرف منابع را کاهش می‌دهد و درخواست‌های بالاتر در ثانیه (RPS) را امکان‌پذیر می‌کند.

ذخیره سازی

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

از آنجایی که Redis را انتخاب کردم، گزینه های من به انواع داده های آن محدود شد. RAM محدود است، بنابراین تصمیم گرفتم یک TTL (زمان برای زندگی) 7 روزه برای پیوندها اضافه کنم، با انعطاف پذیری برای تنظیم بعد.

در ابتدا، ردیس رشته نوع ایده آل به نظر می رسید. کلیدهایی مانند links: می تواند URL های هدف را به عنوان مقادیر ذخیره کند. دستورات مانند SET با NX (برای جلوگیری از رونویسی) و EX (برای تنظیم TTL) یک راه حل ساده ارائه کرد.

با این حال، اگر بخواهم ابرداده های اضافی را در آینده ذخیره کنم، مانند تاریخ ایجاد یا شناسه کاربری، چه؟ من می توانم کلیدهای جداگانه ایجاد کنم (links::createdDate، links::userIdو غیره)، اما مدیریت TTL در چندین کلید، دست و پا گیر و مستعد خطا می شود.

خوشبختانه، ردیس هش نوع داده این مشکل را حل کرد. با هش‌ها، می‌توانم تمام داده‌های مرتبط با پیوند را تحت یک کلید ذخیره کنم (links::meta) و فیلدها را با HSET. TTL را می توان با استفاده از کل کلید اعمال کرد EXPIRE، تضمین ثبات

اما یک نکته وجود داشت: هش های Redis فاقد یک هستند NX گزینه ای برای جلوگیری از برخورد بررسی وجود کلید با EXISTS قبل از HSET در محیط های همزمان قابل اعتماد نیست. یک قفل توزیع شده می تواند کمک کند، اما توان نوشتن را کاهش می دهد.

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

Redis 7.4 راه حل بهتری را معرفی کرد: HEXPIRE فرمان این اجازه می دهد تا TTL را روی فیلدهای هش جداگانه تنظیم کنید، که برای این مورد استفاده عالی بود.

این رویکرد نهایی من است:

1. یک شناسه ایجاد کنید و سعی کنید جفت ID-URL را در یک هش نمایه ذخیره کنید (links:index) با استفاده از HSETNX links:index . اگر نتیجه است 0، یک برخورد وجود دارد.
2. در صورت موفقیت، ابرداده را با استفاده از آن تنظیم کنید HSET links::meta key1 value1 key2 value2 ....
3. تنظیم TTL برای میدان در links:index با استفاده از HEXPIRE links:index و برای ابرداده با EXPIRE links::meta .

مراحل 2 و 3 را می توان برای به حداقل رساندن سفرهای رفت و برگشت به Redis تنظیم کرد.

مدل داده

links
  | index - HASH
      |  -> target URL
  | 
      | meta - HASH
          | targetUrl -> target URL
          | createdAt -> created at date
          | validUntil -> valid until date

نتیجه گیری

امروز، ما شروع به مهندسی یک کوتاه کننده URL جدید کردیم و یک جزء مهم را مورد بحث قرار دادیم: ذخیره سازی لینک.

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

من دوست دارم نظرات و نظرات شما را در مورد این پروژه بشنوم! این سرویس در حال حاضر در آلفا است، اما با خیال راحت آن را امتحان کنید.

کد منبع در GitHub موجود است: tnfy-link. با نزدیک شدن به نسخه بتا، اسناد به‌روزرسانی می‌شوند.

با تشکر برای خواندن!