گو میں پوسٹگری ایس کیو ایل کی حمایت یافتہ ٹاسک قطار کیسے بنائیں

ویب ایپلیکیشن بناتے وقت، تمام کام صارف کی درخواست کے اندر نہیں ہونا چاہیے۔

کچھ آپریشن سست ہیں۔ کچھ آپریشن ناکام ہو سکتے ہیں۔ کچھ کام بعد میں کرنے کی ضرورت ہوگی۔ ای میلز بھیجنا، امیجز کا سائز تبدیل کرنا، ویب ہکس پر کارروائی کرنا، رپورٹس بنانا، اور تھرڈ پارٹی APIs کو دوبارہ آزمانا یہ سب اچھی مثالیں ہیں۔

یہ کام عام طور پر بیک گراؤنڈ ٹاسک سسٹم کے ذریعے سنبھالے جاتے ہیں۔

یہ مضمون ایک اوپن سورس گو پروجیکٹ کا استعمال کرتا ہے جسے Swig کہا جاتا ہے اس کی ایک حقیقی دنیا کی مثال کے طور پر کہ PostgreSQL کی حمایت یافتہ کام کی قطاریں عملی طور پر کیسے کام کرتی ہیں۔

آخر تک، آپ سمجھ جائیں گے کہ Go اور PostgreSQL کا استعمال کرتے ہوئے بیک گراؤنڈ ٹاسک کیو کیسے بنایا جائے اور PostgreSQL زیادہ تر ڈویلپرز کے خیال سے بہتر کیوں ہے۔

انڈیکس

1. شرطیں

2. کیا سیکھنا ہے۔

3. کام کی قطار کیا ہے؟

4. قطاروں کے لیے PostgreSQL کیوں استعمال کریں؟

5. سوئگ کا فن تعمیر

6. PostgreSQL میں آپریشنز کا اظہار کیسے کریں۔

7. گو میں کارکن کی تعریف کیسے کی جائے۔

8. ریاست کا اشتراک کیے بغیر کارکنوں کو کیسے رجسٹر کریں۔

9. ٹاسک کیسے شامل کریں۔

10. متعدد کارکنوں کو محفوظ طریقے سے ہینڈل کرنے کا طریقہ

11. ہم وقتی کارکنوں کے لیے گوروٹینز کا استعمال کیسے کریں۔

12. LISTEN/NOTIFY کے ساتھ کارکن کو کیسے جگایا جائے۔

13. ایڈوائزری لاکنگ کا استعمال کرتے ہوئے لیڈر کا انتخاب کیسے کریں۔

14. ناکام کاموں کو کیسے ہینڈل کریں۔

15. ڈیٹا بیس ڈرائیوروں کا خلاصہ کیسے کریں۔

16. نتیجہ

شرطیں

پیروی کرنے کے لیے آپ کو ضرورت ہو گی:

• گو کا بنیادی علم (سٹرکٹس، انٹرفیس، گوروٹینز)

• PostgreSQL اور SQL کے بارے میں کام کرنے کی سمجھ

• Go انسٹال کریں (1.21 یا اس سے زیادہ)

• PostgreSQL مثال مقامی طور پر یا دور سے دستیاب ہے۔

کیا سیکھنا ہے۔

• PostgreSQL میں آپریشنز کی نمائندگی اور ذخیرہ کرنے کا طریقہ

• استعمال کرنے والے ہم وقت کارکنوں کے درمیان کام کا محفوظ طریقے سے دعوی کیسے کریں۔ FOR UPDATE SKIP LOCKED

• اپنے ملازمین کو مؤثر طریقے سے کیسے بیدار کریں۔ LISTEN/NOTIFY

• ایڈوائزری لاکنگ کا استعمال کرتے ہوئے مثالوں میں لیڈر کا انتخاب کیسے کریں۔

• گو انٹرفیس، گوروٹینز، سیاق و سباق، اور لین دین حقیقی نظاموں میں ایک ساتھ کیسے فٹ ہوتے ہیں۔

کام کی قطار کیا ہے؟

کام کی قطار بعد میں کیے جانے والے کام کو ذخیرہ کرنے کا ایک نظام ہے۔

ایپلیکیشن قطار میں ایک کام کا اضافہ کرتی ہے۔ کارکن قطار سے کام لیتے ہیں اور ان پر عمل درآمد کرتے ہیں۔

