Rate Limiting

อยู่ภายในขีดจำกัด Omise API rate limits และสร้างการเชื่อมต่อที่มีประสิทธิภาพ เรียนรู้เกี่ยวกับ rate limit headers, การจัดการ 429 errors อย่างเหมาะสม และการปรับแต่ง request patterns ของคุณ

ภาพรวม

เพื่อให้บริการที่เชื่อถือได้สำหรับร้านค้าทุกราย Omise ใช้ rate limiting สำหรับ API requests Rate limits ป้องกันไม่ให้การเชื่อมต่อใดๆ ครอบครอง API และรับประกันการจัดสรรทรัพยากรอย่างยุติธรรม การเข้าใจและเคารพขีดจำกัดเหล่านี้เป็นสิ่งจำเป็นสำหรับการสร้างการเชื่อมต่อการชำระเงินที่มีประสิทธิภาพ

เริ่มต้นอย่างรวดเร็ว

• ขีดจำกัดเริ่มต้น: 1,000 requests ต่อนาทีต่อ API key
• ตรวจสอบ X-RateLimit-* headers ใน responses
• จัดการ HTTP 429 ด้วย exponential backoff
• ใช้ request queuing สำหรับการดำเนินการปริมาณสูง
• Cache responses เมื่อเหมาะสม

---

รายละเอียด Rate Limit

ขีดจำกัดปัจจุบัน

ประเภทขีดจำกัด	ค่า	ขอบเขต
Standard Rate Limit	1,000 requests/นาที	ต่อ API key
Burst Allowance	~100 requests	อนุญาต bursts สั้นๆ
Reset Period	60 วินาที	Rolling window

สิ่งที่นับรวมในขีดจำกัด

✅ นับรวม:

• API requests ทั้งหมด (GET, POST, PATCH, DELETE)
• requests ที่สำเร็จ (2xx responses)
• requests ที่ล้มเหลว (4xx, 5xx responses)
• Authentication failures

❌ ไม่นับรวม:

• requests ที่ถูกบล็อกก่อนถึง API (URLs ไม่ถูกต้อง)
• Static asset requests
• Dashboard access
• Webhook deliveries จาก Omise

ประเภทการจำกัดอัตรา

Omise ใช้ทั้งการจำกัดอัตรา ตาม IP และ ตามบัญชี พร้อมการอนุญาตชั่วคราวสำหรับ bursts สั้นๆ ซึ่งหมายความว่าขีดจำกัดจะถูกติดตามต่อ API key และต่อ IP address

การจัดลำดับความสำคัญของคำขอ

เมื่อระบบมีภาระงานสูง คำขอจะถูกจัดลำดับความสำคัญตามลำดับนี้:

ลำดับความสำคัญ	ประเภทคำขอ	คำอธิบาย
1 (สูงสุด)	POST/PUT ในโหมด live	การสร้าง charge, การ capture, การคืนเงิน
2	GET ในโหมด live	การแสดงรายการธุรกรรม, การดึงข้อมูล charges
3 (ต่ำสุด)	คำขอโหมด test ทั้งหมด	คำขอใดๆ ที่ใช้ test API keys

ขีดจำกัด Vault Token

การสร้าง Token บน Vault (vault.omise.co) มี rate limit ที่ต่ำกว่ามาก เมื่อเทียบกับ API หลัก หลีกเลี่ยงการสร้าง tokens ติดต่อกันอย่างรวดเร็ว แต่ให้ใช้ tokens ซ้ำภายในระยะเวลาที่ใช้ได้ หรือแนบบัตรกับลูกค้าสำหรับการใช้งานซ้ำ

ห้ามทำ Load Testing

การทดสอบโหลดกับ Omise API ห้ามทำโดยเด็ดขาด หากคุณต้องการตรวจสอบประสิทธิภาพในระดับ scale โปรดติดต่อ support@omise.co เพื่อจัดเตรียมการทดสอบที่เหมาะสม

---

Rate Limit Headers

ทุก API response รวม rate limit information ใน headers:

Response Headers

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 995
X-RateLimit-Reset: 1612137600

คำอธิบาย Headers

Header	คำอธิบาย	ตัวอย่าง
X-RateLimit-Limit	requests สูงสุดที่อนุญาตใน window	1000
X-RateLimit-Remaining	requests ที่เหลือใน window ปัจจุบัน	995
X-RateLimit-Reset	Unix timestamp เมื่อ limit reset	1612137600

อ่าน Headers ในโค้ด

