रियल-टाइम आपातकालीन प्रतिक्रिया प्रणाली: Upstash, Redis, और QStash का लाभ उठाना

आज के लेख में हम बात करने जा रहे हैं कि कैसे आप Upstash का लाभ उठा सकते हैं ताकि Redis का उपयोग करके किसी देश के शेल्टर मैप के बारे में जानकारी को सुरक्षित रूप से स्टोर और एक्सेस किया जा सके, और QStash के माध्यम से डेटाबेस को रियलटाइम में अपडेट किया जा सके।

परिचय

वर्तमान वैश्विक संदर्भ में, प्राकृतिक आपदाएं और सैन्य खतरे अधिक से अधिक प्रचलित होते जा रहे हैं। इसलिए सामाजिक सेवाओं के क्षेत्र में डिजिटलीकरण की आवश्यकता भी है।

AMBER अलर्ट जैसे आपातकालीन प्रसारण प्रणाली से लेकर COVID-19 ट्रैकिंग ऐप और SOS सिस्टम तक, हमने किसी भी प्रकार के खतरनाक परिदृश्य के जवाब में उपयोग की जा रही प्रौद्योगिकियों की एक विस्तृत श्रृंखला देखी है जो एक देश को प्रभावित करती है।

अब, हम इस बात पर एक नज़र डालने जा रहे हैं कि Redis और सर्वरलेस वर्कलोड कैसे एक रियलटाइम आपातकालीन प्रतिक्रिया प्रणाली के निर्माण में महत्वपूर्ण भूमिका निभा सकते हैं जो नागरिकों को निकटतम बंकर खोजने में मदद करती है, साथ ही उन्हें क्षमता, सुविधाओं (जैसे विकलांग व्यक्तियों की सुविधाएं) और संसाधनों (पानी, बिजली, दवा आदि) के बारे में सूचित करती है।

Project Cloud4 के सौजन्य से

सर्वरलेस क्यों?

तथाकथित सर्वरलेस अवधारणा पिछले वर्षों में डेवलपर्स के बीच लोकप्रिय हुई है। हमने स्टार्टअप की संख्या में वृद्धि देखी है जो इस आर्किटेक्चर का पालन करना चुनते हैं और बड़े निगमों में भी बढ़ी हुई गोद लेने देखी है।

विशेष रूप से राज्य अभिनेताओं के बारे में बात करते समय, एक तीव्र विकास वातावरण और ऑटो-प्रबंधित सेवाएं आपातकालीन प्रतिक्रिया प्रणाली के निर्माण की जटिलता और ओवरहेड को काफी कम कर सकती हैं। हमें दो अन्य कारकों को भी ध्यान में रखना होगा:

1. बजट: यदि कोई देश किसी उभरती आपदा से नहीं गुजरता है, तो क्या निर्णय लेने वाली भूमिका में कोई व्यक्ति अप्रयुक्त कम्प्यूटिंग पावर के लिए भुगतान को मंजूरी दे पाएगा? मुझे संदेह है।
2. ट्रैफिक स्पाइक्स: कल्पना करें कि एक अलार्म ट्रिगर होता है और लाखों लोग निकटतम शेल्टर खोजने के लिए वेब प्लेटफॉर्म तक पहुंचते हैं। आपका REST API इस अचानक rps (रिक्वेस्ट-पर-सेकंड) वृद्धि को कैसे संभालेगा? आवश्यक रियलटाइम घटकों के बारे में क्या?

ये सभी अलग-अलग सवाल Upstash और Ably जैसे वास्तविक सर्वरलेस प्लेटफॉर्म का उपयोग करके उत्तर दिए जा सकते हैं जो भारी-भरकम सर्वर को शक्ति प्रदान करते हैं जो ऑटो-स्केल करते हैं और केवल आपके द्वारा उपयोग किए जा रहे संसाधनों के लिए शुल्क लेते हैं।

Redis क्यों?

हमारे प्रोजेक्ट की डेटा आवश्यकताओं में विभिन्न एल्गोरिदमिक ऑपरेशन शामिल हैं जिन्हें उच्चतम संभव गति से किया जाना चाहिए। शेल्टर की जानकारी का प्रतिनिधित्व करने के लिए बेसिक डेटा संरचनाओं से लेकर किसी स्थान पर उपलब्ध लोगों को विभिन्न मानदंडों द्वारा सॉर्ट करने का एक सरल तरीका होने तक, Redis हमें NoSQL डेटाबेस के लचीलेपन को बनाए रखने की अनुमति देता है, जबकि विकास को सरल और तेज करने के लिए विभिन्न फंक्शन भी प्रदान करता है।

