Redpanda: بديل متوافق مع Kafka وأخف تشغيلاً

في مقال Apache Kafka شغلنا عنقوداً من ثلاثة سيرفرات، ورأينا أن كل سيرفر استهلك مئات الميجابايتات وهو شبه فارغ، وأن تشغيل JVM وضبطها جزء من العمل. وهنا يظهر سؤال طبيعي: هل يوجد شيء يتكلم مع تطبيقاتي بواجهة Kafka نفسها، لكنه أخف في التشغيل؟ وهذا ما يقدمه Redpanda، وقد استخدمناه في تجربة الطابور أم بث الأحداث لأنه يعمل بـ Container واحد، أما هنا فنتكلم عنه هو: كيف بني، وما رخصته بالضبط، ونشغل الكود نفسه عليه وعلى Kafka جنباً إلى جنب ونقيس الموارد، وسوف نناقش في هذا المقال ما يلي:

• ما هو Redpanda، وكيف يختلف من الداخل عن Kafka: C++، وخيط لكل نواة Thread-per-Core، ولا توجد JVM.
• التوافق مع Kafka API، وما الذي يعنيه عملياً.
• الرخصة BSL 1.1 وقيدها بالضبط، والميزات التجارية، والفترة التجريبية التي تبدأ تلقائياً.
• واجهة Redpanda Console.
• تجربة عملية: الكود نفسه على Redpanda وعلى Kafka، والذاكرة والمعالج في وقت الراحة، واختبار سرعة صغير على جهازنا.
• متى تختاره، ومتى تبقى على Kafka.

ما هو Redpanda؟

Redpanda منصة بث أحداث تتكلم بروتوكول Kafka، أي أن المنتجين والمستهلكين وأدوات Kafka تتصل به كما تتصل ب Kafka دون أي تغيير في الكود، ويصف مستودعه الرسمي نفسه بأنه متوافق مع Kafka، ومصمم ليكون أخف وأسرع وأبسط في التشغيل، ودون ZooKeeper ودون JVM، والمستودع نفسه يبين أن أغلب كوده بلغة C++. ويبدأ الاختلاف من الداخل، فبحسب صفحة المعمارية:

• خيط لكل نواة Thread-per-Core: يستخدم Redpanda مكتبة Seastar، ويثبت خيطاً واحداً على كل نواة معالج، فلا يتنقل العمل بين الأنوية ولا ينتظر خيط خيطاً آخر، وكل نواة مسؤولة عن مجموعة من ال Partitions.
• ذاكرة محجوزة من البداية: يحجز Redpanda الذاكرة عند التشغيل ويقسمها على الأنوية، بدل أن يعتمد على ال Page Cache الخاص بنظام التشغيل كما تفعل Kafka، وهذا سبب ما سوف تراه في التجربة: الذاكرة تكبر حتى الحد الذي أعطيته ثم تبقى عنده.
• Raft لكل شيء: النسخ بين السيرفرات بخوارزمية Raft، والبيانات الوصفية كذلك، فلا يوجد نظام خارجي.

والصورة التالية تبين الفرق:

وهناك فرق ثالث مهم في معنى acks=all، فبحسب توثيق المنتجين في Redpanda يكتب Redpanda كل رسالة على القرص fsync قبل أن يؤكدها مع acks=all، بينما في Kafka تعتبر الرسالة مؤكدة دون أن يشترط ذلك، وتعتمد Kafka على النسخ في أكثر من سيرفر. ويستطيع Redpanda أن يعمل مثل Kafka بإعداد اسمه Write Caching يؤكد بعد أن تستلم أغلبية السيرفرات الرسالة دون انتظار القرص، ويقول توثيق إعدادات المواضيع إنه معطل افتراضياً في وضع الإنتاج ومفعل في وضع التطوير، وهذه نقطة سوف تهمنا عند قراءة أرقام التجربة.

ماذا يعني التوافق مع Kafka API؟

