कोटा नीति

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं.
जानकारी

क्या

कोटा नीति का इस्तेमाल करके, अनुरोध मैसेज की संख्या को कॉन्फ़िगर करें. इससे यह तय किया जा सकता है कि एपीआई प्रॉक्सी, किसी समयावधि में कितने अनुरोध मैसेज स्वीकार कर सकती है. जैसे, एक मिनट, एक घंटा, एक दिन, एक हफ़्ता या एक महीना. एपीआई प्रॉक्सी को ऐक्सेस करने वाले सभी ऐप्लिकेशन के लिए, एक ही कोटा सेट किया जा सकता है. इसके अलावा, कोटा को इन आधारों पर भी सेट किया जा सकता है:

  • वह प्रॉडक्ट जिसमें एपीआई प्रॉक्सी शामिल है
  • एपीआई का अनुरोध करने वाला ऐप्लिकेशन
  • ऐप्लिकेशन डेवलपर
  • कई अन्य मानदंड

ट्रैफ़िक में अचानक होने वाली बढ़ोतरी से बचने के लिए, कोटा का इस्तेमाल न करें. इसके लिए, स्पाइक अरेस्ट नीति का इस्तेमाल करें. कीमत में अचानक बढ़ोतरी रोकने से जुड़ी नीति देखें.

वीडियो

इन वीडियो में, कोटा नीति के तहत कोटा मैनेज करने के बारे में बताया गया है:

शुरुआती जानकारी (New Edge)

शुरुआती जानकारी (क्लासिक एज)

डाइनैमिक कोटा

डिस्ट्रिब्यूटेड और सिंक्रोनस

मैसेज का वज़न

Calendar

रोलिंग विंडो

Flexi

शर्तों के साथ कोटा

फ़्लो वैरिएबल

गड़बड़ी ठीक करना

सैंपल

नीति के कोड के इन सैंपल में, कोटा की अवधि शुरू और खत्म करने का तरीका बताया गया है. इसके लिए:

ज़्यादा डाइनैमिक कोटा

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

डाइनैमिक कोटा की मदद से, एक ही कोटा नीति को कॉन्फ़िगर किया जा सकता है. यह कोटा नीति, कोटा नीति को भेजी गई जानकारी के आधार पर, कोटा की अलग-अलग सेटिंग लागू करती है. इस संदर्भ में, कोटा सेटिंग को "सेवा प्लान" भी कहा जाता है. डाइनैमिक कोटा, ऐप्लिकेशन के "सेवा प्लान" की जांच करता है. इसके बाद, उन सेटिंग को लागू करता है.

ध्यान दें: अगर किसी एलिमेंट के लिए वैल्यू और रेफ़रंस, दोनों दिए जाते हैं, तो रेफ़रंस को प्राथमिकता दी जाती है. अगर रेफ़रंस, रनटाइम पर हल नहीं होता है, तो वैल्यू का इस्तेमाल किया जाता है.

उदाहरण के लिए, एपीआई प्रॉडक्ट बनाते समय, आपके पास इस्तेमाल किए जा सकने वाले कोटे की सीमा, समय की इकाई, और इंटरवल सेट करने का विकल्प होता है. हालांकि, एपीआई प्रॉडक्ट पर इन वैल्यू को सेट करने से, एपीआई प्रॉक्सी में इनका इस्तेमाल करना ज़रूरी नहीं हो जाता. आपको एपीआई प्रॉक्सी में कोटा नीति भी जोड़नी होगी, जो इन वैल्यू को पढ़ती है. ज़्यादा जानकारी के लिए, एपीआई प्रॉडक्ट बनाना लेख पढ़ें.

ऊपर दिए गए उदाहरण में, कोटा नीति वाली एपीआई प्रॉक्सी, VerifyAPIKey नीति का इस्तेमाल करती है. इस नीति का नाम verify-api-key है. इसका इस्तेमाल, अनुरोध में पास की गई एपीआई कुंजी की पुष्टि करने के लिए किया जाता है. इसके बाद, कोटा नीति, VerifyAPIKey नीति से फ़्लो वैरिएबल ऐक्सेस करती है, ताकि एपीआई प्रॉडक्ट पर सेट की गई कोटा वैल्यू को पढ़ा जा सके. VerifyAPIKey फ़्लो वैरिएबल के बारे में ज़्यादा जानने के लिए, एपीआई पासकोड की पुष्टि करने वाली नीति देखें.

दूसरा विकल्प यह है कि अलग-अलग डेवलपर या ऐप्लिकेशन के लिए कस्टम एट्रिब्यूट सेट किए जाएं. इसके बाद, कोटा नीति में उन वैल्यू को पढ़ा जाए. उदाहरण के लिए, आपको हर डेवलपर के लिए कोटे की अलग-अलग वैल्यू सेट करनी हैं. इस मामले में, डेवलपर के लिए कस्टम एट्रिब्यूट सेट किए जाते हैं. इनमें सीमा, समय की इकाई, और इंटरवल शामिल होता है. इसके बाद, इन वैल्यू को कोटा नीति में इस तरह से रेफ़रंस करें:

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

इस उदाहरण में, VerifyAPIKey फ़्लो वैरिएबल का इस्तेमाल करके, डेवलपर के लिए सेट किए गए कस्टम एट्रिब्यूट का रेफ़रंस दिया गया है.

कोटा नीति के पैरामीटर सेट करने के लिए, किसी भी वैरिएबल का इस्तेमाल किया जा सकता है. ये वैरिएबल यहां से मिल सकते हैं:

  • फ़्लो वैरिएबल
  • एपीआई प्रॉडक्ट, ऐप्लिकेशन या डेवलपर की प्रॉपर्टी
  • की वैल्यू मैप (केवीएम)
  • हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर वगैरह

हर एपीआई प्रॉक्सी के लिए, कोटा नीति जोड़ी जा सकती है. यह नीति, सभी प्रॉक्सी में मौजूद अन्य सभी कोटा नीतियों की तरह ही वैरिएबल का रेफ़रंस देती है. इसके अलावा, कोटा नीति ऐसे वैरिएबल का रेफ़रंस भी दे सकती है जो उस नीति और प्रॉक्सी के लिए यूनीक हों.

शुरू होने का समय

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

अगर किसी कोटे के लिए type को calendar पर सेट किया गया है, तो आपको <StartTime> की वैल्यू साफ़ तौर पर तय करनी होगी. समय की वैल्यू, जीएमटी के हिसाब से होती है, न कि स्थानीय समय के हिसाब से. अगर आपने calendar टाइप की नीति के लिए <StartTime> वैल्यू नहीं दी है, तो Edge एक गड़बड़ी का मैसेज दिखाता है.