# Ruby - ตรวจสอบ rate limit headers
require 'omise'

Omise.api_key = ENV['OMISE_SECRET_KEY']

response = Omise::Charge.retrieve('chrg_test_...')

# เข้าถึง headers
limit = response.http_headers['X-RateLimit-Limit']
remaining = response.http_headers['X-RateLimit-Remaining']
reset = response.http_headers['X-RateLimit-Reset']

puts "Rate limit: #{remaining}/#{limit}"
puts "Reset เมื่อ: #{Time.at(reset.to_i)}"

// Node.js - ตรวจสอบ rate limit headers
const omise = require('omise')({
  secretKey: process.env.OMISE_SECRET_KEY
});

try {
  const charge = await omise.charges.retrieve('chrg_test_...');

  // Headers มีใน response
  const headers = charge._response.headers;

  const limit = headers['x-ratelimit-limit'];
  const remaining = headers['x-ratelimit-remaining'];
  const reset = headers['x-ratelimit-reset'];

  console.log(`Rate limit: ${remaining}/${limit}`);
  console.log(`Reset เมื่อ: ${new Date(reset * 1000)}`);

} catch (error) {
  console.error('Request ล้มเหลว:', error);
}

---

HTTP 429 Response

เมื่อคุณเกิน rate limit, API จะส่งคืน HTTP 429 Too Many Requests:

รูปแบบ 429 Response

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1612137660
Retry-After: 60

{
  "object": "error",
  "location": "https://www.omise.co/api-errors#rate-limit-exceeded",
  "code": "rate_limit_exceeded",
  "message": "too many requests, please try again later"
}

Response Fields

Field	คำอธิบาย
code	"rate_limit_exceeded"
message	ข้อความ error ที่อ่านได้
Retry-After	วินาทีที่ต้องรอก่อนลองใหม่

---

การจัดการ Rate Limits

กลยุทธ์ที่ 1: Exponential Backoff (แนะนำ)

ลองใหม่ด้วย delays ที่เพิ่มขึ้น:

# Ruby - Exponential backoff
require 'omise'

def create_charge_with_backoff(params, max_attempts: 5)
  attempt = 0

  begin
    attempt += 1
    Omise::Charge.create(params)

  rescue Omise::Error => e
    if e.code == 'rate_limit_exceeded' && attempt < max_attempts
      # คำนวณ backoff delay: 1s, 2s, 4s, 8s, 16s
      delay = 2 ** (attempt - 1)

      # เพิ่ม jitter (ความสุ่ม) เพื่อป้องกัน thundering herd
      jitter = rand(0..delay * 0.1)
      sleep(delay + jitter)

      retry
    else
      raise
    end
  end
end

# การใช้งาน
charge = create_charge_with_backoff(
  amount: 100000,
  currency: 'thb',
  card: token
)

// Node.js - Exponential backoff
async function createChargeWithBackoff(chargeData, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await omise.charges.create(chargeData);

    } catch (error) {
      if (error.code !== 'rate_limit_exceeded' || attempt === maxAttempts - 1) {
        throw error;
      }

      // คำนวณ delay พร้อม jitter
      const baseDelay = Math.pow(2, attempt) * 1000;
      const jitter = Math.random() * baseDelay * 0.1;
      const delay = baseDelay + jitter;

      console.log(`Rate limited. ลองใหม่ใน ${(delay / 1000).toFixed(2)} วินาที...`);
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
}

// การใช้งาน
const charge = await createChargeWithBackoff({
  amount: 100000,
  currency: 'thb',
  card: token
});

กลยุทธ์ที่ 2: เคารพ Retry-After Header

ใช้เวลา retry ที่ server แนะนำ:

<?php
function createChargeWithRetryAfter($params, $maxAttempts = 5) {
    $attempt = 0;

    while ($attempt < $maxAttempts) {
        try {
            $attempt++;
            return OmiseCharge::create($params);

        } catch (Exception $e) {
            if ($e->getCode() !== 'rate_limit_exceeded' || $attempt >= $maxAttempts) {
                throw $e;
            }

            // รับ Retry-After header จาก response
            $retryAfter = $e->getResponse()->getHeader('Retry-After');
            $delay = $retryAfter ? (int)$retryAfter : 60;

            echo "Rate limited. รอ {$delay} วินาที...\n";
            sleep($delay);
        }
    }

    throw new Exception('เกินจำนวนครั้งที่ลองใหม่ได้');
}