يعني أن الكلاينت يتكلم البروتوكول نفسه، فمكتبة Kafka في Java أو Python أو Go، وأدوات سطر الأوامر في Kafka، وأدوات مثل Kafka Connect، تتصل ب Redpanda كما هي، وسوف نرى ذلك في التجربة بأداة kafka-topics.sh من Kafka تنشئ موضوعاً مضغوطاً في Redpanda. لكنه لا يعني أن Redpanda نسخة من Kafka، فالإدارة مختلفة تماماً: أداة rpk بدل سكربتات Kafka، وإعدادات العنقود بأسماء مختلفة، وبعض ميزات Kafka الحديثة قد تتأخر أو تأتي بشكل مختلف، مثل حقل ال Eligible Leader Replicas الذي رأيناه في تجربة Kafka ويظهر هنا بقيمة N/A. لذلك إذا كان نظامك يعتمد على ميزة محددة في Kafka فتحقق منها في توثيق Redpanda قبل أن تنتقل، ولا تفترض أن كل ما يعمل في Kafka يعمل بالضبط بالشكل نفسه.

الرخصة: BSL 1.1، وليست مفتوحة المصدر

هذه أهم نقطة يجب أن تفهمها قبل أن تختار Redpanda، والسبب أن الكلمة «مجاني» هنا لها حدود. فبحسب نص الرخصة في المستودع الكود الأساسي برخصة Business Source License 1.1، وفيها:

• ما يسمح به: نص الإذن الإضافي Additional Use Grant يسمح لك باستخدام Redpanda بشرط واحد هو ألا تستخدمه لتقديم خدمة بث أو طوابير Streaming or Queuing Service.
• ما هي هذه الخدمة بالضبط: تعرفها الرخصة بأنها عرض تجاري يسمح لطرف ثالث، غير موظفيك والمتعاقدين معك أفراداً، بالوصول إلى وظائف Redpanda بفعل يؤدي بشكل مباشر أو غير مباشر إلى إنشاء موضوع Topic فيه، وتذكر الرخصة أن هذا يشمل مزودي البنية التحتية مثل الخدمات السحابية والاستضافة ومراكز البيانات.
• متى تصبح مفتوحة: كل إصدار يتحول إلى رخصة Apache 2.0 بعد أربع سنوات من تاريخ إصداره، وهو ما تسميه الرخصة Change Date.

والنتيجة العملية: إذا كنت تشغل Redpanda لتطبيقات شركتك أو لنظام تبيعه دون أن يستطيع العميل إنشاء مواضيع بنفسه، فالرخصة تسمح بذلك، أما إذا كنت شركة استضافة أو تبني منصة يستطيع العملاء فيها إنشاء مواضيعهم، فهذا هو بالضبط ما تمنعه الرخصة، وتحتاج اتفاقاً تجارياً أو Kafka نفسها. ولاحظ أن هذا ليس قراراً قانونياً نقدمه لك، فإذا كانت حالتك على الحدود فاقرأ نص الرخصة بنفسك أو اسأل مستشارك القانوني.

وهناك طبقة ثانية: بحسب ملف الأسئلة في مجلد الرخص الميزات التجارية برخصة أخرى اسمها Redpanda Community License، وهي تسمح باستخدام هذه الميزات فقط إذا دفعت مقابلها. وتذكر صفحة الترخيص أن من هذه الميزات التخزين المتدرج Tiered Storage، والتحكم بالصلاحيات بالأدوار RBAC، وسجل التدقيق Audit Logging، وتوزيع البيانات المستمر Continuous Data Balancing، وغيرها، وأن كل عنقود جديد يحصل تلقائياً على رخصة تجريبية لمدة 30 يوماً، وبعد انتهائها تتعطل الميزات التجارية غير المستخدمة وتدخل المستخدمة في حالة مقيدة. وقد رأينا ذلك في التجربة: العنقود الجديد كان يستخدم ميزتين تجاريتين دون أن نطلب ذلك، فخطط من البداية لما سيحدث بعد 30 يوماً.

والدرس العام: اقرأ رخصة كل أداة بنية تحتية قبل أن تبني نظامك عليها، ولا تكتف بأن «الكود موجود على GitHub»، فوجود الكود لا يعني أن كل استخدام مسموح.

واجهة Redpanda Console

Redpanda Console واجهة ويب لإدارة المواضيع ومجموعات المستهلكين وقراءة الرسائل، ويصفها مستودعها بأنها تعمل مع أحمال Kafka وRedpanda، أي أنك تستطيع أن تستخدمها مع عنقود Kafka أيضاً. وتحتاج بعض ميزاتها، مثل تسجيل الدخول والصلاحيات وإعادة توزيع ال Partitions، إلى رخصة تجارية بحسب صفحة الترخيص، أما التصفح والقراءة فتعمل في النسخة المجتمعية Console Community كما في التجربة. والصورة التالية من تجربتنا، وفيها مواضيع اختبار السرعة:

ولا تقم بنشر منفذ الواجهة على الإنترنت دون تسجيل دخول، والسبب أن من يصل إليها يقرأ رسائلك ويحذف مواضيعك، وفي التجربة ربطناها بالعنوان 127.0.0.1 فقط.

تجربة عملية: الكود نفسه على Redpanda وعلى Kafka

الآن سوف نشغل Redpanda 26.2.4 وApache Kafka 4.3.1، كل منهما سيرفر واحد مقيد بنواة معالج واحدة، ومعهما Redpanda Console 3.12.0، ثم نشغل سكربت Python واحداً بمكتبة confluent-kafka 2.16.0 على الاثنين دون أي تغيير إلا عنوان الوسيط. ونفذنا الأوامر من Git Bash على Windows مع Docker Engine 29.8.0 على جهاز فيه 8 أنوية و32 جيجابايت ذاكرة.

ملفات التجربة

أنشئ مجلداً فيه compose.yaml التالي:

name: lab-redpanda

services:
  redpanda:
    image: redpandadata/redpanda:v26.2.4
    container_name: lab-redpanda-broker
    hostname: redpanda
    cpus: 1                                   # same CPU budget as the Kafka broker below
    command:
      - redpanda
      - start
      - --smp=1                               # one core, one thread (thread-per-core)
      - --memory=1G                           # memory Redpanda reserves up front
      - --overprovisioned                     # lab only: the core is shared with other containers
      - --kafka-addr=internal://0.0.0.0:9092
      - --advertise-kafka-addr=internal://redpanda:9092
      - --rpc-addr=redpanda:33145
      - --advertise-rpc-addr=redpanda:33145
    volumes: ["redpanda:/var/lib/redpanda/data"]
    healthcheck:
      test: ["CMD", "rpk", "cluster", "health", "--exit-when-healthy"]
      interval: 5s
      retries: 40

  console:
    image: redpandadata/console:v3.12.0
    container_name: lab-redpanda-console
    environment:
      KAFKA_BROKERS: redpanda:9092
    ports: ["127.0.0.1:18080:8080"]          # the web console, from this machine only
    depends_on:
      redpanda:
        condition: service_healthy

  kafka:
    image: apache/kafka:4.3.1                 # one Kafka node with its default 1 GB heap, for comparison
    container_name: lab-redpanda-kafka
    hostname: kafka
    cpus: 1
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
    healthcheck:
      test: ["CMD-SHELL", "/opt/kafka/bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 > /dev/null 2>&1"]
      interval: 5s
      retries: 40

  app:
    build: .
    image: lab-redpanda-app:1
    profiles: ["tools"]

volumes:
  redpanda:

في الإعداد أعلاه لاحظ التالي:

• الوسيطان مقيدان بنواة واحدة cpus: 1 حتى تكون المقارنة على الموارد نفسها، وRedpanda يعرف ذلك من --smp=1 فيشغل خيطاً واحداً.
• Redpanda يحجز 1 جيجابايت بالخيار --memory=1G، وKafka تعمل بذاكرة JVM الافتراضية التي يضعها سكربت التشغيل kafka-server-start.sh عندما لا تحدد غيرها، وهي 1 جيجابايت أيضاً.
• الخيار --overprovisioned للتجربة فقط، لأن النواة مشتركة مع برامج أخرى على الجهاز، وفي الإنتاج تعطي Redpanda أنوية كاملة.
• Kafka هنا سيرفر واحد بدورين Broker وController، وهذا يكفي للمقارنة فقط وليس للإنتاج، وقد شرحنا العنقود الحقيقي في مقال Kafka.

ثم Dockerfile:

FROM python:3.13.16-slim
RUN pip install --no-cache-dir confluent-kafka==2.16.0
WORKDIR /app
COPY *.py ./
ENV PYTHONUNBUFFERED=1

ثم bench.py، وهو الكود الذي سوف نشغله على الوسيطين: ينشئ موضوعاً بثلاثة Partitions، وينشر 200 ألف رسالة حجم كل منها 1 كيلوبايت مع acks=all ومنتج آمن عند التكرار، ثم يقرؤها كلها بمجموعة مستهلكين:

# The same Kafka client code for both brokers:  python bench.py <bootstrap> [messages]
# Creates a topic, produces N messages of 1 KB with acks=all, then reads them all back with a consumer group.
import sys, time, uuid
from confluent_kafka import Producer, Consumer
from confluent_kafka.admin import AdminClient, NewTopic

bootstrap, total = sys.argv[1], int(sys.argv[2]) if len(sys.argv) > 2 else 200_000
topic = f"bench-{uuid.uuid4().hex[:6]}"

admin = AdminClient({"bootstrap.servers": bootstrap})
admin.create_topics([NewTopic(topic, num_partitions=3, replication_factor=1)])[topic].result()
md = admin.list_topics(timeout=10)
print(f"broker: {bootstrap}, topic {topic} with {len(md.topics[topic].partitions)} partitions")

p = Producer({"bootstrap.servers": bootstrap, "acks": "all", "linger.ms": 5, "enable.idempotence": True})
payload, failed = b"x" * 1024, 0
def report(err, msg):
    global failed
    failed += err is not None
start = time.time()
for i in range(total):
    while True:
        try:
            p.produce(topic, key=str(i % 1000), value=payload, on_delivery=report)
            break
        except BufferError:               # local queue full: let the client send what it has
            p.poll(0.05)
    p.poll(0)
p.flush()
secs = time.time() - start
print(f"produce: {total} messages in {secs:.1f}s = {total / secs:,.0f} msg/s, {total / secs / 1024:.1f} MB/s, failed={failed}")

c = Consumer({"bootstrap.servers": bootstrap, "group.id": f"g-{topic}", "auto.offset.reset": "earliest"})
c.subscribe([topic])
got, start = 0, None
while got < total:
    for m in c.consume(num_messages=1000, timeout=5):
        if m.error() is None:
            start = start or time.time()
            got += 1
secs = time.time() - start
print(f"consume: {got} messages in {secs:.1f}s = {got / secs:,.0f} msg/s")
c.close()

التشغيل، والإعداد الذي يأتي مع ال Image

docker compose --profile tools build
docker compose up -d --wait
docker exec lab-redpanda-broker rpk version
docker exec lab-redpanda-broker rpk cluster info

والمخرج بعد حذف بعض الأسطر سوف يكون كما يلي:

rpk version: v26.2.4
Git ref:     9a85b6b72a2efafabaac6e7997f2c477cfedd1f7

Redpanda Cluster
  node-0  v26.2.4 - 9a85b6b72a2efafabaac6e7997f2c477cfedd1f7
CLUSTER
=======
redpanda.ca388cbb-f76b-455e-ba8c-f8a0981093da

BROKERS
=======
ID    HOST      PORT
0*    redpanda  9092

ثم ننظر في ملف الإعداد الذي أنشأه Redpanda عند التشغيل الأول:

docker exec lab-redpanda-broker cat /etc/redpanda/redpanda.yaml

والمخرج بعد حذف أسطر العناوين والمنافذ سوف يكون كما يلي:

redpanda:
    data_directory: /var/lib/redpanda/data
    seed_servers: []
    ...
    developer_mode: true
    auto_create_topics_enabled: true
    fetch_reads_debounce_timeout: 10
    group_initial_rebalance_delay: 0
    group_topic_partitions: 3
    log_segment_size_min: 1
    storage_min_free_bytes: 10485760
    topic_partitions_per_shard: 1000
    write_caching_default: "true"
rpk:
    overprovisioned: true

لاحظ أن ال Image تبدأ بإعدادات تطوير: developer_mode: true وwrite_caching_default: "true"، أي أن تأكيد acks=all لا ينتظر القرص، وهذا مناسب لجهازك لكنه ليس ما تريده في الإنتاج، ويشرح توثيق الأمر rpk redpanda mode أن وضع التطوير يغير هذه الإعدادات، وأن وضع الإنتاج يتطلب rpk redpanda mode production وضبط النظام بالأمر rpk redpanda tune. لذلك سوف نقيس بالوضعين.

الموارد في وقت الراحة

بعد التشغيل مباشرة، ودون أي مواضيع أو رسائل:

for i in 1 2 3; do docker stats --no-stream --format '{{.Name}} {{.MemUsage}} {{.CPUPerc}}' lab-redpanda-broker lab-redpanda-kafka lab-redpanda-console; done