हर ऐप्लिकेशन के लिए कोटा काउंटर, <StartTime>, <Interval>, और <TimeUnit> वैल्यू के आधार पर रीफ़्रेश होता है. इस उदाहरण के लिए, कोटा 18 फ़रवरी, 2017 को सुबह 10:30 बजे GMT से गिनती शुरू करता है और हर पांच घंटे में रीफ़्रेश होता है. इसलिए, अगला रीफ़्रेश 18 फ़रवरी, 2017 को दोपहर 3:30 बजे GMT पर होगा.

ऐक्सेस काउंटर

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

एपीआई प्रॉक्सी के पास, कोटा नीति के ज़रिए सेट किए गए फ़्लो वैरिएबल का ऐक्सेस होता है. इन फ़्लो वैरिएबल को एपीआई प्रॉक्सी में ऐक्सेस किया जा सकता है. ऐसा इन कामों के लिए किया जा सकता है: शर्तों के हिसाब से प्रोसेसिंग करना, नीति की कोटे की सीमा के करीब पहुंचने पर उसकी निगरानी करना, किसी ऐप्लिकेशन को मौजूदा कोटा काउंटर दिखाना या अन्य वजहों से.

नीति के फ़्लो वैरिएबल को ऐक्सेस करने की सुविधा, नीतियों के name एट्रिब्यूट पर आधारित होती है. इसलिए, ऊपर दी गई QuotaPolicy नाम की नीति के फ़्लो वैरिएबल को इस फ़ॉर्म में ऐक्सेस किया जाता है:

  • ratelimit.QuotaPolicy.allowed.count: अनुमति वाली संख्या.
  • ratelimit.QuotaPolicy.used.count: काउंटर की मौजूदा वैल्यू.
  • ratelimit.QuotaPolicy.expiry.time: यूटीसी समय, जब काउंटर रीसेट होता है.

ऐसे कई अन्य फ़्लो वैरिएबल हैं जिन्हें ऐक्सेस किया जा सकता है. इनके बारे में यहां बताया गया है.

उदाहरण के लिए, Quota फ़्लो वैरिएबल की वैल्यू को रिस्पॉन्स हेडर के तौर पर दिखाने के लिए, AssignMessage नीति का इस्तेमाल किया जा सकता है. इसके लिए, यहां दिया गया कोड इस्तेमाल करें:

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

पहला अनुरोध

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

इस सैंपल कोड का इस्तेमाल करके, हर घंटे 10,000 कॉल का कोटा लागू करें. यह नीति, हर घंटे की शुरुआत में कोटा काउंटर को रीसेट करती है. अगर काउंटर, एक घंटे के खत्म होने से पहले 10,000 कॉल के कोटे तक पहुंच जाता है, तो 10,000 से ज़्यादा कॉल अस्वीकार कर दिए जाते हैं.

उदाहरण के लिए, अगर काउंटर 2017-07-08 07:00:00 से शुरू होता है, तो यह 2017-07-08 08:00:00 (शुरू होने के समय से एक घंटे बाद) पर रीसेट होकर 0 हो जाता है. अगर पहला मैसेज 2017-07-08 07:35:28 पर मिलता है और मैसेज की संख्या 2017-07-08 08:00:00 से पहले 10,000 तक पहुंच जाती है, तो इसके बाद किए जाने वाले कॉल अस्वीकार कर दिए जाते हैं. ऐसा तब तक होता है, जब तक कि हर घंटे की शुरुआत में कॉल की संख्या रीसेट नहीं हो जाती.

काउंटर रीसेट होने का समय, <Interval> और <TimeUnit> के कॉम्बिनेशन पर आधारित होता है. उदाहरण के लिए, अगर आपने <TimeUnit> को एक घंटे के <Interval> के लिए 12 पर सेट किया है, तो काउंटर हर बारह घंटे में रीसेट हो जाएगा. <TimeUnit> को मिनट, घंटे, दिन, हफ़्ते या महीने के हिसाब से सेट किया जा सकता है.

इस नीति का रेफ़रंस, अपनी एपीआई प्रॉक्सी में कई जगहों पर दिया जा सकता है. उदाहरण के लिए, इसे प्रॉक्सी प्रीफ़्लो पर रखा जा सकता है, ताकि हर अनुरोध पर इसे लागू किया जा सके. इसके अलावा, इसे एपीआई प्रॉक्सी में कई फ़्लो पर भी रखा जा सकता है. अगर इस नीति का इस्तेमाल प्रॉक्सी में कई जगहों पर किया जाता है, तो यह एक ही काउंटर को बनाए रखता है. इस काउंटर को नीति के सभी इंस्टेंस अपडेट करते हैं.

इसके अलावा, अपनी एपीआई प्रॉक्सी में एक से ज़्यादा कोटा नीतियां तय की जा सकती हैं. हर कोटा नीति, name एट्रिब्यूट के आधार पर अपना काउंटर बनाए रखती है.

पहचानकर्ता सेट करना

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

डिफ़ॉल्ट रूप से, कोटा नीति एपीआई प्रॉक्सी के लिए एक काउंटर तय करती है. इससे कोई फ़र्क़ नहीं पड़ता कि अनुरोध किस ऑरिजिन से किया गया है. इसके अलावा, <Identifier> एट्रिब्यूट की वैल्यू के आधार पर अलग-अलग काउंटर बनाए रखने के लिए, कोटा नीति के साथ <Identifier> एट्रिब्यूट का इस्तेमाल किया जा सकता है.

उदाहरण के लिए, हर क्लाइंट आईडी के लिए अलग-अलग काउंटर तय करने के लिए, <Identifier> टैग का इस्तेमाल करें. आपके प्रॉक्सी को किए गए अनुरोध पर, क्लाइंट ऐप्लिकेशन clientID वाला हेडर पास करता है. जैसा कि ऊपर दिए गए उदाहरण में दिखाया गया है.

<Identifier> एट्रिब्यूट के लिए, किसी भी फ़्लो वैरिएबल की जानकारी दी जा सकती है. उदाहरण के लिए, यह बताया जा सकता है कि id नाम के क्वेरी पैरामीटर में यूनीक आइडेंटिफ़ायर शामिल है:

<Identifier ref="request.queryparam.id"/>

अगर एपीआई कुंजी की पुष्टि करने के लिए VerifyAPIKey नीति या OAuth टोकन के साथ OAuthV2 नीतियों का इस्तेमाल किया जाता है, तो एपीआई कुंजी या टोकन में मौजूद जानकारी का इस्तेमाल करके, एक ही कोटा नीति के लिए अलग-अलग काउंटर तय किए जा सकते हैं. उदाहरण के लिए, यहां दिया गया <Identifier> टैग, verify-api-key नाम की VerifyAPIKey नीति के client_id फ़्लो वैरिएबल का इस्तेमाल करता है:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

अब हर यूनीक client_id वैल्यू, कोटा नीति में अपना काउंटर तय करती है.