// การใช้งาน
$charge = createChargeWithRetryAfter([
    'amount' => 100000,
    'currency' => 'thb',
    'card' => $token
]);

---

กลยุทธ์การเพิ่มประสิทธิภาพ

1. Cache Responses

# Ruby - Cache ด้วย Redis
require 'redis'

class OmiseCache
  def initialize
    @redis = Redis.new
  end

  def get_charge(charge_id)
    cache_key = "charge:#{charge_id}"

    # ลอง cache ก่อน
    cached = @redis.get(cache_key)
    return JSON.parse(cached) if cached

    # ดึงจาก API
    charge = Omise::Charge.retrieve(charge_id)

    # Cache 5 นาที
    @redis.setex(cache_key, 300, charge.to_json)

    charge
  end
end

cache = OmiseCache.new

# การเรียกครั้งแรก - ติด API
charge = cache.get_charge('chrg_test_...')

# การเรียกถัดไป - จาก cache (ไม่มี API request)
charge = cache.get_charge('chrg_test_...')

2. ใช้ Webhooks แทนการ Polling

// ❌ ไม่ดี - Polling ใช้ rate limit เปล่าๆ
async function waitForChargeComplete(chargeId) {
  let charge;

  // Poll ทุก 2 วินาที - เสีย requests!
  while (true) {
    charge = await omise.charges.retrieve(chargeId);

    if (charge.status === 'successful' || charge.status === 'failed') {
      return charge;
    }

    await new Promise(resolve => setTimeout(resolve, 2000));
  }
}

// ✅ ดี - ใช้ webhooks
app.post('/webhooks/omise', async (req, res) => {
  const event = req.body;

  if (event.key === 'charge.complete') {
    const charge = event.data;

    // ประมวลผล charge ที่เสร็จแล้ว
    await processCharge(charge);
  }

  res.sendStatus(200);
});

---

แนวทางปฏิบัติที่ดีที่สุด

1. ใช้ Retry Logic เสมอ

# ✅ ดี - Retry logic ในตัว
@retry(
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=1, min=1, max=60),
    retry=retry_if_exception_type(omise.errors.RateLimitError)
)
def create_charge(amount, currency, card):
    return omise.Charge.create(
        amount=amount,
        currency=currency,
        card=card
    )

2. ตรวจสอบการใช้งาน Rate Limit

# ✅ ดี - ติดตามและแจ้งเตือน
after_action :track_rate_limit

def track_rate_limit
  if response.headers['X-RateLimit-Remaining']
    remaining = response.headers['X-RateLimit-Remaining'].to_i
    limit = response.headers['X-RateLimit-Limit'].to_i

    usage_percent = ((limit - remaining).to_f / limit * 100).round(2)

    # Log metrics
    StatsD.gauge('omise.rate_limit.usage', usage_percent)

    # แจ้งเตือนถ้าสูง
    if usage_percent > 90
      AlertService.notify("การใช้งาน Omise rate limit สูง: #{usage_percent}%")
    end
  end
end

3. จัดการ Rate Limits อย่างเหมาะสม

# ✅ ดี - จัดการ error แบบ user-friendly
def create_charge(params)
  Omise::Charge.create(params)

rescue Omise::Error => e
  if e.code == 'rate_limit_exceeded'
    # อย่าเปิดเผยรายละเอียดทางเทคนิคให้ผู้ใช้
    flash[:error] = "ระบบชำระเงินของเรากำลังยุ่งอยู่ กรุณาลองใหม่ในอีกสักครู่"

    # Log สำหรับการตรวจสอบ
    Rails.logger.warn("Rate limit exceeded: #{e.message}")

    # ลองใหม่ใน background job
    ChargeCreationJob.perform_later(params)
  else
    raise
  end
end

---

รายการตรวจสอบ Rate Limit

ก่อน go live:

• ใช้ exponential backoff สำหรับ retries
• เคารพ Retry-After header
• ตรวจสอบ rate limit headers ใน responses
• ตั้งค่าแจ้งเตือนสำหรับการใช้งานสูง (>80%)
• Cache responses เมื่อเหมาะสม
• ใช้ webhooks แทน polling
• รวมการดำเนินการเป็น batch เมื่อทำได้
• จำกัด parallel workers สูงสุด 10 ตัว
• กระจายคำขอตามเวลา (ควรส่ง 20/วินาที เป็นเวลา 5 วินาที แทน 100/วินาที ใน 1 วินาที)
• ทดสอบการจัดการ rate limit ใน staging
• บันทึกกลยุทธ์ rate limit สำหรับทีม
• มีแผนสำรองสำหรับ rate limit errors
• ตรวจสอบ rate limit metrics ใน production
• ติดต่อ support@omise.co สำหรับกิจกรรมที่คาดว่าจะมีทราฟฟิกสูง
• ตรวจสอบโค้ดสำหรับ API calls ที่ไม่จำเป็น