QStash क्यों?

पारंपरिक मैसेज क्यू इवेंट-ड्रिवन सिस्टम को आर्किटेक्ट करने का एक ठोस तरीका प्रदान करते हैं, लेकिन एक चेतावनी है: उनमें से अधिकांश पूरी तरह से AMPQ जैसे स्टेटफुल प्रोटोकॉल पर निर्भर करते हैं, जिसका अर्थ है कि वे सर्वरलेस फंक्शन जैसे शॉर्ट-रनिंग वातावरण में उपयोग के लिए तैयार नहीं हैं।

QStash HTTP का उपयोग करके अनुरोध करने की अनुमति देकर इस समस्या को हल करता है, जो आमतौर पर ऐसे वातावरण में उपयोग किया जाने वाला स्टेटलेस प्रोटोकॉल है। वेबहुक के साथ संयोजन करके, हम डेटाबेस से और डेटाबेस में डेटा को अपडेट और लाने के लिए रियलटाइम पाइपलाइन बना सकते हैं।

आवश्यकताएं

नोट: यदि आप केवल सैंपल के माध्यम से देखना चाहते हैं, तो आवश्यकताएं और सेटअप अनुभाग छोड़ दें। वे दिखाने के लिए हैं कि हम क्या उपयोग कर रहे हैं और कैसे।

यदि आप इस तरह की प्रणाली को स्वयं बनाना चाहते हैं, तो आपको निम्नलिखित की आवश्यकता होगी:

• एक Upstash अकाउंट, जिससे आप एक Redis डेटाबेस बनाएंगे और एक QStash एंडपॉइंट या टॉपिक का उपयोग करेंगे;
• एक Ably अकाउंट और एक वेबहुक इंटीग्रेशन सेट अप
• एक Next.js प्रोजेक्ट;
• ngrok जैसी टनलिंग सेवा यदि आप स्थानीय अनुरोधों को इंटरनेट-उपलब्ध URL पर प्रॉक्सी करना चाहते हैं;
• कोई भी पैकेज मैनेजर जो अनुरोधित लाइब्रेरी का समर्थन करता है। इस लेख में npm का उपयोग किया जाएगा, लेकिन यह अनिवार्य नहीं है।

नोट: यह लेख उक्त प्रौद्योगिकियों के उपयोग को हमारे एप्लिकेशन की आर्किटेक्चर के संदर्भ में प्रदर्शित करने के लिए कुछ बुनियादी प्रूफ-ऑफ-कॉन्सेप्ट सैंपल प्रदान करेगा। दिया गया कोड प्रोडक्शन रेडी नहीं है और बेहतर पढ़ने के लिए सरलीकृत और छोटा किया गया था। यदि आप डेप्लॉय करना चाहते हैं तो आवश्यक संशोधन करना सुनिश्चित करें (अपवाद हैंडलिंग, सुरक्षा, आदि)

सेटअप

सर्वरलेस फंक्शन

हम Next.js के एज API रूट का उपयोग सर्वरलेस वर्कलोड को यूजर के स्थान के करीब चलाने के लिए करेंगे।

Next.js प्रोजेक्ट बनाने के लिए पैरेंट डायरेक्टरी में npx create-next-app@latest <your-app-name> चलाएं। उसके बाद आप डेवलपमेंट सर्वर शुरू करने के लिए npm run dev, प्रोडक्शन बंडल बनाने के लिए npm run build और प्रोडक्शन सर्वर शुरू करने के लिए npm run start चला सकते हैं।

Next.js API रूट के लिए डिफ़ॉल्ट रूप से नोड एनवायरनमेंट का उपयोग करता है। हम इसे दो तरीकों से बदल सकते हैं:

1. प्रति-रूट दृष्टिकोण। वांछित रूट में निम्नलिखित एक्सपोर्ट जोड़ें:

   export const config = { runtime: "experimental-edge", };

2. वैश्विक दृष्टिकोण। एज को डिफ़ॉल्ट रनटाइम बनाने के लिए, अपने next.config.js फाइल में निम्नलिखित जोड़ें:

   const nextConfig = {
     // ...
     experimental: { runtime: "experimental-edge", },
     // ...
   };

Upstash

Upstash प्रोवाइडर बनाने के लिए इस गाइड का पालन करें।