कक्षा

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

क्लास पर आधारित कोटा की गिनती का इस्तेमाल करके, कोटा की सीमाओं को डाइनैमिक तौर पर सेट किया जा सकता है. इस उदाहरण में, कोटा की सीमा इस बात पर निर्भर करती है कि हर अनुरोध के साथ developer_segment हेडर की कौनसी वैल्यू पास की गई है. उस वैरिएबल की वैल्यू platinum या silver हो सकती है. अगर हेडर में अमान्य वैल्यू है, तो नीति, कोटे के उल्लंघन की गड़बड़ी दिखाती है.


कोटा नीति के बारे में जानकारी

कोटा, अनुरोध मैसेज का एक ऐसा हिस्सा होता है जिसे एपीआई प्रॉक्सी, किसी समयावधि में हैंडल कर सकती है. जैसे, मिनट, घंटा, दिन, हफ़्ता या महीना. यह नीति, ऐसे काउंटर बनाए रखती है जो एपीआई प्रॉक्सी को मिले अनुरोधों की संख्या का हिसाब रखते हैं. इस सुविधा की मदद से, एपीआई उपलब्ध कराने वाली कंपनियां, किसी समयावधि में ऐप्लिकेशन से किए गए एपीआई कॉल की संख्या पर सीमाएं लागू कर सकती हैं. कोटा नीतियों का इस्तेमाल करके, उदाहरण के लिए, ऐप्लिकेशन के लिए हर मिनट में एक अनुरोध या हर महीने में 10,000 अनुरोध की सीमा तय की जा सकती है.

उदाहरण के लिए, अगर हर महीने के लिए कोटा 10,000 मैसेज तय किया गया है, तो 10,000वां मैसेज भेजने के बाद, दर सीमित करने की सुविधा शुरू हो जाती है. इससे कोई फ़र्क़ नहीं पड़ता कि 10,000 मैसेज, उस अवधि के पहले दिन गिने गए थे या आखिरी दिन. तय समयसीमा के खत्म होने पर, कोटा काउंटर अपने-आप रीसेट हो जाता है. इसके बाद ही, अतिरिक्त अनुरोध किए जा सकते हैं. इसके अलावा, कोटा रीसेट करने की नीति का इस्तेमाल करके, कोटा को साफ़ तौर पर रीसेट किया जा सकता है.

स्पाइकअरेस्ट, कोटा का एक वैरिएशन है. यह ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को रोकता है. ऐसा अचानक इस्तेमाल बढ़ने, गड़बड़ी वाले क्लाइंट या नुकसान पहुंचाने वाले हमलों की वजह से हो सकता है. SpikeArrest के बारे में ज़्यादा जानकारी के लिए, SpikeArrest की नीति देखें.

कोटा, हर एपीआई प्रॉक्सी पर लागू होते हैं. इन्हें एपीआई प्रॉक्सी के बीच बांटा नहीं जाता. उदाहरण के लिए, अगर आपके पास किसी एपीआई प्रॉडक्ट में तीन एपीआई प्रॉक्सी हैं, तो तीनों के लिए एक ही कोटा शेयर नहीं किया जाता भले ही, तीनों एक ही कोटा नीति कॉन्फ़िगरेशन का इस्तेमाल करते हों.

कोटा से जुड़ी नीति के टाइप

कोटा नीति, कई तरह की नीतियों के साथ काम करती है: डिफ़ॉल्ट, calendar, flexi, और rollingwindow. हर टाइप के लिए, कोटा काउंटर के शुरू होने और रीसेट होने का समय तय होता है. इसकी जानकारी इस टेबल में दी गई है:

समय इकाई डिफ़ॉल्ट (या शून्य) रीसेट कैलेंडर रीसेट करना फ़्लेक्सी रीसेट
मिनट अगले मिनट की शुरुआत <StartTime> के एक मिनट बाद पहले अनुरोध के एक मिनट बाद
hour अगले घंटे की शुरुआत में <StartTime> के एक घंटे बाद पहले अनुरोध के एक घंटे बाद
दिन मौजूदा दिन की मध्यरात्रि जीएमटी <StartTime> के 24 घंटे बाद पहली बार अनुरोध करने के 24 घंटे बाद
हफ़्ता सप्ताह के आखिर में, रविवार को मध्यरात्रि GMT <StartTime> के एक हफ़्ते बाद पहली बार अनुरोध करने के एक हफ़्ते बाद
महीना महीने के आखिरी दिन, रात 12 बजे GMT <StartTime> के एक महीने (28 दिन) बाद पहले अनुरोध के एक महीने (28 दिन) बाद

type="calendar" के लिए, आपको <StartTime> की वैल्यू देनी होगी.

टेबल में, rollingwindow टाइप के लिए वैल्यू नहीं दी गई है. रोलिंग विंडो वाले कोटे, कोटे की "विंडो" का साइज़ सेट करके काम करते हैं. जैसे, एक घंटे या एक दिन की विंडो. जब कोई नया अनुरोध आता है, तो नीति यह तय करती है कि क्या पिछले "विंडो" में कोटे से ज़्यादा अनुरोध किए गए थे.

उदाहरण के लिए, आपने दो घंटे की एक विंडो तय की है, जिसमें 1,000 अनुरोध किए जा सकते हैं. नया अनुरोध शाम 4:45 बजे आता है. नीति, पिछले दो घंटे की विंडो के लिए कोटे की गिनती करती है. इसका मतलब है कि दोपहर 2:45 बजे से किए गए अनुरोधों की संख्या. अगर दो घंटे की उस विंडो में कोटे की सीमा पार नहीं की गई है, तो अनुरोध को अनुमति दी जाती है.

एक मिनट बाद, शाम 4:46 बजे एक और अनुरोध आता है. अब नीति, कोटा काउंट की गिनती दोपहर 2:46 बजे से करती है. इससे यह तय किया जाता है कि सीमा पार हो गई है या नहीं.

rollingwindow टाइप के लिए, काउंटर कभी रीसेट नहीं होता. हालांकि, हर अनुरोध पर इसकी फिर से गिनती की जाती है.

कोटा काउंटर के बारे में जानकारी

डिफ़ॉल्ट रूप से, कोटा नीति एक ही काउंटर को बनाए रखती है. भले ही, एपीआई प्रॉक्सी में इसे कितनी बार रेफ़रंस किया गया हो. कोटा काउंटर का नाम, नीति के name एट्रिब्यूट पर आधारित होता है.

