Cloudflare K2 را معرفی کرد؛ استریم رویداد بدون کلاستر Kafka

Cloudflare روز ۹ مهر ۱۴۰۵ (۱ اکتبر ۲۰۲۶) K2 را در بتای عمومی عرضه کرد: یک استریم رویداد سرورلس که مستقیم روی آبجکت استوریج R2 ساخته شده و رویدادها را به‌شکل لاگی پایدار و ترتیب‌دار نگه می‌دارد. K2 برای همان کاری ساخته شده که تیم‌ها با Apache Kafka می‌کنند، بدون بالا آوردن کلاستر و شمردن پارتیشن؛ در عوض یک هزینه مشخص دارد: حدود ۱ ثانیه تأخیر تولید در نسخه اول.

چرا یک لاگ روی R2 و نه یک کلاستر Kafka

به نوشته Micah Wylde و Marc Selwan در وبلاگ Cloudflare، K2 اول برای خودِ این شرکت ساخته شد: بافری پایدار برای ورودی Basin Pipelines. «این‌جا جایی است که بیشتر شرکت‌ها Apache Kafka را مستقر می‌کنند»، اما Pipelines روی شبکه لبه Cloudflare در بیش از ۳۳۵ شهر اجرا می‌شود و به روایت این شرکت، چنین زیرساختی اجازه اجرای Kafka را نمی‌دهد: سهم هر سرور کوچک است، ماشین‌ها زودگذرند و شبکه اغلب از اینترنت عمومی می‌گذرد.

پس Cloudflare حالت پایدار را به R2 سپرد، با دوام «۱۱ نُه». اما R2، مثل هر آبجکت استوریج، عملیات append ندارد؛ یعنی همان عملیات اصلی یک لاگ. K2 نوشته‌ها را در حافظه یک سرویس لبه جمع می‌کند و بعد در یک فایل کامل (segment) می‌نویسد؛ ترتیب و افست‌های اکیداً صعودی هم از عملیات اتمیک خودِ R2 می‌آید، بدون هماهنگ‌کننده جداگانه.

با آن ۱ ثانیه تأخیر، K2 کجا به کار می‌آید؟

Cloudflare این بده‌بستان را صریح می‌نویسد: نوشتن روی آبجکت استوریج از دیسک محلی کندتر است و باید منتظر جمع شدن بچ محلی هم ماند؛ در نسخه اول K2 این دو حدود ۱ ثانیه تأخیر تولید در صدک ۹۹ می‌سازند.

پس K2 ابزار مسیر درخواست نیست و جایی به کار می‌آید که نوشتن رویداد از خواندنش جدا باشد: خط لوله تحلیلی و کلیک‌استریم، تله‌متری و لاگ، گذرگاه رویداد میکروسرویس‌ها (event bus) و پردازش غیرهمگام. Cloudflare در نقشه راه از سطح Express با تأخیر کمتر نام برده، بدون تاریخ.

تولید رویداد: HTTP API یا بایندینگ Worker

استریم را با cf، Wrangler، داشبورد یا API می‌سازید و دو راه برای نوشتن دارید: POST به اندپوینت /produce، یا send() روی بایندینگ Worker. نمونه خودِ Cloudflare:

const result = await env.EVENTS.send([
  {
    content: new TextEncoder().encode(
      JSON.stringify({
        event: "page_view",
        path: new URL(request.url).pathname,
        timestamp: Date.now(),
      }),
    ),
    headers: { "content-type": "application/json" },
  },
]);

if (!result.success) {
  console.error(`Produce failed: ${result.error.message}`);
  return new Response("Failed to record event", {
    status: result.error.retryable ? 503 : 500,
  });
}

مستندات K2 چند نکته عملی دارد. بلوک [[k2]] در فایل Wrangler دو مقدار می‌گیرد: binding، نام دلخواه (مستندات ORDERS و وبلاگ EVENTS را مثال زده‌اند)، و stream، شناسه استریم. content باید ArrayBuffer یا Uint8Array باشد؛ رشته، حتی base64، پذیرفته نمی‌شود. send() هم هنگام رد شدن بچ خطا پرتاب نمی‌کند، پس result.success را بررسی کنید. نوشتن هر بچ اتمیک است: یا همه رکوردها ثبت می‌شوند یا هیچ‌کدام. اما K2 تکراری‌زدایی نمی‌کند، پس تلاش مجدد می‌تواند همان بچ را دو بار ذخیره کند.

مصرف: اشتراک، اجاره پنج‌دقیقه‌ای و ack یا nack

داده را با اشتراک (subscription) می‌خوانید: هر اشتراک نقطه شروع دارد (earliest یا latest) و موقعیت خودش را در لاگ نگه می‌دارد. چند مصرف‌کننده می‌توانند یک اشتراک را تقسیم کنند و بخشی از داده را بگیرند، یا هر کدام اشتراک خودش را بسازد و همه پیام‌ها را ببیند؛ یعنی pub/sub.

با فراخوانی /consume مصرف‌کننده یک بچ را برای ۵ دقیقه اجاره (lease) می‌گیرد و سه گزینه دارد: ack یعنی پردازش موفق بود، nack یعنی شکست خورد، و تمدید اجاره برای کاری که طول می‌کشد. رکوردهای اجاره‌منقضی یا nack‌شده در بچ بعدی دوباره تحویل می‌شوند؛ تحویل K2 «حداقل یک‌بار» (at-least-once) است، یعنی یک رکورد می‌تواند بیش از یک بار برسد و مصرف‌کننده باید تکراری را تحمل کند.

K2، Queues یا Pipelines؟

Cloudflare مقصد را تعیین‌کننده می‌داند: آبجکت استوریج و جدول‌های Iceberg سهم Pipelines است؛ پردازش سفارشی سهم K2.

محدودیت‌های بتا و قیمتِ پیش‌بینی‌شده

K2 روی Workers Free کار نمی‌کند و به Workers Paid نیاز دارد. جدول محدودیت‌ها سقف‌های روشنی می‌گذارد:

مصرف K2 در بتا صورت‌حساب نمی‌شود و Cloudflare قیمت نهایی را اعلام نکرده؛ فقط «پیش‌بینی» کرده: هر گیگابایت تولید ۰٫۰۴ دلار، هر گیگابایت مصرف ۰٫۰۴ دلار و هر گیگابایت نگهداری ۰٫۰۲ دلار در ماه. این شرکت نگفته در الگوی pub/sub هزینه مصرف برای هر اشتراک جدا حساب می‌شود یا نه؛ اگر معماری‌تان بر فن‌اوت تکیه دارد، همین نکته روی صورت‌حساب می‌نشیند.

برای تیمی که بین «کلاستر Kafka خودمان را بالا بیاوریم» و «سرویس مدیریت‌شده گران بخریم» گیر کرده، K2 گزینه سوم است، اگر آن ۱ ثانیه قابل تحمل باشد. استریم‌های چندگیگابایتی، کلید پیام و ترتیب بر اساس کلید، مصرف‌کننده‌های push و پشتیبانی از کلاینت‌های Kafka هم در نقشه راه‌اند، بدون هیچ تاریخی؛ همان مسیری که پلتفرم‌های لبه دیگر هم می‌روند.