QStash-रिसीवर रूट सेटअप करने के लिए इस गाइड का पालन करें। ध्यान दें कि Ably हमें वेबहुक मैसेज एन्कोडिंग के लिए दो विकल्प प्रदान करता है, JSON और MessagePack। यदि आप पूर्व का उपयोग करना चाहते हैं, तो आपको संभावित एन्क्रिप्शन संगतता समस्याओं के साथ काम करने के लिए JWT के बजाय ऑथराइज़ेशन हेडर का उपयोग करने की आवश्यकता हो सकती है। सरलता के लिए हम JSON पर टिके रहेंगे।

Ably

रियलटाइम कार्यक्षमता के लिए, हम Ably के प्रोटोकॉल का उपयोग करेंगे, जो जहां संभव हो WebSockets पर डिफ़ॉल्ट होता है। शुरू करने के लिए इस गाइड का पालन करें और, चूंकि हम Next.js का उपयोग कर रहे हैं, आप @ably-labs/react-hooks npm पैकेज देख सकते हैं।

हमें अपने QStash URL पर इंगित करने के लिए एक वेबहुक इंटीग्रेशन भी सेटअप करना चाहिए, और कोई भी आवश्यक हेडर जोड़ें।

यदि आप प्रोडक्शन में जा रहे हैं, तो प्रमाणीकरण और सुरक्षा भी जांचें।

वैकल्पिक: स्थानीय टनलिंग

ngrok के साथ शुरू करने के लिए इस गाइड का पालन करें

आर्किटेक्चर

फ्लो

हमारे एप्लिकेशन के फ्लो को बेहतर ढंग से समझने के लिए, आइए इस आरेख को देखें (excalidraw.com के साथ बनाया गया):

जैसा कि आप देख सकते हैं हमने दो प्रकार के यूजर्स को परिभाषित किया है:

1. नागरिक, जो शेल्टर या स्थान की जानकारी तक पहुंच सकता है, और बंकर पर जाने के अपने इरादे की घोषणा कर सकता है
2. एडमिन, जो बंकर के लॉजिस्टिक्स डेटा को संशोधित कर सकता है और उपलब्धता को संशोधित कर सकता है (उदाहरण के लिए, पुष्टि करें कि कोई व्यक्ति/परिवार स्थान पर पहुंच गया है)

हम डेटा को रियलटाइम में उपलब्ध कराने की कोशिश कर रहे हैं जबकि फ्रंटएंड और बैकएंड को यथासंभव डिकॉपल्ड रखते हैं, इसलिए हम Ably चैनल का उपयोग क्लाइंट के साथ संचार करने और हर बार उपलब्धता बदलने पर वेबहुक ट्रिगर करने के लिए करेंगे।

इसके अलावा, हम बैकएंड से संदेश प्रकाशित करने के लिए Ably के REST API का उपयोग करेंगे, क्योंकि हमें किसी भी प्रकार के स्टेटफुल कनेक्शन का उपयोग नहीं करना चाहिए।

डेटा

वर्तमान में हमें दो मुख्य डेटा प्रकार संग्रहीत करने हैं:

• एक शेल्टर की जानकारी, जो Redis हैश का रूप ले सकती है और इसमें निम्नलिखित प्रॉपर्टी हो सकती हैं:

  • कुंजी का नाम country-city-number के रूप में (उदाहरण: RO-CJ-01)
  • उपलब्धता (उदाहरण: 300)
  • सुविधाएं (उदाहरण: ["disabled persons special acces", "counseling"])
  • संसाधन:

    { resource: quantity, or resource: list ... }

    उदाहरण:

    { "water": "200 liters", "medicine": ["insuline", ...] }

  • बिजली: yes/no
  • हीटिंग: yes/no
  • स्थिति: [longitude, latitude] या

    { longitude: number, latitude: number }

  • _id: हम इसे रैंडमली जनरेट करेंगे

• एक स्थान की जानकारी

  जबकि हम कर सकते हैं निर्दिष्ट स्थान के लिए उपलब्ध शेल्टर खोजने के लिए एक नेस्टेड क्वेरी करें, यह समय की कीमत पर और बहुत बड़े डेटा लोड के साथ एक बेहतर विचार हो सकता है कि उन्हें क्वेरी को सरल और ऑप्टिमाइज़ करने के लिए एक अलग डेटा संरचना के रूप में संग्रहीत किया जाए। ऐसा करने के लिए, हम एक Redis सेट का उपयोग कर सकते हैं और एलिमेंट का नाम <geographical-unit>-<name> (उदाहरण: country-RO या city-CJ) के रूप में रख सकते हैं। इस तरह हम डुप्लीकेशन भी रोक रहे हैं

  उदाहरण:

  city-CJ : ["RO-CJ-01", "RO-CJ-02", "RO-CJ-03"]