---

อ้างอิงด่วน

ขีดจำกัดปัจจุบัน

1,000 requests ต่อนาทีต่อ API key

Rate Limit Headers

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 995
X-RateLimit-Reset: 1612137600

HTTP 429 Response

{
  "code": "rate_limit_exceeded",
  "message": "too many requests, please try again later"
}

รูปแบบ Retry พื้นฐาน

begin
  omise_request()
rescue Omise::Error => e
  if e.code == 'rate_limit_exceeded'
    sleep(2 ** attempt)
    retry
  end
  raise
end

สูตร Exponential Backoff

delay = base_delay * (2 ^ attempt) + jitter

ตัวอย่าง:

• ครั้งที่ 1: 1 วินาที + jitter
• ครั้งที่ 2: 2 วินาที + jitter
• ครั้งที่ 3: 4 วินาที + jitter
• ครั้งที่ 4: 8 วินาที + jitter
• ครั้งที่ 5: 16 วินาที + jitter

---

ทรัพยากรที่เกี่ยวข้อง

• ภาพรวม API Reference
• การจัดการข้อผิดพลาด
• Idempotency
• การยืนยันตัวตน
• แนวทางปฏิบัติที่ดีที่สุด

---

พร้อมเชื่อมต่อหรือยัง? ตรวจสอบคู่มือที่จำเป็นทั้งหมด: การยืนยันตัวตน • การจัดการข้อผิดพลาด • Pagination • Idempotency • Versioning

---

FAQ

จะเกิดอะไรขึ้นเมื่อเกินขีดจำกัดอัตรา?

เมื่อคุณเกินขีดจำกัดอัตรา API จะส่งคืน HTTP 429 (Too Many Requests) พร้อมรหัสข้อผิดพลาด rate_limit_exceeded การตอบกลับจะรวม header Retry-After ที่ระบุจำนวนวินาทีที่ต้องรอก่อนลองใหม่

ขีดจำกัดอัตราใช้ร่วมกันระหว่างโหมดทดสอบและโหมดใช้งานจริงหรือไม่?

ไม่ โหมดทดสอบและโหมดใช้งานจริงมีขีดจำกัดอัตราแยกกัน คำขอที่ทำด้วย API keys ทดสอบจะไม่นับรวมในขีดจำกัดโหมดใช้งานจริงของคุณ และในทางกลับกัน

ฉันสามารถขอขีดจำกัดอัตราที่สูงขึ้นสำหรับบัญชีของฉันได้หรือไม่?

ได้ หากการเชื่อมต่อของคุณต้องการขีดจำกัดอัตราที่สูงขึ้น โปรดติดต่อ support@omise.co พร้อมรายละเอียดเกี่ยวกับกรณีการใช้งานของคุณ ขีดจำกัดที่สูงขึ้นมีให้สำหรับร้านค้าที่มีปริมาณธุรกรรมสูง

การส่ง webhook นับรวมในขีดจำกัดอัตราของฉันหรือไม่?

ไม่ การส่ง webhook จาก Omise ไปยังเซิร์ฟเวอร์ของคุณไม่นับรวมในขีดจำกัดอัตราของคุณ เฉพาะคำขอ API ของคุณไปยัง Omise เท่านั้นที่นับ

ฉันควรจัดการข้อผิดพลาดขีดจำกัดอัตราในระบบ production อย่างไร?

ใช้ exponential backoff พร้อม jitter เคารพ header Retry-After และพิจารณาจัดคิวคำขอในช่วงที่มีทราฟฟิกสูง ตรวจสอบ header X-RateLimit-Remaining เพื่อชะลอเชิงรุกก่อนถึงขีดจำกัด

การแคชช่วยลดการใช้ขีดจำกัดอัตราหรือไม่?

ใช่ การแคชการตอบกลับ API สามารถลดการใช้ขีดจำกัดอัตราได้อย่างมาก แคชการดำเนินการอ่าน (GET requests) ที่ข้อมูลไม่เปลี่ยนแปลงบ่อย เช่น โปรไฟล์ลูกค้าหรือประวัติการชำระเงิน