مثال کے طور پر، جب کوئی صارف سائن اپ کرتا ہے، تو آپ فوری طور پر اپنی درخواست میں صارف بنا سکتے ہیں اور پھر درج ذیل اعمال شامل کر سکتے ہیں:

{
  "kind": "send_welcome_email",
  "payload": {
    "to": "user@example.com",
    "subject": "Welcome!"
  }
}

ایک بیک گراؤنڈ ورکر بعد میں اس کام کو اٹھائے گا اور ای میل بھیجے گا۔ یہ صارف کی درخواستوں کو تیزی سے رکھتا ہے۔ جواب واپس کرنے سے پہلے سائن اپ روٹ کو ای میل فراہم کنندہ کا انتظار نہیں کرنا پڑتا ہے۔

کام کی قطاروں کو عام طور پر کئی اہم سوالات کے جوابات دینے کی ضرورت ہوتی ہے:

• میرا کام کہاں محفوظ ہے؟

• ورکرز کو نوکریاں کیسے ملتی ہیں؟

• آپ دو کارکنوں کو ایک ہی کام پر کارروائی کرنے سے کیسے روکتے ہیں؟

• میں ناکام آپریشن کی دوبارہ کوشش کیسے کروں؟

• آپ کارکنوں کو محفوظ طریقے سے کیسے بند کرتے ہیں؟

• آپ ملازمت کی تخلیق اور درخواست کے ڈیٹا کو کس طرح مستقل رکھتے ہیں؟

سوئگ ان سوالات کا جواب Go اور PostgreSQL کے ساتھ دیتا ہے۔

قطاروں کے لیے PostgreSQL کیوں استعمال کریں؟

بہت سے کام کی قطاریں Redis، RabbitMQ، SQS، یا Kafka کا استعمال کرتی ہیں۔ وہ تمام مفید اوزار ہیں۔ تاہم، بہت سی ایپلیکیشنز پہلے ہی PostgreSQL پر انحصار کرتی ہیں۔ اگر آپ کی ایپ میں پوسٹگریس پہلے سے موجود ہے تو، آپ بیک گراؤنڈ ٹاسک چلانے کے لیے کوئی اور سروس نہیں چلانا چاہیں گے۔

PostgreSQL قطاروں کے لیے کئی بہت مفید خصوصیات فراہم کرتا ہے۔

• پائیدار کام کے اسٹوریج کے لیے میز

• جوہری تحریروں کے لیے لین دین

• محفوظ کنکرنٹ پروسیسنگ کے لیے قطار لاکنگ

• SKIP LOCKED کارکنوں کو دوسری ملازمتوں کا دعوی کرنے کے قابل بنانا

• LISTEN/NOTIFY نئی نوکری آنے پر ملازمین کو جگانا۔

• رہنما کے انتخاب کے لیے ایڈوائزری لاکنگ

• لچکدار ٹاسک پے لوڈز کے لیے JSONB

تجارتی تعلقات اہم ہیں۔ PostgreSQL کی حمایت یافتہ قطاریں ایونٹ اسٹریمنگ کے لیے کافکا یا پیچیدہ روٹنگ کے لیے RabbitMQ کو تبدیل کرنے کی کوشش نہیں کرتی ہیں۔ یہ کسی بھی بنیادی ڈھانچے کو شامل کیے بغیر عام ایپلیکیشن کے پس منظر کے کاموں کو آسان، قابل اعتماد اور کام کرنے میں آسان بناتا ہے۔

سوئگ کا فن تعمیر

اعلی سطح پر، سوئگ پانچ حصوں پر مشتمل ہے:

1. کوئی راستہ نہیں swig_jobs PostgreSQL میں ٹیبل

2. کاموں کو سنبھالنے کے لئے کارکنوں کو منتقل کریں۔

3. ایک ورکر رجسٹری جو ورکرز کی اقسام کے مطابق جاب کے ناموں کا نقشہ بناتی ہے۔

4. ڈرائیور کی پرت دونوں کو سپورٹ کرتی ہے۔ pgx اور database/sql

5. مشترکہ دیکھ بھال کے کاموں کے لیے لیڈر لوپ

بنیادی بہاؤ مندرجہ ذیل ہے:

1. کال ایپ AddJob

2. سوئگ JSON پر جاب پے لوڈ کو سیریلائز کرتا ہے۔

3. سوئگ قطاریں داخل کرتا ہے۔ swig_jobs

4. PostgreSQL ایک اطلاع بھیجتا ہے کہ نوکری بن گئی ہے۔

5. ایک گو کارکن اٹھتا ہے اور ایک زیر التواء کام کی درخواست کرنے کی کوشش کرتا ہے۔

6. PostgreSQL قطار کو لاک کرنا یقینی بناتا ہے کہ صرف ایک کارکن اس قطار کا دعوی کرتا ہے۔

7. کارکن کام چلاتے ہیں۔

8. سوئگ کاموں کو مکمل یا ناکام کے طور پر نشان زد کرتا ہے۔

مشکل حصے ہیں ہم آہنگی، غلطیاں، کنکشن لائف سائیکل، اور ختم کرنا۔ یہ وہ جگہ ہے جہاں Go اور PostgreSQL ایک ساتھ کھیلتے ہیں۔

PostgreSQL میں آپریشنز کا اظہار کیسے کریں۔

یہاں سوئگ ایکشن ٹیبل کا ایک آسان ورژن ہے:

CREATE TABLE swig_jobs (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  kind TEXT NOT NULL,
  queue TEXT NOT NULL,
  payload JSONB NOT NULL,
  status TEXT NOT NULL DEFAULT 'pending',
  priority INTEGER NOT NULL DEFAULT 0,
  attempts INTEGER NOT NULL DEFAULT 0,
  max_attempts INTEGER NOT NULL DEFAULT 3,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  scheduled_for TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  instance_id UUID,
  worker_id UUID,
  locked_at TIMESTAMPTZ,
  last_error TEXT,
  last_error_at TIMESTAMPTZ
);

ہر قطار ایک آپریشن ہے۔ اہم کالم یہ ہیں:

• kind: ملازمت کی قسم، جیسے send_email

• payload: کام کو چلانے کے لیے JSON ڈیٹا درکار ہے۔

• status: چاہے کام زیر التواء ہے، پروسیسنگ، مکمل، یا ناکام ہے۔

• attempts: جتنی بار آپریشن کی کوشش کی گئی۔

• scheduled_for: جب ٹاسک پر عمل درآمد کی اجازت ہو۔

• locked_at: جب نوکری کا دعویٰ کیا گیا تھا۔

میز سچائی کا ذریعہ ہے۔ PostgreSQL اطلاعات کارکنوں کو جگا سکتی ہیں، لیکن اطلاعات پائیدار قطاریں نہیں ہیں۔ لائن swig_jobs ہوں

گو میں کارکن کی تعریف کیسے کی جائے۔

سوئگ میں، ایک کارکن گو کی ایک قسم ہے جو جانتا ہے کہ ایک قسم کے کام کو کیسے سنبھالنا ہے۔

یہاں ایک سادہ ای میل کارکن ہے:

type EmailWorker struct {
    To      string `json:"to"`
    Subject string `json:"subject"`
    Body    string `json:"body"`
}

func (w *EmailWorker) JobName() string {
    return "send_email"
}

func (w *EmailWorker) Process(ctx context.Context) error {
    fmt.Printf("Sending email to %s with subject %s\n", w.To, w.Subject)
    return nil
}

دو اہم طریقے ہیں:

ساختی فیلڈز بھی آپریشن کے دلائل ہیں۔ قطار میں شامل کرتے وقت EmailWorkerسوئگ ساخت کو JSON پر سیریلائز کرتا ہے اور اسے PostgreSQL میں اسٹور کرتا ہے۔ بعد میں، کارکن قطار کی درخواست کرتا ہے اور JSON کو ایک نئی قطار میں واپس لے جاتا ہے۔ EmailWorkerاور کال کریں Process.

انٹرفیس پر جائیں۔

گو انٹرفیس رویے کی وضاحت کرتے ہیں۔ سوئگ کو ہر کارکن کی صحیح مخصوص قسم جاننے کی ضرورت نہیں ہے۔ آپ کو صرف یہ جاننے کی ضرورت ہے کہ کارکن ٹاسک کا نام فراہم کر سکتا ہے اور کام پر کارروائی کر سکتا ہے۔