उदाहरण के लिए, आपने MyQuotaPolicy नाम की एक कोटा नीति बनाई है. इसमें अनुरोधों की सीमा पांच है. आपने इसे एपीआई प्रॉक्सी में कई फ़्लो (फ़्लो A, B, और C) पर लागू किया है. इसका इस्तेमाल कई फ़्लो में किया जाता है. हालांकि, यह एक ही काउंटर को बनाए रखता है. इस काउंटर को नीति के सभी इंस्टेंस अपडेट करते हैं:

  • फ़्लो A को एक्ज़ीक्यूट किया जाता है -> MyQuotaPolicy को एक्ज़ीक्यूट किया जाता है और इसका काउंटर = 1
  • फ़्लो B को एक्ज़ीक्यूट किया जाता है -> MyQuotaPolicy को एक्ज़ीक्यूट किया जाता है और इसका काउंटर = 2
  • फ़्लो A को एक्ज़ीक्यूट किया जाता है -> MyQuotaPolicy को एक्ज़ीक्यूट किया जाता है और इसका काउंटर = 3
  • फ़्लो C को एक्ज़ीक्यूट किया जाता है -> MyQuotaPolicy को एक्ज़ीक्यूट किया जाता है और इसका काउंटर = 4
  • फ़्लो A को एक्ज़ीक्यूट किया जाता है -> MyQuotaPolicy को एक्ज़ीक्यूट किया जाता है और इसका काउंटर = 5

इन तीनों फ़्लो में से किसी के लिए भी अगला अनुरोध अस्वीकार कर दिया जाता है, क्योंकि कोटा काउंटर अपनी सीमा तक पहुंच गया है.

एपीआई प्रॉक्सी फ़्लो में एक से ज़्यादा जगहों पर एक ही कोटा नीति का इस्तेमाल करना, The Book of Apigee Edge Antipatterns में बताई गई एक एंटी-पैटर्न है. इससे अनजाने में कोटा, आपकी उम्मीद से ज़्यादा तेज़ी से खत्म हो सकता है.

इसके अलावा, एपीआई प्रॉक्सी में कई कोटा नीतियां तय की जा सकती हैं. साथ ही, हर फ़्लो में अलग नीति का इस्तेमाल किया जा सकता है. हर कोटा नीति का अपना काउंटर होता है. यह काउंटर, नीति के name एट्रिब्यूट पर आधारित होता है.

इसके अलावा, कोटा नीति में <Class> या <Identifier> एलिमेंट का इस्तेमाल करके, एक ही नीति में कई यूनीक काउंटर तय किए जा सकते हैं. इन एलिमेंट का इस्तेमाल करके, एक ही नीति के तहत अलग-अलग काउंटर बनाए जा सकते हैं. ये काउंटर, अनुरोध करने वाले ऐप्लिकेशन, अनुरोध करने वाले ऐप्लिकेशन डेवलपर, क्लाइंट आईडी या अन्य क्लाइंट आइडेंटिफ़ायर वगैरह के आधार पर बनाए जाते हैं. <Class> या <Identifier> एलिमेंट इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, ऊपर दिए गए उदाहरण देखें.

समय का नोटेशन

सभी कोटा के समय, कोऑर्डिनेटेड यूनिवर्सल टाइम (यूटीसी) टाइम ज़ोन के हिसाब से सेट किए जाते हैं.

कोटा टाइम नोटेशन, तारीख के लिए अंतरराष्ट्रीय स्टैंडर्ड नोटेशन के मुताबिक होता है. यह नोटेशन, अंतरराष्ट्रीय स्टैंडर्ड आईएसओ 8601 में तय किया गया है.

तारीखों को साल, महीने, और दिन के हिसाब से तय किया जाता है. इनका फ़ॉर्मैट यह होता है: YYYY-MM-DD. उदाहरण के लिए, 2015-02-04 का मतलब 4 फ़रवरी, 2015 है.

दिन के समय को घंटे, मिनट, और सेकंड के हिसाब से इस फ़ॉर्मैट में दिखाया जाता है: hours:minutes:seconds. उदाहरण के लिए, 23:59:59 आधी रात से एक सेकंड पहले का समय दिखाता है.

ध्यान दें कि एक तारीख से जुड़ी दो आधी रातों के बीच अंतर करने के लिए, दो नोटेशन 00:00:00 और 24:00:00 उपलब्ध हैं. इसलिए, 2015-02-04 24:00:00 और 2015-02-05 00:00:00 की तारीख और समय एक ही है. आम तौर पर, बाद वाले नोटेशन को प्राथमिकता दी जाती है.

एपीआई प्रॉडक्ट के कॉन्फ़िगरेशन से कोटा सेटिंग पाना

एपीआई प्रॉडक्ट कॉन्फ़िगरेशन में कोटा की सीमाएं सेट की जा सकती हैं. इन सीमाओं से, कोटा अपने-आप लागू नहीं होता. इसके बजाय, कोटा की नीति में प्रॉडक्ट के कोटा की सेटिंग का रेफ़रंस दिया जा सकता है. कोटा नीतियों के लिए, प्रॉडक्ट पर कोटा सेट करने के कुछ फ़ायदे यहां दिए गए हैं:

  • कोटा नीतियों में, एपीआई प्रॉडक्ट में मौजूद सभी एपीआई प्रॉक्सी के लिए एक जैसी सेटिंग का इस्तेमाल किया जा सकता है.
  • एपीआई प्रॉडक्ट पर कोटा सेटिंग में रनटाइम बदलाव किए जा सकते हैं. साथ ही, कोटा की उन नीतियों में कोटा की वैल्यू अपने-आप अपडेट हो जाती हैं जो वैल्यू को अपने-आप रेफ़रंस करती हैं.

एपीआई प्रॉडक्ट से कोटा सेटिंग इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, ऊपर दिया गया "डाइनैमिक कोटा" उदाहरण देखें.

कोटे की सीमाओं के साथ एपीआई प्रॉडक्ट कॉन्फ़िगर करने के बारे में जानकारी के लिए, एपीआई प्रॉडक्ट बनाना लेख पढ़ें.

एलिमेंट का रेफ़रंस

इस नीति के लिए, यहां दिए गए एलिमेंट और एट्रिब्यूट कॉन्फ़िगर किए जा सकते हैं. ध्यान दें कि कुछ एलिमेंट के कॉम्बिनेशन, एक-दूसरे से अलग होते हैं या उनकी ज़रूरत नहीं होती. इस्तेमाल के खास उदाहरण देखें. अनुरोध में ऐप्लिकेशन की एपीआई कुंजी की जांच करने के लिए, "VerifyAPIKey" नाम की Verify API Key नीति का इस्तेमाल करने पर, नीचे दिए गए verifyapikey.VerifyAPIKey.apiproduct.* वैरिएबल डिफ़ॉल्ट रूप से उपलब्ध होते हैं. वैरिएबल की वैल्यू, उस एपीआई प्रॉडक्ट की कोटा सेटिंग से मिलती हैं जिससे कुंजी जुड़ी है. इसके बारे में एपीआई प्रॉडक्ट के कॉन्फ़िगरेशन से कोटा सेटिंग पाना लेख में बताया गया है.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
</Quota>