lab-redpanda-broker 276.5MiB / 31.29GiB 0.39%
lab-redpanda-kafka 376.4MiB / 31.29GiB 8.44%
lab-redpanda-console 50.83MiB / 31.29GiB 0.02%

lab-redpanda-broker 276.5MiB / 31.29GiB 0.36%
lab-redpanda-kafka 375.8MiB / 31.29GiB 4.11%
lab-redpanda-console 50.83MiB / 31.29GiB 0.00%

lab-redpanda-broker 276.5MiB / 31.29GiB 0.55%
lab-redpanda-kafka 404.4MiB / 31.29GiB 114.41%
lab-redpanda-console 50.83MiB / 31.29GiB 0.00%

لاحظ أن Redpanda استهلك 276 ميجابايت وأقل من 1% من المعالج وهو فارغ، وKafka قرابة 380 إلى 400 ميجابايت مع قفزات في المعالج، وهذه القفزات من عمل JVM في الخلفية مثل جمع النفايات Garbage Collection وتهيئة الكود، وهي أوضح هنا لأن Kafka مقيدة بنواة واحدة. والواجهة Console أخذت 50 ميجابايت فقط.

اختبار سرعة صغير على جهازنا

نشغل السكربت نفسه على الوسيطين، أولاً بإعدادات ال Image كما هي، ثم بعد تعطيل Write Caching في Redpanda حتى يكتب على القرص قبل التأكيد كما في الإنتاج:

for b in kafka:9092 redpanda:9092; do docker compose run --rm -T app python bench.py $b; done
docker exec lab-redpanda-broker rpk cluster config set write_caching_default false
for b in redpanda:9092 kafka:9092 redpanda:9092 kafka:9092 redpanda:9092; do docker compose run --rm -T app python bench.py $b; done

والمخرج بعد حذف أسطر Compose ورسالة التحذير الأولى من Kafka سوف يكون كما يلي:

broker: kafka:9092, topic bench-3a9a81 with 3 partitions
produce: 200000 messages in 14.5s = 13,832 msg/s, 13.5 MB/s, failed=0
consume: 200000 messages in 4.0s = 50,502 msg/s
broker: redpanda:9092, topic bench-3a2ea2 with 3 partitions
produce: 200000 messages in 4.2s = 47,572 msg/s, 46.5 MB/s, failed=0
consume: 200000 messages in 1.9s = 107,602 msg/s
Successfully updated configuration. New configuration version is 3.
broker: redpanda:9092, topic bench-b3ed4d with 3 partitions
produce: 200000 messages in 3.4s = 59,015 msg/s, 57.6 MB/s, failed=0
consume: 200000 messages in 1.7s = 120,363 msg/s
broker: kafka:9092, topic bench-1db90d with 3 partitions
produce: 200000 messages in 8.3s = 24,036 msg/s, 23.5 MB/s, failed=0
consume: 200000 messages in 3.8s = 52,275 msg/s
broker: redpanda:9092, topic bench-284334 with 3 partitions
produce: 200000 messages in 5.1s = 39,261 msg/s, 38.3 MB/s, failed=0
consume: 200000 messages in 1.0s = 210,303 msg/s
broker: kafka:9092, topic bench-b95f83 with 3 partitions
produce: 200000 messages in 7.8s = 25,649 msg/s, 25.0 MB/s, failed=0
consume: 200000 messages in 1.0s = 204,617 msg/s
broker: redpanda:9092, topic bench-26e526 with 3 partitions
produce: 200000 messages in 7.6s = 26,465 msg/s, 25.8 MB/s, failed=0
consume: 200000 messages in 1.0s = 206,943 msg/s

والجدول التالي يجمع الأرقام، وهي أرقام جهاز واحد في يوم واحد وليست مقياساً عاماً:

في المخرج أعلاه لاحظ التالي:

• Redpanda كان أسرع في النشر في أغلب المرات، لكن الفرق بين تشغيل وآخر للوسيط نفسه كبير جداً، من 26 ألفاً إلى 59 ألفاً، والسبب أن الوسيطين يشتركان مع برامج أخرى في جهاز واحد مع Windows وDocker Desktop، وأن الكلاينت نفسه بلغة Python قد يكون هو الحد في بعض المرات.
• أول تشغيل ل Kafka كان الأبطأ، وظهرت فيه رسالة Coordinator load in progress، أي أن الوسيط كان ما زال يهيئ موضوع المجموعات الداخلي، وبعده تحسنت أرقامه، وهذا من طبيعة JVM التي تسرع بعد أن تعمل فترة.
• القراءة في المرات الأخيرة وصلت في الاثنين إلى قرابة 200 ألف رسالة في الثانية، لأن البيانات كانت في الذاكرة.
• تعطيل Write Caching في Redpanda لم يبطئه بشكل واضح في تجربتنا، والسبب المرجح أن القرص على هذا الجهاز سريع والحجم صغير، فلا تبن على هذه النقطة قراراً قبل أن تقيس على أجهزتك.

وقد يتساءل البعض: إذن أيهما أسرع؟ والإجابة الصادقة أن هذه التجربة لا تكفي لتقول ذلك، فاختبار حقيقي يحتاج سيرفرات مخصصة، وعنقوداً بثلاثة سيرفرات، ومدة طويلة، وأحمالاً تشبه أحمالك، وما تقوله التجربة بوضوح هو شيئان: الكود نفسه عمل على الاثنين دون أي تغيير، وRedpanda استهلك ذاكرة ومعالجاً أقل في وقت الراحة.

الذاكرة بعد الحمل

docker stats --no-stream --format '{{.Name}} {{.MemUsage}} {{.CPUPerc}}' lab-redpanda-broker lab-redpanda-kafka

lab-redpanda-broker 898.2MiB / 31.29GiB 0.56%
lab-redpanda-kafka 714.3MiB / 31.29GiB 107.77%

لاحظ أن الصورة انعكست بعد الحمل: Redpanda أصبح قرابة 900 ميجابايت، أي قريباً من 1 جيجابايت التي حجزناها، والسبب أنه يستخدم ذاكرته المحجوزة كذاكرة مؤقتة لنفسه بدل ال Page Cache، أما Kafka فتترك البيانات في ال Page Cache الخاص بنظام التشغيل، وهذا لا يظهر في رقم ال Container. لذلك لا تقارن الذاكرة بين الاثنين برقم واحد، وإنما اسأل: كم ذاكرة يحتاج السيرفر كله لكل منهما؟

أدوات Kafka تعمل على Redpanda

نستخدم أداة kafka-topics.sh من Container ال Kafka لإنشاء موضوع مضغوط في Redpanda، ثم نقرأ إعداده بأداة rpk:

docker exec lab-redpanda-kafka /opt/kafka/bin/kafka-topics.sh --bootstrap-server redpanda:9092 \
  --create --topic from-kafka-cli --partitions 3 --config cleanup.policy=compact
docker exec lab-redpanda-kafka /opt/kafka/bin/kafka-topics.sh --bootstrap-server redpanda:9092 --describe --topic from-kafka-cli
docker exec lab-redpanda-broker rpk topic describe from-kafka-cli -c | grep cleanup

Created topic from-kafka-cli.
Topic: from-kafka-cli	TopicId: gXvMJ7L5RceaxqHVn_n4hA	PartitionCount: 3	ReplicationFactor: 1	Configs: cleanup.policy=compact
	Topic: from-kafka-cli	Partition: 0	Leader: 0	Replicas: 0	Isr: 0	Elr: N/A	LastKnownElr: N/A
	Topic: from-kafka-cli	Partition: 1	Leader: 0	Replicas: 0	Isr: 0	Elr: N/A	LastKnownElr: N/A
	Topic: from-kafka-cli	Partition: 2	Leader: 0	Replicas: 0	Isr: 0	Elr: N/A	LastKnownElr: N/A
cleanup.policy                        compact        DYNAMIC_TOPIC_CONFIG

لاحظ أن أداة Kafka أنشأت الموضوع ووصفته دون أي مشكلة، وأن rpk يرى الإعداد نفسه، ولاحظ Elr: N/A الذي ذكرناه في قسم التوافق.

الرخصة التجريبية التي بدأت وحدها

docker exec lab-redpanda-broker rpk cluster license info

LICENSE INFORMATION
===================
License status:              valid
License violation:           false
Enterprise features in use:  [partition_auto_balancing_continuous core_balancing_continuous]
Organization:                Redpanda Built-In Evaluation Period
Type:                        free_trial
Expires:                     Nov 10 2026