type Worker interface {
    JobName() string
    Process(context.Context) error
}

اگر قسم کا ایک متعلقہ طریقہ ہے، تو یہ ایک انٹرفیس کو مطمئن کرتا ہے، کسی واضح اعلان کی ضرورت نہیں ہے۔ یہ ایک وجہ ہے کہ گو میں انٹرفیس بہت مفید ہیں۔ آپ وراثت کے بجائے رویے کے ارد گرد ڈیزائن کر سکتے ہیں.

ریاست کا اشتراک کیے بغیر کارکنوں کو کیسے رجسٹر کریں۔

سوئگ کے پاس ورکر رجسٹری ہے جو ورکرز کی اقسام کے مطابق جاب کے ناموں کا نقشہ بناتی ہے۔

registry := workers.NewWorkerRegistry()
registry.RegisterWorker(&EmailWorker{})

بعد میں، جب آپ اپنی ٹاسک لائن میں کچھ ایسا دیکھتے ہیں: kind = 'send_email'سوئگ رجسٹرڈ کارکنوں کو ڈھونڈتا ہے اور انہیں چلاتا ہے۔

یہاں ایک لطیف ہم آہنگی کا مسئلہ ہے۔ جب درست معلومات رجسٹری میں محفوظ کی جاتی ہیں۔ &EmailWorker{} پوائنٹرز کو استعمال کرنے اور ان کو تمام آپریشنز میں دوبارہ استعمال کرنے سے، متعدد گوروٹینز بیک وقت پے لوڈ کو ایک ہی Go ویلیو پر اتار سکتے ہیں۔

سوئگ اندرونی طور پر فیکٹری کے نقطہ نظر کو استعمال کرکے اس کو روکتا ہے۔ رجسٹریشن کارکن کی قسم کو پکڑ لیتی ہے اور JSON کے بے نقاب ہونے سے پہلے ہر دعوی کردہ کام کو کارکن کی ایک نئی مثال ملتی ہے۔ API آسان ہے، لیکن ہڈ کے نیچے Swig نئے APIs بناتا ہے۔ EmailWorker ہر کام کے لیے۔ یہ ایک مفید گو پیٹرن ہے۔ اپنے عوامی API کو سادہ رکھتے ہوئے اپنی داخلی لائف سائیکل کو مزید محفوظ بنائیں۔

ٹاسک کیسے شامل کریں۔

صارف کی طرف سے ٹاسک کو شامل کرنے سے ایسا لگتا ہے:

err := swigClient.AddJob(ctx, &EmailWorker{
    To:      "user@example.com",
    Subject: "Welcome!",
    Body:    "Thanks for signing up.",
})

سوئگ کا اندرونی عمل تقریباً درج ذیل ہے:

argsJSON, err := json.Marshal(workerWithArgs)
if err != nil {
    return err
}

_, err = db.ExecContext(ctx, `
    INSERT INTO swig_jobs (kind, queue, payload, priority, scheduled_for, status)
    VALUES (\(1, \)2, \(3, \)4, $5, 'pending')
`, jobName, queue, argsJSON, priority, runAt)

لین دین کے اندر کاموں کی قطار کیسے لگائی جائے۔

آپ کے کام کے لیے PostgreSQL استعمال کرنے کی ایک بہترین وجہ لین دین کی قطار ہے۔

تصور کریں کہ ایک صارف سائن اپ کرتا ہے۔ میں ایک صارف کو داخل کرنا چاہتا ہوں اور قطار میں ایک خوش آمدید ای میل شامل کرنا چاہتا ہوں۔ اگر یہ چیزیں الگ الگ ہوتی ہیں تو، متضاد ریاستوں کا نتیجہ ہو سکتا ہے. لین دین میں، یا تو دونوں کامیاب ہوتے ہیں یا دونوں ناکام ہوتے ہیں۔

tx, err := pool.Begin(ctx)
if err != nil {
    return err
}
defer tx.Rollback(ctx)

_, err = tx.Exec(ctx, `INSERT INTO users (email) VALUES ($1)`, email)
if err != nil {
    return err
}

err = swigClient.AddJobWithTx(ctx, tx, &EmailWorker{
    To:      email,
    Subject: "Welcome!",
    Body:    "Thanks for joining.",
})
if err != nil {
    return err
}