<Quota> एट्रिब्यूट

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

यहां दिए गए एट्रिब्यूट, इस नीति के लिए खास तौर पर बनाए गए हैं.

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
टाइप

इस कुकी का इस्तेमाल यह तय करने के लिए किया जाता है कि कोटा काउंटर, कोटे के इस्तेमाल की जांच कब और कैसे करता है. ज़्यादा जानकारी के लिए, कोटा से जुड़ी नीति के टाइप देखें.

अगर आपने type वैल्यू शामिल नहीं की है, तो काउंटर मिनट/घंटे/दिन/हफ़्ते/महीने की शुरुआत से शुरू होता है.

मान्य वैल्यू में ये शामिल हैं:

  • calendar: साफ़ तौर पर बताए गए शुरू होने के समय के आधार पर कोटा कॉन्फ़िगर करें. हर ऐप्लिकेशन के लिए कोटा काउंटर, <StartTime>, <Interval>, और <TimeUnit> की सेट की गई वैल्यू के आधार पर रीफ़्रेश होता है.
  • rollingwindow: "रोलिंग विंडो" का इस्तेमाल करने वाले कोटे को कॉन्फ़िगर करें, ताकि कोटे के इस्तेमाल का पता लगाया जा सके. rollingwindow की मदद से, <Interval> और <TimeUnit> एलिमेंट का इस्तेमाल करके विंडो का साइज़ तय किया जाता है. उदाहरण के लिए, एक दिन. जब कोई अनुरोध आता है, तो Edge उस अनुरोध के समय (मान लें कि शाम 5:01 बजे) को देखता है. इसके बाद, वह पिछले दिन शाम 5:01 बजे से लेकर अब तक (एक दिन) मिले अनुरोधों की संख्या गिनता है. इससे यह तय किया जाता है कि उस समयावधि में कोटा पूरा हुआ है या नहीं.
  • flexi: ऐसा कोटा कॉन्फ़िगर करें जिससे किसी ऐप्लिकेशन से पहला अनुरोध मैसेज मिलने पर काउंटर शुरू हो जाए. साथ ही, <Interval>, और <TimeUnit> वैल्यू के आधार पर रीसेट हो जाए.
कैलेंडर वैकल्पिक

यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
name

नीति का अंदरूनी नाम. name एट्रिब्यूट की वैल्यू ये काम कर सकती है: अक्षरों, संख्याओं, स्पेस, हाइफ़न, अंडरस्कोर, और फ़ुलस्टॉप को शामिल करें. यह मान नहीं हो सकता 255 वर्णों से ज़्यादा होने चाहिए.

इसके अलावा, नीति को लेबल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल करें प्रबंधन यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर को अलग, आम भाषा में इस्तेमाल करने वाले नाम के साथ किया जा सकता है.

लागू नहीं ज़रूरी है
continueOnError

किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए false पर सेट करें. यह उम्मीद है व्यवहार की जानकारी देने वाला डेटा.

नीति के लागू होने के बाद भी फ़्लो को एक्ज़ीक्यूट करने के लिए, इसे true पर सेट करें विफल होता है.

गलत वैकल्पिक
enabled

नीति को लागू करने के लिए, true पर सेट करें.

नीति को बंद करने के लिए, false पर सेट करें. नीति लागू किया जाता है, भले ही वह किसी फ़्लो से जुड़ा रहता हो.

सही वैकल्पिक
async

यह एट्रिब्यूट अब काम नहीं करता.

गलत बहिष्कृत

&lt;DisplayName&gt; एलिमेंट

इस कॉलम में नीति को लेबल करने के लिए, name एट्रिब्यूट के साथ-साथ इस्तेमाल करें मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.

<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट

लागू नहीं

अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की name एट्रिब्यूट की वैल्यू यह होगी इस्तेमाल किया गया.

मौजूदगी वैकल्पिक
टाइप स्ट्रिंग

<Allow> एलिमेंट

कोटे के लिए गिनती की सीमा तय करता है. अगर नीति के लिए काउंटर इस सीमा तक पहुंच जाता है, तो काउंटर रीसेट होने तक बाद के कॉल अस्वीकार कर दिए जाते हैं.

<Allow> एलिमेंट को सेट करने के तीन तरीके यहां दिए गए हैं:

<Allow count="2000"/>
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

अगर आपने count और countRef, दोनों एट्रिब्यूट की वैल्यू सबमिट की हैं, तो countRef एट्रिब्यूट को प्राथमिकता दी जाएगी. अगर रनटाइम के दौरान countRef हल नहीं होता है, तो count की वैल्यू का इस्तेमाल किया जाता है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप: पूर्णांक

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
सोलर पैनलों की संख्या

इस कुकी का इस्तेमाल, कोटे के लिए मैसेज की संख्या तय करने के लिए किया जाता है.

उदाहरण के लिए, count एट्रिब्यूट की वैल्यू 100, Interval की वैल्यू 1, और TimeUnit की वैल्यू महीने के हिसाब से तय करने पर, हर महीने 100 मैसेज भेजने का कोटा तय होता है.

2000 वैकल्पिक
countRef

इस विकल्प का इस्तेमाल, कोटे के लिए मैसेज की संख्या वाला फ़्लो वैरिएबल तय करने के लिए किया जाता है. countRef को count एट्रिब्यूट की जगह प्राथमिकता दी जाती है.

कोई नहीं वैकल्पिक

<Allow>/<Class> एलिमेंट

<Class> एलिमेंट की मदद से, फ़्लो वैरिएबल की वैल्यू के आधार पर <Allow> एलिमेंट की वैल्यू को शर्त के साथ सेट किया जा सकता है. नीति, <Class> के हर अलग <Allow> चाइल्ड टैग के लिए, अलग काउंटर बनाए रखती है.

<Class> एलिमेंट का इस्तेमाल करने के लिए, <Class> टैग के ref एट्रिब्यूट का इस्तेमाल करके, फ़्लो वैरिएबल तय करें. इसके बाद, Edge फ़्लो वैरिएबल की वैल्यू का इस्तेमाल करके, <Allow> चाइल्ड टैग में से किसी एक को चुनता है. इससे यह तय किया जाता है कि नीति के तहत कितने अनुरोध किए जा सकते हैं. Edge, फ़्लो वैरिएबल की वैल्यू को class टैग के class एट्रिब्यूट से मैच करता है. इसे यहां दिखाया गया है:<Allow>

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

