راهنمای کامل برای پردازش محدودیت های سرعت API: از 429 خطا جلوگیری کنید

هنگام ادغام API ، مانند API از Chatgpt یا API Ayrshare در رسانه های اجتماعی ، در سکوی شما ، ایجاد اقدامات برای مقابله با خطاها در محدوده سرعت API قبل از ظاهر شدن ضروری است. از آنجا که بیشتر سیستم های API محدودیت های سرعت دارند ، شما می خواهید یک تجربه صاف و قابل پیش بینی را برای کاربران خود فراهم کنید ، به همراه جلوگیری از توقف احتمالی یا هزینه های غیر منتظره.
در این راهنما ما یک سیستم محدودیت سرعت را در چهار مرحله مترقی ایجاد خواهیم کرد ، با شروع اصول اولیه و پایان دادن به راه حلی که بسیاری از کاربران را با محدودیت سرعت فردی پردازش می کند. هر مرحله بر روی قسمت قبلی ساخته می شود ، بنابراین می توانید دقیقاً آنچه را که هنگام ادغام Ayrshare نیاز دارید اعمال کنید.
ما همچنین نحوه اجرای محدودیت سرعت مشتری برای API را برای جلوگیری از 429 اشتباه ، رسیدگی به لطف و ساخت برنامه های مقیاس برای بسیاری از کاربران بررسی خواهیم کرد.
محدودیت سرعت API ضروری است
چرا سیستم های API حتی محدودیت سرعت دارند؟ هر API بالغ محدودیت های سرعت برای حفظ یک بستر سالم خواهد داشت تا کاربر تمام منابع سیستم را کوچک نکند یا به طور تصادفی باعث شود DDO ها در سیستم ثالث سوم شکست بخورد. به عنوان مثال ، تصور کنید که اگر به اشتباه 100000 بار در ثانیه در یک طرح بی پایان تماس بگیرید – این می تواند برای یک سیستم بدون محافظت مناسب فاجعه بار باشد. یا اگر هزینه تماس API را پرداخت می کنید ، حساب بانکی شما قابل تخلیه است. نگران نباشید ، Ayrshare تماس های AI را شارژ نمی کند ، اما AI API مطمئناً این کار را انجام می دهد.
علاوه بر این ، Ayrshare محدودیت هایی در سرعت حفظ اکوسیستم سالم در رسانه های اجتماعی و محافظت از حساب های اجتماعی کاربران از فعالیت های ناخواسته اسپم دارد. به عنوان مثال ، اگر می توانید 10،000 پست فیس بوک ، همه را در یک حساب فیس بوک ارسال کنید ، خوب است که یک حساب فیس بوک توسط متا به دلیل اسپامر ممنوع شود.
بهترین شیوه ها را محدود کنید
در مرحله بعد ، بیایید درک کنیم که چرا محدود کردن بهترین روشهای API مهم است و چقدر محدود کردن سرعت مشتری می تواند از دریچه گاز API جلوگیری کند.
مزایای بهره وری و قابلیت اطمینان
هنگام ساختن برنامه هایی که با API خارجی ادغام می شوند ، مدیریت جریان برای حفظ یک تجربه کاربر صاف بسیار مهم است. محدودیت سرعت نه تنها برای ماندن در سهمیه های API – بلکه ایجاد یک سیستم پایدار است که ترافیک قابل پیش بینی و برازنده را انجام می دهد. در اینجا برخی از مزایای آن وجود دارد که چرا مدیریت درصد های فعال مهم است.
- حفاظت فعال: به جای اینکه به محدودیت سرعت ضربه بزنید و با 429 پاسخ برخورد کنید ، با مدیریت زمان درخواست در پایان ، آنها را به طور کامل از آنها جلوگیری می کنید.
- تجربه بهتر کاربر: هنگامی که کاربران سعی در دسترسی به API دارند ، به عنوان مثال ، هیچ خرابی ناگهانی API وجود ندارد. انتشار انتشارات. کاربران شما عملکرد انتشار مداوم و قابل پیش بینی را دریافت می کنند.
- 429 پردازش خطا: اجرای منطق صحیح تکرار و نمایی برای معامله به جای اینکه بلافاصله ناکام باشد ، به طرز فجیعی به محدودیت سرعت پاسخ می دهد.
- اثربخشی: درخواست های کمتر ناموفق به معنای هزینه های API پایین تر و استفاده کارآمدتر از منابع است. در حالی که Ayrshare برای تماس های API هزینه نمی کند ، بسیاری از API های دیگر که می توانند به سرعت جمع شوند و هزینه آن را می توان به سرعت جمع کرد.
- توزیع منصفانه منابع: هر کاربر سهمیه توزیع شده خود را برای انتشار دریافت می کند ، بدون اینکه یک کاربر سنگین بر توانایی دیگران در دسترسی به منابع API تأثیر بگذارد.
درک استراتژی ها برای محدود کردن سرعت
چندین مدل برای محدود کردن سرعت گره وجود دارد.
پنجره کشویی
استراتژی برای محدود کردن سرعت کشویی پنجره ، درخواست ها را در پنجره دوره متحرک ردیابی می کند. بر خلاف ویندوزهای ثابت ، که در فواصل خاص مجدداً تنظیم می شوند ، ویندوز کشویی با به روزرسانی مداوم پنجره با پیشرفت زمان ، محدودیت سرعت بیشتری را فراهم می کند.
به عنوان مثال ، با 5 درخواست در هر محدودیت سرعت API 60 ثانیه ، تصور کنید که کاربر 5 درخواست را در 10:00:30 انجام می دهد. در یک سیستم پنجره ثابت (هر پنجره جدید) آنها تا ساعت 10:01:00 صبر می کنند تا درخواست دیگری ارائه دهند. با این حال ، اگر API پس زمینه نیز هر دقیقه از تنظیم مجدد استفاده نکند ، کاربر ممکن است از حد مجاز سرعت فراتر رود. با داشتن یک پنجره کشویی ، کاربر درخواست بعدی خود را در ساعت 10:01:30 انجام می دهد ، زیرا اولین درخواست “با 60 ثانیه” به پنجره بیرون رفت و محدودیت سرعت نرم تری را بدون محدودیت مصنوعی زمان ایجاد کرد.
تنظیم سرور تست
قبل از غوطه ور شدن خود در محدودیت سرعت ، ما یک سرور تست ساده API ایجاد خواهیم کرد. این به ما این امکان را می دهد تا با خیال راحت محدود کننده سرعت خود را بدون ضربه زدن به محدودیت های واقعی API آزمایش کنیم.
برای چندین پروفایل کاربر ، ما سه کاربر داریم که “user1” ، “user2” و “user3” را به همراه کلیدهای مربوط به پروفایل-کلید 1 ، “پروفایل-کلید -2” و “پروفایل-کلید -3” مشخص کرده اند. می توانید تصمیم بگیرید که از چه شناسه هایی در سیستم خود استفاده خواهید کرد. همچنین ، در امتحان کردن سرعت های متغیر مختلف و Window_MS دریغ نکنید.
در یک پوشه پروژه Node.js Express را نصب کنید:
npm install express
یک فایل با یک تست ساده server.js ایجاد کنید:
// Updated Test Server with Header Authentication
const express = require('express');
const app = express();
const PORT = 3001;
app.use(express.json());
// Profile keys for authentication
const validProfiles = {
'profile-key-1': 'user1',
'profile-key-2': 'user2',
'profile-key-3': 'user3'
};
// Simple in-memory rate limiting for profiles
const rateLimits = {
'profile-key-1': [],
'profile-key-2': [],
'profile-key-3': []
};
const RATE_LIMIT = 5; // 5 requests per window
const WINDOW_MS = 10000; // 10 seconds
function checkRateLimit(profileKey) {
const now = Date.now();
if (!rateLimits[profileKey]) {
rateLimits[profileKey] = [];
}
// Remove old requests outside the window
rateLimits[profileKey] = rateLimits[profileKey].filter(time => now - time WINDOW_MS);
// Check if under limit
if (rateLimits[profileKey].length >= RATE_LIMIT) {
return false;
}
// Record this request
rateLimits[profileKey].push(now);
return true;
}
// Single POST endpoint that simulates social media posting
app.post('/api/post', (req, res) => {
const { post, platforms = ['twitter'] } = req.body;
const authHeader = req.headers['authorization'];
const profileKey = req.headers['profile-key'];
// Validate authentication header
if (!authHeader || !authHeader.startsWith('Bearer ')) {
return res.status(401).json({
success: false,
message: 'Invalid authorization header. Expected: Bearer primary-profile-key'
});
}
// Validate profile key
if (!profileKey || !validProfiles[profileKey]) {
return res.status(401).json({
success: false,
message: 'Invalid or missing profile-key header'
});
}
// Validate post content
if (!post) {
return res.status(400).json({
success: false,
message: 'Post content is required'
});
}
// Check rate limit for this profile
if (!checkRateLimit(profileKey)) {
return res.status(429).json({
success: false,
message: 'Rate limit exceeded',
profileKey,
retryAfter: 10
});
}
// Simulate some processing delay
setTimeout(() => {
res.json({
success: true,
id: `post_${Date.now()}`,
profileKey,
post,
platforms,
timestamp: new Date().toISOString()
});
}, Math.random() * 500 + 200); // 200-700ms delay
});
app.listen(PORT, () => {
console.log(`🚀 Header-Based Test Server running on http://localhost:${PORT}`);
console.log(`📝 POST /api/post with headers:`);
console.log(` Authorization: Bearer primary-profile-key`);
console.log(` Profile-Key: profile-key-1|profile-key-2|profile-key-3`);
console.log(`⏱️ Rate limit: 5 requests per 10 seconds per profile`);
});
سرور تست را شروع کنید:
node simple-test-server.js
سرور ارائه می دهد:
- نقطه پایانی تک /API /پست.
- محدودیت سرعت ساخته شده (5 درخواست برای 10 ثانیه در هر کاربر).
- پشتیبانی از 3 کاربر آزمایش: User1 ، User2 ، User3.
- تأخیرهای واقع بینانه در جواب.
- 429 پاسخ هنگامی که محدودیت های سرعت بیش از حد است.
مرحله 1: یک کلاس محدودیت سرعت اساسی در JavaScript بسازید
ابتدا بیایید یک محدود کننده سرعت ساده ایجاد کنیم که با استفاده از یک الگوریتم پنجره کشویی ، یک پنجره زمانی را دنبال می کند. ما از ادغام API برای رسانه های اجتماعی Ayrshare به عنوان راهنما استفاده خواهیم کرد ، اما این پنجره کشویی می تواند برای هر ادغام API اعمال شود.
class RateLimiter {
constructor(maxRequests = 10, windowMs = 60000) {
this.maxRequests = maxRequests;
this.windowMs = windowMs;
this.requests = [];
}
canMakeRequest() {
const now = Date.now();
// Remove requests outside the current window
this.requests = this.requests.filter(time => now - time this.windowMs);
return this.requests.length this.maxRequests;
}
recordRequest() {
this.requests.push(Date.now());
}
getWaitTime() {
if (this.requests.length === 0) return 0;
const oldestRequest = Math.min(...this.requests);
const timeToWait = this.windowMs - (Date.now() - oldestRequest);
return Math.max(0, timeToWait);
}
}
چه چیزی ساخته ایم: محدود کننده سرعت کشویی که درخواست برند زمان را ردیابی می کند و به طور خودکار ورودی های بارگیری شده را حذف می کند. این محدودیت سرعت صاف را بدون رویکردهای ناگهانی یک پنجره ثابت فراهم می کند.
خصوصیات اساسی:
- محدودیت های درخواست قابل تنظیم و ویندوزهای زمان.
- درخواست های منقضی خودکار.
- انتظار محاسبه زمان برای تأخیرهای صحیح.
مرحله 2: غلاف Fetch را با محدودیت سرعت اصلی اضافه کنید
حال بیایید استخراج را بپیچیم تا به طور خودکار مقابله کنیم تا سرعت محدود شود:
class RateLimitedFetch {
constructor(maxRequests = 10, windowMs = 60000) {
this.limiter = new RateLimiter(maxRequests, windowMs);
}
async fetch(url, options = {}) {
// Check if we can make the request
if (!this.limiter.canMakeRequest()) {
const waitTime = this.limiter.getWaitTime();
console.log(`Rate limit exceeded. Waiting ${waitTime}ms...`);
await this.sleep(waitTime);
}
// Record the request and make it
this.limiter.recordRequest();
return fetch(url, options);
}
sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
}
// Example usage with headers
const rateLimitedFetch = new RateLimitedFetch(3, 5000); // 3 requests per 5 seconds
async function testBasicRateLimit() {
try {
for (let i = 0; i 5; i++) {
console.log(`Publishing post ${i + 1}...`);
const response = await rateLimitedFetch.fetch('http://localhost:3001/api/post', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer primary-profile-key',
'Profile-Key': 'profile-key-1'
},
body: JSON.stringify({
post: `Test post ${i + 1} from rate limiter`,
platforms: ['twitter', 'linkedin']
})
});
console.log(`Post ${i + 1} response:`, response.status);
}
} catch (error) {
console.error('Error:', error);
}
}
testBasicRateLimit();
چه چیزی اضافه کرده ایم: غلاف استخراج که به طور خودکار با انتظار در صورت لزوم به حد مجاز سرعت می پردازد. این مانع از مرزهای API می شود که قبل از ظاهر شدن از آن جلوگیری می کند.
پیشرفت های کلیدی:
- وقتی از محدودیت های سرعت فراتر می رود ، انتظار اتوماتیک را داشته باشید.
- یک برنامه خواب ساده برای تأخیر.
- جایگزینی از استخراج بومی.
مرحله 3: منطق دوباره با پشتی نمایی
بیایید سیستم خود را با 429 پردازش خطا و اجرای نمایی برنامه اصلی برای مدیریت خرابی های برازنده API بهبود بخشیم:
class FetchWithBackoff extends RateLimitedFetch {
constructor(maxRequests = 10, windowMs = 60000, maxRetries = 3) {
super(maxRequests, windowMs);
this.maxRetries = maxRetries;
}
async fetch(url, options = {}) {
let attempt = 0;
while (attempt this.maxRetries) {
try {
// Check our local rate limit
if (!this.limiter.canMakeRequest()) {
const waitTime = this.limiter.getWaitTime();
console.log(`Local rate limit: waiting ${waitTime}ms...`);
await this.sleep(waitTime);
}
this.limiter.recordRequest();
const response = await fetch(url, options);
// Handle server-side rate limiting
if (response.status === 429) {
const retryAfter = response.headers.get('Retry-After');
const waitTime = retryAfter ? parseInt(retryAfter) * 1000 : this.getBackoffDelay(attempt);
console.log(`Server rate limit (429): waiting ${waitTime}ms... (attempt ${attempt + 1})`);
await this.sleep(waitTime);
attempt++;
continue;
}
return response;
} catch (error) {
if (attempt === this.maxRetries) {
throw error;
}
const waitTime = this.getBackoffDelay(attempt);
console.log(`Request failed: waiting ${waitTime}ms before retry... (attempt ${attempt + 1})`);
await this.sleep(waitTime);
attempt++;
}
}
throw new Error(`Max retries (${this.maxRetries}) exceeded`);
}
getBackoffDelay(attempt) {
// Exponential backoff: 1s, 2s, 4s, 8s...
return Math.min(1000 * Math.pow(2, attempt), 30000); // Cap at 30 seconds
}
}
// Example usage with headers
const fetchWithBackoff = new FetchWithBackoff(2, 5000, 3);
async function testFetchWithBackoff() {
try {
for (let i = 0; i 5; i++) {
console.log(`Publishing fetch with backoff post ${i + 1}...`);
const response = await fetchWithBackoff.fetch('http://localhost:3001/api/post', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer primary-profile-key',
'Profile-Key': 'profile-key-1'
},
body: JSON.stringify({
post: `Fetch with backoff test post ${i + 1}`,
platforms: ['twitter']
})
});
const result = await response.json();
console.log(`Post ${i + 1} published successfully:`, result.id);
}
} catch (error) {
console.error('Final error:', error.message);
}
}
testFetchWithBackoff();
چه چیزی اضافه کرده ایم: منطق تکرار هوشمند که هم خطاهای شبکه و هم محدودیت سرعت سرور را پردازش می کند (429 پاسخ).
پیشرفت های کلیدی:
- به نمایی برای جلوگیری از سرورهای بزرگ مبارز.
- احترام به عناوین برای استفاده مجدد از سرور.
- تلاش های قابل تنظیم برای تکرار با پیش فرض معقول.
- بین محدود کردن سرعت محلی و سرور تمایز قائل شوید.
مرحله 4: محدودیت بسیاری از کاربران برای ادغام API
حال بیایید سیستمی را ایجاد کنیم که محدودیت سرعت کاربر را پردازش کند – اینجاست که همه چیز برای سیستم عامل های مدیریت رسانه های اجتماعی بسیار قدرتمند است:
class MultiUserRateLimiter {
constructor(maxRequestsPerProfile = 10, windowMs = 60000, maxRetries = 3) {
this.maxRequestsPerProfile = maxRequestsPerProfile;
this.windowMs = windowMs;
this.maxRetries = maxRetries;
// Store rate limiters per profile key
this.profileLimiters = new Map();
}
getProfileLimiter(profileKey) {
if (!this.profileLimiters.has(profileKey)) {
// Create a FetchWithBackoff instance for each profile
this.profileLimiters.set(profileKey, new FetchWithBackoff(this.maxRequestsPerProfile, this.windowMs, this.maxRetries));
}
return this.profileLimiters.get(profileKey);
}
async fetch(url, options = {}) {
// Extract profile key from headers
const profileKey = options.headers?.['Profile-Key'] || options.headers?.['profile-key'];
if (!profileKey) {
throw new Error('Profile-Key header is required for multi-user rate limiting');
}
// Get the profile's rate limiter and use it
const profileLimiter = this.getProfileLimiter(profileKey);
console.log(`Profile ${profileKey}: making request...`);
return await profileLimiter.fetch(url, options);
}
// Utility methods for monitoring
getProfileStatus(profileKey) {
const limiter = this.profileLimiters.get(profileKey);
if (!limiter) {
return null;
}
return {
profileKey,
canMakeRequest: limiter.limiter.canMakeRequest(),
requestsThisWindow: limiter.limiter.requests.length,
waitTime: limiter.limiter.getWaitTime()
};
}
getAllProfilesStatus() {
const statuses = [];
for (const profileKey of this.profileLimiters.keys()) {
statuses.push(this.getProfileStatus(profileKey));
}
return statuses;
}
// Cleanup inactive profiles (optional)
cleanupInactiveProfiles(inactiveThresholdMs = 300000) { // 5 minutes
const now = Date.now();
for (const [profileKey, fetchWithBackoff] of this.profileLimiters.entries()) {
const limiter = fetchWithBackoff.limiter;
const lastRequest = Math.max(...limiter.requests, 0);
if (now - lastRequest > inactiveThresholdMs) {
this.profileLimiters.delete(profileKey);
console.log(`Cleaned up inactive profile: ${profileKey}`);
}
}
}
}
// Example usage with multiple profiles
const multiUserRateLimiter = new MultiUserRateLimiter(3, 10000, 3); // 3 posts per 10 seconds per profile
async function testMultiUserRateLimit() {
const profiles = [
{ key: 'profile-key-1', auth: 'Bearer primary-profile-key' },
{ key: 'profile-key-2', auth: 'Bearer primary-profile-key' },
{ key: 'profile-key-3', auth: 'Bearer primary-profile-key' }
];
const promises = [];
// Simulate multiple profiles publishing posts
for (const profile of profiles) {
for (let i = 0; i 5; i++) {
promises.push(
multiUserRateLimiter.fetch('http://localhost:3001/api/post', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': profile.auth,
'Profile-Key': profile.key
},
body: JSON.stringify({
post: `Post ${i + 1} from ${profile.key} via rate limiter`,
platforms: ['twitter', 'linkedin']
})
})
.then(response => response.json())
.then(data => console.log(`${profile.key} - Post ${i + 1} published:`, data.id || 'Success'))
.catch(error => console.error(`${profile.key} - Error:`, error.message))
);
}
}
// Monitor status
console.log('Initial status:', multiUserRateLimiter.getAllProfilesStatus());
try {
await Promise.all(promises);
console.log('All posts published successfully');
console.log('Final status:', multiUserRateLimiter.getAllProfilesStatus());
} catch (error) {
console.error('Some posts failed:', error);
}
}
testMultiUserRateLimit();
چه چیزی اضافه کرده ایم: محدود کردن تعرفه های فردی برای چندین کاربر ، فراهم کردن توزیع عادلانه منابع و جلوگیری از تأثیرگذاری هر کاربر بر دیگران. ایده آل برای سیستم عامل های مدیریت رسانه های اجتماعی که در آن هر مشتری به محدودیت های ارسال خود نیاز دارد.
پیشرفت های کلیدی:
- پیگیری محدودیت سرعت کاربر با محدودیت های جداگانه.
- کار ساده و مستقیم با درخواست های بدون دم پیچیده.
- برنامه های نظارت و تمیز کردن وضعیت کاربر.
- رسیدگی جدا شده (خرابی های یک کاربر بر دیگران تأثیر نمی گذارد).
یادداشت ها برای فیلتر
در کلاس Ratelimiter در مرحله 1 ما استفاده کردیم this.requests = this.requests.filter(time => now - time the .filter یک عملیات زمان خطی است که از طریق مارک های معتبر زمان تکرار می شود. اگر می خواهید Ratelimiter را بهینه کنید ، می توانید از یک لیست مرتبط برای آن استفاده کنید. قرار دادن حذف درخواست ها هنوز یک عمل خطی برای زمان خواهد بود ، اما با رسیدن به یک علامت زمانی در پنجره کشویی معتبر ، می توان آن را به حالت تعلیق درآورد.
یک پایه جامد برای به روزرسانی
با محدودیت سرعت مناسب ، شما قادر خواهید بود تعاملات API را با لطف انجام دهید و در حالی که در شرایط خوبی با ارائه دهنده API خود هستید ، تجربه بهتری را برای کاربران خود فراهم کنید. هیچ 429 اشتباه دیگر وجود ندارد ، دیگر کاربران لغو نشده و دیگر نگران متوقف کردن یا بلوک های حساب سکوی اجتماعی نیستید.


![چگونه می توان ذکرهای فیس بوک را ردیابی کرد؟ [2025] چگونه می توان ذکرهای فیس بوک را ردیابی کرد؟ [2025]](https://brand24.com/blog/app/uploads/2024/02/facebook_mentions_brand_image_blog_cover_615x345_czekadelko2_4.png)