return tx.Commit(ctx)

جب ایک ٹرانزیکشن کو رول بیک کیا جاتا ہے، کوئی صارف نہیں بنایا جاتا ہے اور قطار میں کوئی ٹاسک شامل نہیں ہوتا ہے۔ اگر ڈیٹا بیس اور قطار الگ الگ نظام ہیں تو اس کی ضمانت دینا بہت زیادہ مشکل ہے۔

متعدد کارکنوں کو محفوظ طریقے سے ہینڈل کرنے کا طریقہ

قطاریں اس وقت دلچسپ ہو جاتی ہیں جب بہت سے کارکن ایک ساتھ چل رہے ہوتے ہیں۔ تصور کریں کہ تینوں کارکن اگلے زیر التواء آپریشن کے لیے PostgreSQL کی درخواست کر رہے ہیں۔ آپ نہیں چاہتے کہ تینوں لوگ ایک جیسے کاموں کو سنبھالیں۔

بولی اپروچ میں ریس کی شرط ہوتی ہے۔ دو کارکنوں میں سے ایک اپ ڈیٹ کرنے سے پہلے ایک ہی کام کو منتخب کر سکتا ہے۔

اپ ڈیٹس کو چھوڑنے کے لیے PostgreSQL مقفل ہے۔

PostgreSQL کسی ٹرانزیکشن کے اندر منتخب قطاروں کو لاک کر سکتا ہے۔ FOR UPDATE اس کا مطلب ہے "اس قطار کو لاک کریں کیونکہ ہم اسے اپ ڈیٹ کرنے جا رہے ہیں۔” SKIP LOCKED اس کا مطلب ہے "اگر کسی دوسرے کارکن کے پاس پہلے سے ہی قطار بند ہے، تو اس قطار کو چھوڑ دیں اور دوسرے کارکن کو تلاش کریں۔”

یہ قطاروں کے لیے بہترین ہے۔

کسی مرکزی کوآرڈینیٹر کی ضرورت نہیں۔ سوئگ ایٹم اپ ڈیٹ پیٹرن کا استعمال کرتا ہے۔

UPDATE swig_jobs
SET status="processing",
    instance_id = $1,
    worker_id = $2,
    locked_at = NOW(),
    attempts = attempts + 1