इस उदाहरण में, मौजूदा कोटा काउंटर का पता लगाने के लिए, time_variable क्वेरी पैरामीटर की वैल्यू का इस्तेमाल किया जाता है. यह पैरामीटर, हर अनुरोध के साथ पास किया जाता है. उस वैरिएबल की वैल्यू peak_time या off_peak_time हो सकती है. अगर क्वेरी पैरामीटर में अमान्य वैल्यू शामिल है, तो नीति, कोटे के उल्लंघन की गड़बड़ी का मैसेज दिखाती है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप: लागू नहीं

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref

इसका इस्तेमाल, किसी कोटे के लिए कोटे की क्लास वाला फ़्लो वैरिएबल तय करने के लिए किया जाता है.

कोई नहीं ज़रूरी है

<Allow>/<Class>/<Allow> element

<Allow> एलिमेंट, <Class> एलिमेंट से तय किए गए कोटा काउंटर की सीमा तय करता है. <Allow> के हर अलग <Allow> चाइल्ड टैग के लिए, नीति अलग काउंटर बनाए रखती है.<Class>

उदाहरण के लिए:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

इस उदाहरण में, कोटा नीति peak_time और off_peak_time नाम के दो कोटा काउंटर बनाए रखती है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप: लागू नहीं

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
क्लास

यह कोटे के काउंटर का नाम तय करता है.

कोई नहीं ज़रूरी है
सोलर पैनलों की संख्या यह कुकी, काउंटर के लिए कोटे की सीमा तय करती है. कोई नहीं ज़रूरी है

<Interval> एलिमेंट

इसका इस्तेमाल पूर्णांक (उदाहरण के लिए, 1, 2, 5, 60 वगैरह) तय करने के लिए किया जाता है. यह पूर्णांक, TimeUnit के साथ जोड़ा जाता है. TimeUnit से मिनट, घंटा, दिन, हफ़्ता या महीना तय किया जाता है. इससे यह तय होता है कि Edge किस समयावधि के दौरान, कोटे के इस्तेमाल का हिसाब लगाएगा.

उदाहरण के लिए, hour के TimeUnit के साथ 24 का Interval का मतलब है कि कोटा का हिसाब 24 घंटे के दौरान लगाया जाएगा.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
डिफ़ॉल्ट: कोई नहीं
मौजूदगी: ज़रूरी है
टाइप: पूर्णांक

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref

इस विकल्प का इस्तेमाल, फ़्लो वैरिएबल के बारे में बताने के लिए किया जाता है. इसमें कोटे के लिए इंटरवल होता है. ref को इंटरवल की तय की गई वैल्यू पर प्राथमिकता मिलती है. अगर रेफ़रंस और वैल्यू, दोनों तय की गई हैं, तो रेफ़रंस को प्राथमिकता दी जाती है. अगर रनटाइम के दौरान ref हल नहीं होता है, तो इस वैल्यू का इस्तेमाल किया जाता है.

कोई नहीं वैकल्पिक

<TimeUnit> एलिमेंट

इस पैरामीटर का इस्तेमाल, कोटा पर लागू होने वाली समय की इकाई के बारे में बताने के लिए किया जाता है.

उदाहरण के लिए, hour के TimeUnit के साथ 24 का Interval का मतलब है कि कोटा का हिसाब 24 घंटे के दौरान लगाया जाएगा.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
डिफ़ॉल्ट: कोई नहीं
मौजूदगी: ज़रूरी है
टाइप:

स्ट्रिंग. minute, hour, day, week या month में से कोई एक चुनें.

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref इस विकल्प का इस्तेमाल, कोटे के लिए समय की इकाई वाला फ़्लो वैरिएबल तय करने के लिए किया जाता है. ref को इंटरवल की तय की गई वैल्यू पर प्राथमिकता मिलती है. अगर रनटाइम पर ref हल नहीं होता है, तो वैल्यू का इस्तेमाल किया जाता है. कोई नहीं वैकल्पिक

<StartTime> एलिमेंट

type को calendar, पर सेट करने से, उस तारीख और समय के बारे में पता चलता है जब कोटा काउंटर गिनती शुरू करेगा. भले ही, किसी ऐप्लिकेशन से कोई अनुरोध मिला हो या नहीं.

उदाहरण के लिए:

<StartTime>2017-7-16 12:00:00</StartTime>
डिफ़ॉल्ट: कोई नहीं
मौजूदगी: type को calendar पर सेट करने पर, यह एट्रिब्यूट ज़रूरी है.
टाइप:

ISO 8601 फ़ॉर्मैट में तारीख और समय की स्ट्रिंग.

<Distributed> एलिमेंट

Edge के इंस्टॉलेशन में, अनुरोधों को प्रोसेस करने के लिए एक या उससे ज़्यादा मैसेज प्रोसेसर का इस्तेमाल किया जा सकता है. इस एलिमेंट को true पर सेट करें, ताकि यह तय किया जा सके कि नीति को एक सेंट्रल काउंटर बनाए रखना चाहिए और उसे सभी मैसेज प्रोसेसर के साथ लगातार सिंक करना चाहिए. मैसेज प्रोसेसर, उपलब्धता क्षेत्र और/या क्षेत्रों में उपलब्ध हो सकते हैं.

अगर false की डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है, तो हो सकता है कि आपका कोटा पूरा हो जाए. इसकी वजह यह है कि हर मैसेज प्रोसेसर के लिए, मैसेज की संख्या शेयर नहीं की जाती:

<Distributed>true</Distributed>

यह पक्का करने के लिए कि काउंटर सिंक किए गए हैं और हर अनुरोध पर अपडेट किए गए हैं, <Distributed> और <Synchronous> को सही पर सेट करें:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>
डिफ़ॉल्ट: गलत
मौजूदगी: वैकल्पिक
टाइप: बूलियन

<Synchronous> एलिमेंट

डिस्ट्रिब्यूट किए गए कोटा काउंटर को एक साथ अपडेट करने के लिए, इसे true पर सेट करें. इसका मतलब है कि काउंटर को अपडेट करने के साथ-साथ, एपीआई से किए गए अनुरोध पर कोटा की जांच की जाती है. अगर यह ज़रूरी है कि आपको कोटे से ज़्यादा एपीआई कॉल की अनुमति नहीं देनी है, तो इसे true पर सेट करें.

कोटा काउंटर को एसिंक्रोनस तरीके से अपडेट करने के लिए, इसे false पर सेट करें. इसका मतलब है कि कोटा से ज़्यादा एपीआई कॉल किए जाने पर भी, कुछ कॉल पूरे हो सकते हैं. ऐसा इस बात पर निर्भर करता है कि सेंट्रल रिपॉज़िटरी में कोटा काउंटर को एसिंक्रोनस तरीके से कब अपडेट किया जाता है. हालांकि, आपको सिंक्रोनस अपडेट से जुड़ी परफ़ॉर्मेंस पर पड़ने वाले संभावित असर का सामना नहीं करना पड़ेगा.