लेकिन अभी भी एक समस्या बनी हुई है: हम नागरिक के शेल्टर पर जाने के इरादे और शेल्टर के एडमिन पुष्टिकरण द्वारा ट्रिगर किए गए वास्तविक ऑक्यूपेंसी अपडेट के बीच कैसे अंतर कर सकते हैं? हम इसे दो तरीकों से कर सकते हैं:

1. लगातार अपडेट करें शेल्टर के उपलब्धता कुंजी: एक यूजर अपने आने की घोषणा करता है (अकेले या परिवार के साथ/आदि) => हम x से बढ़ाते हैं; एडमिन को पता चलता है कि पुष्टिकरण मान्य नहीं है => हम x से घटाते हैं (या -x से बढ़ाते हैं)

   यहां समस्या यह है कि एडमिन को सच्चाई के स्रोत के रूप में कार्य करना होगा और नागरिक के स्थान का ट्रैक रखना होगा; साथ ही, शेल्टर के डेटा पर तुरंत भरोसा नहीं किया जा सकता

2. एक अलग स्ट्रिंग कुंजी बनाएं नाम shelter-"availability" (उदाहरण: RO-CJ-01-availability) और रियलटाइम-अपडेटेड मान संग्रहीत करें। इस तरह हम रियलटाइम में अपडेट कर सकते हैं, और अपने हैश के उपलब्धता कुंजी को सच्चाई के स्रोत के रूप में रख सकते हैं।

   ध्यान दें कि क्लाइंट साइड पर हम हैश और स्ट्रिंग कुंजी दोनों को लाएंगे, और उन्हें वास्तविक उपलब्धता और अनुमानित के रूप में प्रस्तुत करेंगे। एक वैकल्पिक दृष्टिकोण केवल स्ट्रिंग लाना होगा और जरूरत पड़ने पर सच्चाई के स्रोत पर वापस आना होगा। हालांकि यह नेटवर्क लोड को कम करेगा, एडमिन को लगातार डेटा सत्यापित करने की आवश्यकता होगी (पहले परिदृश्य की तरह) और, वास्तव में कम लाने के लिए, हमें शेल्टर के उपलब्धता कुंजी को अलग से संग्रहीत करने की आवश्यकता होगी (याद रखें, हमें अभी भी अन्य जानकारी प्राप्त करने की आवश्यकता है!)।

सॉर्टिंग

Redis डेटा प्रकार का लाभ उठाएं जिसे सॉर्टेड सेट कहा जाता है। मान लें कि हम किसी स्थान पर बंकर को उपलब्धता, सुविधाओं या उपलब्ध संसाधनों द्वारा सॉर्ट करना चाहते हैं: जैसा कि मैंने पहले उल्लेख किया है, हम एक नेस्टेड क्वेरी कर सकते हैं लेकिन समय की कीमत पर और बहुत बड़े डेटा लोड के साथ। एक बेहतर समाधान हर फ़िल्टरिंग मानदंड के लिए सॉर्टेड सेट बनाना होगा (हम उन्हें <geographical-unit>-<name>-<criteria> नाम दे सकते हैं, जैसे city-CJ-availability या country-RO-food)

उदाहरण: city-B-availability

इस उदाहरण में, उपलब्धता स्कोर की गणना total seats - current occupation के रूप में की गई थी।

उदाहरण

हम अपने API और क्लाइंट के व्यवहार को प्रदर्शित करने के लिए कुछ बुनियादी कोड लिख सकते हैं

एंडपॉइंट्स

मुख्य रूप से, हमें होना चाहिए:

• एक डेटा एंडपॉइंट जो क्लाइंट को किसी भी अनुरोधित जानकारी की सेवा करेगा और
• हमारे डेटा प्रकार बनाने या अपडेट करने के लिए एक एंडपॉइंट

क्लाइंट

यूजर के स्थान को ट्रैक करने के बाद हम स्वचालित रूप से "availability" चैनल से जुड़ेंगे और एक संदेश प्रकाशित करेंगे यदि नागरिक बंकर पर जाने का इरादा रखता है।

सबसे पहले, /_app.js फाइल से कनेक्शन बनाएं:

import { useEffect, useState } from "react";
import "../styles/globals.css";
import { configureAbly } from "@ably-labs/react-hooks";
export default function App({ Component, pageProps }) {
  const [loaded, setLoaded] = useState(false);
  useEffect(() => {
    configureAbly({
      // प्रोडक्शन सिस्टम में, आपको प्रमाणीकरण कुंजी का उपयोग करना चाहिए
      key: process.env.NEXT_PUBLIC_ABLY_API_KEY,
    });
    setLoaded(true);
  }, []);
  if (!loaded) return <div>loading...</div>;
  return <Component {...pageProps} />;
}

और फिर किसी भी कंपोनेंट में चैनल से कनेक्ट करें जिसकी हमें आवश्यकता है:

import { useChannel } from "@ably-labs/react-hooks";
export default function Test() {
  const [availability] = useChannel("availability", (msg) => {
    console.log(msg);
  });
  return <></>;
}

डेटाबेस के साथ काम करना

नया डेटा जोड़ना

Redis में नया डेटा जोड़ने के लिए हम HSET, SET और SADD कमांड का उपयोग कर सकते हैं

export default async (req) => {
  let data = await req.json();
  if (data.type === "shelter") {
    // 'type' कुंजी को हटा दें क्योंकि यह अब आवश्यक नहीं है
    delete data.type;
    const { name: shelter, availability } = data;
    let shelterData = data;
    // एक रैंडम id जनरेट करें।
    shelterData._id = Math.random()
      .toString(36)
      .replace(/[^a-z]+/g, "")
      .substring(0, 7);
    // शेल्टर की जानकारी को हैश के रूप में संग्रहीत करें
    await redis.hset(shelter, shelterData);
    // रियलटाइम-अपडेटेड उपलब्धता को स्ट्रिंग के रूप में संग्रहीत करें
    await redis.set(shelter + "-availability", availability);
    return new Response("ok");
  } else if (data.type === "location") {
    const { name: location, shelters } = data;
    await redis.sadd(location, ...shelters);
    return new Response("ok");
  }
};

मौजूदा डेटा अपडेट करना

बेसिक UD (अपडेट-डिलीट) ऑपरेशन के अलावा, हम शेल्टर की उपलब्धता को संशोधित करने के लिए Redis INCRBY और HINCRBY कमांड का उपयोग कर सकते हैं।

यदि कोई नागरिक बंकर पर जाने के अपने इरादे की घोषणा करता है, तो हम क्लाइंट ऐप से एक संदेश प्रकाशित कर सकते हैं

availability.publish("update", {
  shelter: "RO-CJ-01",
  availability: 1, // या -x, यदि यूजर कैंसिल करता है।
});

आर्किटेक्चर में समझाए अनुसार, यह एक वेबहुक ट्रिगर करेगा जिससे हम डेटा ले सकते हैं और shelter-"availability" कुंजी को अपडेट कर सकते हैं।

await redis.incrby(shelter + "-availability", value);

यदि आप सर्वर से अपडेट कर रहे हैं (उदाहरण: एडमिन पुष्टिकरण), तो REST API का उपयोग करना न भूलें।

डेटा पुनर्प्राप्त करना

सर्वर पर, हम GET, SMEMBERS और HGETALL कमांड का उपयोग कर सकते हैं।

क्लाइंट पर, हम चैनल में संदेशों को सुन सकते हैं और तदनुसार स्टेट को अपडेट कर सकते हैं।

संक्षेप में

आज हमने देखा कि कैसे हम एक शक्तिशाली सर्वरलेस आर्किटेक्चर का लाभ उठाकर एक वास्तविक दुनिया आपातकालीन ट्रैकिंग ऐप बना सकते हैं। जबकि इसे पूरा करने के कई दृष्टिकोण हैं, मैं व्यक्तिगत रूप से इस तरह के फ्लो के साथ जाने की सलाह देता हूं क्योंकि सरलीकृत डेवलपर एक्सपीरियंस के कारण।

शायद आप एक वरिष्ठ डेवलपर हैं जो वितरित कंप्यूटिंग सिस्टम बनाने के आदी हैं और प्रबंधित सेवा की आवश्यकता महसूस करते हैं। या, आप एक शुरुआती हो सकते हैं लेकिन आपके पास एक विचार है जो संभावित रूप से दुनिया को बेहतर के लिए बदल सकता है। सही उपकरण ढूंढना हमेशा प्रक्रिया का एक अनिवार्य हिस्सा होता है।

मुझे बताएं कि आप इस लेख के बारे में क्या सोचते हैं, और यदि आपके कोई प्रश्न हैं तो बेझिझक मुझे LinkedIn पर संदेश दें या GitHub पर मेरे अन्य कोड देखें।