WHERE id = (
  SELECT id
  FROM swig_jobs
  WHERE status="pending"
    AND scheduled_for <= NOW()
  ORDER BY priority DESC, created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
RETURNING id, kind, payload;

یہ استفسار زیر التواء کاموں کو تلاش کرتا ہے، پہلے سے مقفل کاموں کو چھوڑ دیتا ہے، انہیں پروسیسنگ کے طور پر نشان زد کرتا ہے، اس کارکن کو ریکارڈ کرتا ہے جس نے ٹاسک کی درخواست کی تھی، اور ٹاسک کا ڈیٹا واپس کر دیتی ہے۔ یہ سب جوہری طور پر ہوتا ہے۔ کارکن کبھی الگ الگ کام نہیں کرتے۔ SELECT اور بعد میں امید ہے UPDATE یہ اب بھی محفوظ ہے۔

ہم وقتی کارکنوں کے لیے گوروٹینز کا استعمال کیسے کریں۔

سوئگ ورکر لوپ کو گوروٹین کے طور پر شروع کرتا ہے۔

for i := 0; i < maxWorkers; i++ {
    go s.startWorker(ctx, queueType)
}

ہر کارکن آزادانہ طور پر چلتا ہے۔ PostgreSQL کوآرڈینیٹ کرتا ہے کہ ہر کارکن کو کون سے کام ملتے ہیں۔ گو کنکرنسی کو ہینڈل کرنے کے لیے گوروٹینز کا استعمال کرتا ہے، جبکہ PostgreSQL محفوظ آپریشن کی درخواستوں کو ہینڈل کرنے کے لیے تالے کا استعمال کرتا ہے۔

خوبصورت شٹ ڈاؤن کو کیسے ہینڈل کریں۔

جب کوئی سروس ختم ہو جاتی ہے، کارکنوں کو اس کے مکمل ہونے کا انتظار کرنا چاہیے۔ گوتھ sync.WaitGroup مددگار:

var wg sync.WaitGroup

wg.Add(1)
go func() {
    defer wg.Done()
    processJobs()
}()

wg.Wait()

میں سوئگ بھی استعمال کرتا ہوں۔ sync.Once برطرفی کو بے اختیار بناتا ہے۔ کال کرنا Stop آپ کو ایک سے زیادہ بار گھبرانے کی ضرورت نہیں ہے کیونکہ آپ کا ڈوپلیکس چینل بند ہے۔ شٹ ڈاؤن پاتھ اکثر پروڈکشن سسٹم کو ہیپی پاتھ ڈیمو سے مختلف برتاؤ کرنے کا سبب بنتے ہیں۔

LISTEN/NOTIFY کے ساتھ کارکن کو کیسے جگایا جائے۔

اگر آپ کے کارکن مسلسل کام کے لیے ڈیٹا بیس کی پولنگ کر رہے ہیں، اگر قطار خالی ہے تو وسائل ضائع ہو رہے ہیں۔ PostgreSQL کے پاس ہے۔ LISTEN/NOTIFY اس مسئلے کو حل کرنے کے لیے۔

ایک کنکشن ایک چینل پر سن سکتا ہے۔

LISTEN swig_jobs;

آپ دوسرے سیشنز سے اطلاعات بھیج سکتے ہیں۔

NOTIFY swig_jobs, '{"id":"job-id"}';

Swig ایک ٹرگر بناتا ہے تاکہ PostgreSQL ٹاسک داخل کرنے کے بعد ایک اطلاع بھیج سکے۔ دفتری کارکن سوتے ہیں جب کوئی کام نہیں ہوتا اور جب نیا کام آتا ہے تو جاگ جاتے ہیں۔

یہاں کچھ اہم PostgreSQL تفصیلات ہیں: LISTEN سیشن کا دائرہ کار۔ کارکنوں کو اسی ڈیٹا بیس سیشن میں اطلاعات کا انتظار کرنا چاہیے جس پر وہ چلتے ہیں۔ LISTEN. Swig ہر کارکن کے لیے ایک وقف سامعین بنا کر اس کو سنبھالتا ہے جو اپنی زندگی کے دوران ایک ڈیٹا بیس سیشن کا مالک ہوتا ہے۔

یہ بیک اینڈ انجینئرنگ کا ایک عام سبق ہے۔ کنکشن پولز جیسے تجرید کارآمد ہیں، لیکن ڈیٹا بیس کی کچھ خصوصیات مخصوص کنکشن کے لائف سائیکل پر منحصر ہوتی ہیں۔

ایڈوائزری لاکنگ کا استعمال کرتے ہوئے لیڈر کا انتخاب کیسے کریں۔

کچھ قطار کی دیکھ بھال کے کام، جیسے کہ ناکام کاموں کی دوبارہ کوشش کرنا، پرانے کاموں کو بازیافت کرنا، یا پرانے ریکارڈ کو صاف کرنا، ایک وقت میں صرف ایک مثال پر چلنا چاہیے۔

Swig اس مقصد کے لیے PostgreSQL ایڈوائزری لاکنگ کا استعمال کرتا ہے۔

SELECT pg_try_advisory_lock($1);

اگر نتیجہ درست ہے تو، وہ سوئگ مثال لیڈر بن جاتا ہے۔ مشاورتی تالے بھی سیشن کے دائرہ کار میں ہیں، لہذا Swig قیادت کے لیے ایک وقف شدہ مشاورتی لاک کنکشن استعمال کرتا ہے۔ جب وہ سیشن ختم ہوتا ہے، PostgreSQL لاک کو جاری کرتا ہے اور ایک اور مثال اس پر قبضہ کر سکتی ہے۔ ZooKeeper یا etcd کے بغیر سادہ فیل اوور ممکن ہے۔

ناکام کاموں کو کیسے ہینڈل کریں۔

اگر کارکن غلطی لوٹاتا ہے، تو Swig غلطی کو لاگ کرتا ہے اور یا تو کام کی دوبارہ کوشش کرتا ہے یا اسے ناکام کے طور پر نشان زد کرتا ہے۔

UPDATE swig_jobs
SET status = CASE
    WHEN attempts >= max_attempts THEN 'failed'
    ELSE 'pending'
  END,
  last_error = $2,
  last_error_at = NOW()
WHERE id = $1;

ٹرانسفر سیمنٹکس پر ایک نوٹ

آپ یہ کہنا چاہیں گے کہ ٹاسک کیو ایک ٹاسک کو بالکل ایک بار پروسس کرتی ہے۔ تقسیم شدہ نظام میں، یہ ایک خطرناک دلیل ہے۔

درج ذیل منظر نامے پر غور کریں:

1. ایک ملازم ای میل بھیجتا ہے۔

2. ٹاسک مکمل کے بطور نشان زد ہونے سے پہلے ہی کارکن کریش ہو جاتا ہے۔

3. آپریشن کی دوبارہ کوشش کی جائے گی۔

4. آپ کا ای میل دوبارہ بھیجا جا سکتا ہے۔

درست تفصیل یہ ہے کہ سوئگ ایٹم بلنگ اور کم از کم ایک بار پروسیسنگ پیش کرتا ہے۔ کارکنان کو کمزور ہونا چاہیے کیونکہ آپریشنز کی دوبارہ کوشش کی جا سکتی ہے۔ ایک ہی کام کو ایک سے زیادہ بار چلانے سے وہی نتائج برآمد ہوتے ہیں جیسے ایک بار چلانے سے۔

ڈیٹا بیس ڈرائیوروں کا خلاصہ کیسے کریں۔

سوئگ دونوں کو سپورٹ کرتا ہے۔ pgx اور database/sql ڈرائیور انٹرفیس کے ذریعے:

type Driver interface {
    Exec(ctx context.Context, sql string, args ...interface{}) error
    Query(ctx context.Context, sql string, args ...interface{}) (Rows, error)
    QueryRow(ctx context.Context, sql string, args ...interface{}) Row
    WithTx(ctx context.Context, fn func(tx Transaction) error) error
    NewListener(ctx context.Context, channel string) (Listener, error)
    TryAdvisoryLock(ctx context.Context, lockID int64) (AdvisoryLock, bool, error)
}

بنیادی کیو کوڈ صرف طرز عمل پر انحصار کرتا ہے نہ کہ مخصوص لائبریریوں پر۔ یہ ایک عام گو ڈیزائن ہے۔ بنیادی پیکجوں کے لیے مطلوبہ رویے کی وضاحت کریں، مخصوص انحصار کے لیے چھوٹے اڈاپٹر لکھیں، اور بنیادی منطق کو آزاد رکھیں۔

نتیجہ

PostgreSQL سپورٹ کی قطاریں تمام سسٹمز کا جواب نہیں ہیں۔ اگر آپ کو بڑے پیمانے پر ایونٹ اسٹریمنگ کی ضرورت ہے تو، کافکا بہتر فٹ ہو سکتا ہے۔ اگر آپ کو پیچیدہ روٹنگ کی ضرورت ہے تو، RabbitMQ بہتر ہو سکتا ہے۔

تاہم، بہت سی گو ایپلیکیشنز کے لیے PostgreSQL پہلے سے موجود ہے۔ Swig دکھاتا ہے کہ آپ ایک چھوٹے Go API اور کچھ PostgreSQL خصوصیات کا استعمال کرتے ہوئے کتنی دور جا سکتے ہیں۔

• کام کو میز پر محفوظ کریں۔

• جوہری طور پر کاموں کا دعوی کریں۔ FOR UPDATE SKIP LOCKED

• اپنے سرشار عملے کو بیدار کریں۔ LISTEN/NOTIFY سیشن

• مشاورتی لاک ڈاؤن کے ذریعے قیادت کی صف بندی کرنا

• ایپ ڈیٹا اور آپریشنز کو لین دین کے مطابق رکھیں

• گوروٹینز اور سیاق و سباق کا استعمال کرتے ہوئے ورکر لائف سائیکل مینجمنٹ

یہ مجموعہ بیک گراؤنڈ پروسیسنگ کے لیے ایک ٹھوس بنیاد فراہم کرتا ہے اور یہ سیکھنے کے لیے ایک بہترین پروجیکٹ بناتا ہے کہ Go اور PostgreSQL کس طرح پروڈکشن سسٹم میں ایک ساتھ کام کرتے ہیں۔ آپ github.com/glamboyosa/swig پر مکمل سورس کوڈ دریافت کر سکتے ہیں۔