डिफ़ॉल्ट रूप से, एसिंक्रोनस अपडेट का इंटरवल 10 सेकंड होता है. इस एसिंक्रोनस व्यवहार को कॉन्फ़िगर करने के लिए, AsynchronousConfiguration एलिमेंट का इस्तेमाल करें.

<Synchronous>false</Synchronous>
डिफ़ॉल्ट: गलत
मौजूदगी: वैकल्पिक
टाइप: बूलियन

<AsynchronousConfiguration> एलिमेंट

यह नीति, डिस्ट्रिब्यूट किए गए कोटा काउंटर के बीच सिंक करने का इंटरवल कॉन्फ़िगर करती है. ऐसा तब होता है, जब नीति कॉन्फ़िगरेशन एलिमेंट <Synchronous> मौजूद नहीं होता या मौजूद होता है और false पर सेट होता है.

SyncIntervalInSeconds या SyncMessageCount चाइल्ड एलिमेंट का इस्तेमाल करके, किसी समयावधि या मैसेज की संख्या के बाद सिंक्रनाइज़ किया जा सकता है. ये दोनों एक-दूसरे से अलग होते हैं. उदाहरण के लिए,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

या

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>
डिफ़ॉल्ट: SyncIntervalInSeconds = 10 सेकंड
मौजूदगी: ज़रूरी नहीं है. <Synchronous> को true पर सेट करने पर, इसे अनदेखा कर दिया जाता है.
टाइप:

परिसर

<AsynchronousConfiguration>/<SyncIntervalInSeconds> element

इस विकल्प का इस्तेमाल करके, डिफ़ॉल्ट सेटिंग को बदला जा सकता है. डिफ़ॉल्ट सेटिंग में, एसिंक्रोनस अपडेट 10 सेकंड के अंतराल के बाद किए जाते हैं.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

सिंक करने का इंटरवल 10 सेकंड से ज़्यादा या इसके बराबर होना चाहिए. इसके बारे में सीमाएं विषय में बताया गया है.

डिफ़ॉल्ट: 10
मौजूदगी: वैकल्पिक
टाइप:

पूर्णांक

<AsynchronousConfiguration>/<SyncMessageCount> एलिमेंट

इस विकल्प से, कोटा अपडेट के बीच सभी Apigee मैसेज प्रोसेसर के लिए अनुरोधों की संख्या तय की जाती है.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

इस उदाहरण में बताया गया है कि Apigee Edge के हर मैसेज प्रोसेसर पर, हर पांच अनुरोधों के बाद कोटा काउंट अपडेट किया जाता है.

डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप:

पूर्णांक

<Identifier> एलिमेंट

<Identifier> एलिमेंट का इस्तेमाल करके, नीति को कॉन्फ़िगर करें. इससे फ़्लो वैरिएबल के आधार पर यूनीक काउंटर बनाए जा सकते हैं.

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

इस एलिमेंट का इस्तेमाल न करने पर, नीति एक काउंटर का इस्तेमाल करती है. यह काउंटर, कोटे पर लागू होता है.

इस एलिमेंट के बारे में, Apigee Community की इस पोस्ट में भी बताया गया है: Quota identifier across different policies.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>
डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप:

स्ट्रिंग

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref

यह एक फ़्लो वैरिएबल तय करता है. यह वैरिएबल, अनुरोध के लिए इस्तेमाल किए जाने वाले काउंटर की पहचान करता है. यह आइडेंटिफ़ायर, एचटीटीपी हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर या मैसेज कॉन्टेंट हो सकता है. यह हर ऐप्लिकेशन, ऐप्लिकेशन के उपयोगकर्ता, ऐप्लिकेशन डेवलपर, एपीआई प्रॉडक्ट या अन्य विशेषता के लिए यूनीक होता है.

ऐप्लिकेशन की खास तौर पर पहचान करने के लिए, <Identifier> का सबसे ज़्यादा इस्तेमाल किया जाता है.client_id client_id, एपीआई पासकोड या उपभोक्ता पासकोड का दूसरा नाम है. यह पासकोड, Apigee Edge पर किसी संगठन में रजिस्टर किए जाने पर ऐप्लिकेशन के लिए जनरेट किया जाता है. अगर आपने अपने एपीआई के लिए, एपीआई पासकोड या OAuth की पुष्टि करने की नीतियां चालू की हैं, तो इस आइडेंटिफ़ायर का इस्तेमाल किया जा सकता है.

कुछ मामलों में, कोटा सेटिंग को वापस पाना ज़रूरी होता है. जैसे, जब कोई सुरक्षा नीति लागू न हो और कोई client_id उपलब्ध न हो. ऐसे मामलों में, ऐक्सेस एंटिटी नीति का इस्तेमाल करके, एपीआई प्रॉडक्ट की सही सेटिंग वापस पाई जा सकती हैं. इसके बाद, ExtractVariables का इस्तेमाल करके वैल्यू निकाली जा सकती हैं. इसके बाद, निकाली गई वैल्यू वाले कॉन्टेक्स्ट वैरिएबल का इस्तेमाल, कोटा नीति में किया जा सकता है. ज़्यादा जानकारी के लिए, ऐक्सेस एंटिटी की नीति देखें.

लागू नहीं वैकल्पिक

<MessageWeight> एलिमेंट

इसका इस्तेमाल, हर मैसेज को असाइन किया गया वज़न तय करने के लिए किया जाता है. मैसेज के वेट का इस्तेमाल करके, अनुरोध वाले ऐसे मैसेज का असर बढ़ाएं जो अन्य मैसेज की तुलना में ज़्यादा कंप्यूटेशनल संसाधनों का इस्तेमाल करते हैं. उदाहरण के लिए, अनुरोध वाले मैसेज.

उदाहरण के लिए, आपको POST मैसेज को GET मैसेज की तुलना में दो गुना "भारी" या महंगा मानना है. इसलिए, POST के लिए MessageWeight को 2 पर और GET के लिए 1 पर सेट करें. MessageWeight को 0 पर भी सेट किया जा सकता है, ताकि अनुरोध से काउंटर पर कोई असर न पड़े. इस उदाहरण में, अगर कोटा हर मिनट 10 मैसेज है और POST अनुरोधों के लिए MessageWeight 2 है, तो कोटा किसी भी 10 मिनट के अंतराल में 5 POST अनुरोधों की अनुमति देगा. काउंटर रीसेट होने से पहले, POST या GET के किसी भी अन्य अनुरोध को अस्वीकार कर दिया जाता है.

MessageWeight को दिखाने वाली वैल्यू, फ़्लो वैरिएबल से तय की जानी चाहिए. इसे एचटीटीपी हेडर, क्वेरी पैरामीटर, एक्सएमएल या JSON अनुरोध के पेलोड या किसी अन्य फ़्लो वैरिएबल से निकाला जा सकता है. उदाहरण के लिए, आपने इसे weight नाम के हेडर में सेट किया है:

<MessageWeight ref="message_weight"/>
डिफ़ॉल्ट: लागू नहीं
मौजूदगी: वैकल्पिक
टाइप:

पूर्णांक

फ़्लो वैरिएबल

कोटा नीति लागू होने पर, पहले से तय किए गए ये फ़्लो वैरिएबल अपने-आप भर जाते हैं. फ़्लो वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.

वैरिएबल टाइप अनुमतियां ब्यौरा
ratelimit.{policy_name}.allowed.count लंबा रीड-ओनली अनुमति वाले कोटे की संख्या दिखाता है
ratelimit.{policy_name}.used.count लंबा रीड-ओनली यह फ़ंक्शन, कोटे के इंटरवल में इस्तेमाल किए गए मौजूदा कोटे की जानकारी देता है
ratelimit.{policy_name}.available.count लंबा रीड-ओनली यह फ़ंक्शन, कोटा इंटरवल में उपलब्ध कोटे की संख्या दिखाता है
ratelimit.{policy_name}.exceed.count लंबा रीड-ओनली कोटा खत्म होने के बाद, 1 दिखाता है.
ratelimit.{policy_name}.total.exceed.count लंबा रीड-ओनली कोटा खत्म होने के बाद, 1 दिखाता है.
ratelimit.{policy_name}.expiry.time लंबा रीड-ओनली

यह कुकी, यूटीसी समय को मिलीसेकंड में दिखाती है. इससे यह तय होता है कि कोटा कब खत्म होगा और नया कोटा इंटरवल कब शुरू होगा.

जब कोटा नीति का टाइप rollingwindow होता है, तब यह वैल्यू मान्य नहीं होती, क्योंकि कोटा इंटरवल कभी खत्म नहीं होता.

ratelimit.{policy_name}.identifier स्ट्रिंग रीड-ओनली नीति से जुड़े (क्लाइंट) आइडेंटिफ़ायर के रेफ़रंस की जानकारी देता है
ratelimit.{policy_name}.class स्ट्रिंग रीड-ओनली क्लाइंट आइडेंटिफ़ायर से जुड़ी क्लास दिखाता है
ratelimit.{policy_name}.class.allowed.count लंबा रीड-ओनली क्लास में तय किए गए, इस्तेमाल किए जा सकने वाले कोटे की संख्या दिखाता है
ratelimit.{policy_name}.class.used.count लंबा रीड-ओनली यह फ़ंक्शन, किसी क्लास में इस्तेमाल किए गए कोटे की जानकारी देता है
ratelimit.{policy_name}.class.available.count लंबा रीड-ओनली क्लास में उपलब्ध कोटे की संख्या दिखाता है
ratelimit.{policy_name}.class.exceed.count लंबा रीड-ओनली यह फ़ंक्शन, मौजूदा कोटे के इंटरवल में क्लास के लिए तय की गई सीमा से ज़्यादा अनुरोधों की संख्या दिखाता है
ratelimit.{policy_name}.class.total.exceed.count लंबा रीड-ओनली यह क्लास में, सभी कोटे के इंटरवल में सीमा से ज़्यादा अनुरोधों की कुल संख्या दिखाता है. इसलिए, यह सभी कोटे के इंटरवल के लिए class.exceed.count का योग होता है.
ratelimit.{policy_name}.failed बूलियन रीड-ओनली

इससे पता चलता है कि नीति का उल्लंघन हुआ है या नहीं (सही या गलत).

गड़बड़ी की जानकारी

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Cause Fix
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 Occurs if the <Interval> element is not defined within the Quota policy. This element is mandatory and used to specify the interval of time applicable to the quota. The time interval can be minutes, hours, days, weeks, or months as defined with the <TimeUnit> element.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 Occurs if the <TimeUnit> element is not defined within the Quota policy. This element is mandatory and used to specify the unit of time applicable to the quota. The time interval can be in minutes, hours, days, weeks, or months.
policies.ratelimit.InvalidMessageWeight 500 Occurs if the value of the <MessageWeight> element specified through a flow variable is invalid (a non-integer value).
policies.ratelimit.QuotaViolation 500 The quota limit was exceeded. N/A

Deployment errors

Error name Cause Fix
InvalidQuotaInterval If the quota interval specified in the <Interval> element is not an integer, then the deployment of the API proxy fails. For example, if the quota interval specified is 0.1 in the <Interval> element, then the deployment of the API proxy fails.
InvalidQuotaTimeUnit If the time unit specified in the <TimeUnit> element is unsupported, then the deployment of the API proxy fails. The supported time units are minute, hour, day, week, and month.
InvalidQuotaType If the type of the quota specified by the type attribute in the <Quota> element is invalid, then the deployment of the API proxy fails. The supported quota types are default, calendar, flexi, and rollingwindow.
InvalidStartTime If the format of the time specified in the <StartTime> element is invalid, then the deployment of the API proxy fails. The valid format is yyyy-MM-dd HH:mm:ss, which is the ISO 8601 date and time format. For example, if the time specified in the <StartTime> element is 7-16-2017 12:00:00 then the deployment of the API proxy fails.
StartTimeNotSupported If the <StartTime> element is specified whose quota type is not calendar type, then the deployment of the API proxy fails. The <StartTime> element is supported only for the calendar quota type. For example, if the type attribute is set to flexi or rolling window in the <Quota> element, then the deployment of the API proxy fails.
InvalidTimeUnitForDistributedQuota If the <Distributed> element is set to true and the <TimeUnit> element is set to second then the deployment of the API proxy fails. The timeunit second is invalid for a distributed quota.
InvalidSynchronizeIntervalForAsyncConfiguration If the value specified for the <SyncIntervalInSeconds> element within the <AsynchronousConfiguration> element in a Quota policy is less than zero, then the deployment of the API proxy fails.
InvalidAsynchronizeConfigurationForSynchronousQuota If the value of the <AsynchronousConfiguration> element is set to true in a Quota policy, which also has asynchronous configuration defined using the <AsynchronousConfiguration> element, then the deployment of the API proxy fails.

Fault variables

These variables are set when this policy triggers an error. For more information, see What you need to know about policy errors.

Variables Where Example
fault.name="fault_name" fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. fault.name Matches "QuotaViolation"
ratelimit.policy_name.failed policy_name is the user-specified name of the policy that threw the fault. ratelimit.QT-QuotaPolicy.failed = true

Example error response

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Example fault rule

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

स्कीमा

मिलते-जुलते विषय

ResetQuota नीति

SpikeArrest नीति

कोटा, स्पाइक अरेस्ट, और एक साथ कई अनुरोध करने पर रोक लगाने से जुड़ी नीतियों की तुलना करना