لاحظ أن العنقود بدأ فترة تجريبية تنتهي بعد 30 يوماً، وأنه يستخدم ميزتين تجاريتين للتوزيع المستمر دون أن نطلبهما، فإذا كنت تشغل النسخة المجتمعية في الإنتاج فراجع هذا الأمر بعد التثبيت، وقرر ماذا تفعل بهذه الميزات قبل أن تنتهي الفترة، حتى لا تفاجأ بتغير سلوك العنقود.

متى تختار Redpanda، ومتى تبقى على Kafka؟

والقاعدة العملية: اختر Redpanda إذا كنت تريد واجهة Kafka بأقل جهد تشغيل، وفريقك صغير، وحالتك بعيدة عن قيد الرخصة، وخذ الميزات التجارية في حسابك من البداية. وابق على Apache Kafka إذا كانت الرخصة المفتوحة شرطاً عندك، أو كنت تقدم خدمة بث لعملاء ينشئون مواضيعهم، أو تعتمد على ميزات Kafka الحديثة فور صدورها.

أخطاء شائعة

• التشغيل في الإنتاج بإعدادات ال Image: كما رأينا، ال Image تبدأ بوضع التطوير، فاستخدم rpk redpanda mode production وrpk redpanda tune كما في دليل النشر للإنتاج.
• اعتبار Redpanda مفتوح المصدر: الرخصة BSL، فاقرأ قيدها قبل أن تبني عليه خدمة لعملاء.
• نسيان الفترة التجريبية: الميزات التجارية تعمل في أول 30 يوماً ثم تتقيد، فلا تختبر نظامك على ميزة لن تملكها بعد شهر.
• مقارنة الذاكرة برقم ال Container: Redpanda يحجز ذاكرته ويستخدمها، وKafka تعتمد على ذاكرة نظام التشغيل، فقارن حاجة السيرفر كله.
• بناء القرار على اختبار سرعة على جهاز المطور: رأيت كيف تغيرت الأرقام بين تشغيل وآخر، فاختبر على أجهزة تشبه الإنتاج.

حذف المختبر

docker compose --profile tools down -v
docker image rm lab-redpanda-app:1

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• Redpanda يتكلم Kafka API، فالكود والأدوات نفسها تعمل عليه، وقد شغلنا السكربت نفسه وأداة kafka-topics.sh عليه دون تغيير.
• من الداخل مكتوب بلغة C++ مع Seastar، بخيط لكل نواة وذاكرة محجوزة من البداية، ودون JVM أو ZooKeeper، واستهلك في تجربتنا ذاكرة ومعالجاً أقل في وقت الراحة.
• مع acks=all يكتب على القرص قبل التأكيد في وضع الإنتاج، وال Image تبدأ بوضع التطوير الذي يؤكد قبل القرص.
• الرخصة BSL 1.1 تمنع تقديمه خدمة بث أو طوابير يستطيع فيها الآخرون إنشاء مواضيع، وكل إصدار يصبح Apache 2.0 بعد أربع سنوات، والميزات التجارية برخصة منفصلة وتبدأ بفترة تجريبية 30 يوماً.
• اختبار السرعة على جهاز واحد أعطى أرقاماً متقلبة، فلا تبن عليه قراراً، واختبر على أجهزتك.

وفي المقال التالي من المرحلة نتكلم عن NATS، وهو وسيط مختلف تماماً في الفكرة، خفيف جداً ومصمم للرسائل بين الخدمات المصغرة.

دليلApache Kafka: بث الأحداث بأحجام ضخمةكيف يحفظ عنقود Kafka أحداثك بنسخ على عدة سيرفرات، وماذا يحدث للمنتجين والمستهلكين عندما يسقط أحدها.دليلالطابور Queue أم بث الأحداث Event Streaming؟ما يحدث للرسالة بعد قراءتها هو الفرق بين طابور مثل RabbitMQ وسجل أحداث مثل Kafka، ومنه تعرف أيهما يناسب مشروعك.دليلRabbitMQ: طوابير موثوقة لتطبيقاتك على سيرفرككيف تشغل RabbitMQ في عنقود من ثلاث عقد، وتوجه الرسائل بالموزعات، وتضمن ألا تضيع رسالة إذا سقطت عقدة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ تجربة Redpanda 26.2.4 وRedpanda Console 3.12.0 بجانب Apache Kafka 4.3.1، بمكتبة confluent-kafka 2.16.0 على Python 3.13.16 في Docker.