ليه auto_increment مش كفاية؟
الـ auto_increment بتاع الداتابيز مابيشتغلش كويس لما يبقى عندك كذا سيرفر. المطلوب IDs: فريدة، أرقام بس، ٦٤ بت، مرتبة بالوقت، وآلاف في الثانية.
أربع طرق
| الطريقة | الفكرة | الحكم |
|---|---|---|
| Multi-master | كل سيرفر يزود بـ k (عدد السيرفرات) | صعب تكبّره، ومش مرتب بالوقت عبر السيرفرات |
| UUID | ١٢٨ بت عشوائي، كل سيرفر يولّد لوحده | سهل ومفيش تنسيق. طويل، مش رقم، ومش مرتب |
| Ticket Server | سيرفر مركزي واحد بيوزع أرقام | بسيط. بس SPOF: لو وقع، محدش يقدر يولّد ID |
| Snowflake | تقسم الـ ٦٤ بت لأجزاء | ده الحل اللي بنرشّحه |
تشريح الـ Snowflake ID
| الجزء | الحجم | بيعمل إيه |
|---|---|---|
| sign | ١ بت | دايمًا ٠، عشان الرقم يفضل موجب |
| timestamp | ٤١ بت | ملي ثانية من epoch مخصص — يكفي حوالي ٦٩ سنة، وبيخلي الـ IDs مرتبة بالوقت |
| datacenter | ٥ بت | ٣٢ داتا سنتر |
| machine | ٥ بت | ٣٢ ماكينة في كل داتا سنتر |
| sequence | ١٢ بت | ٤٠٩٦ ID لكل ماكينة في كل ملي ثانية |
Checklist الـ IDs
🧠 اختبر نفسك
١) ليه الـ ticket server خطر في سيستم كبير؟
لأنه نقطة فشل واحدة: لو وقع، توليد الـ IDs يقف.
٢) إيه ترتيب أجزاء الـ Snowflake من الشمال لليمين؟
sign، ثم timestamp، ثم datacenter، ثم machine، ثم sequence.
٣) ماكينة واحدة تقدر تولّد كام ID في ملي ثانية واحدة بالنسب دي؟
٤٠٩٦، لأن الـ sequence ١٢ بت.
٤) ساعة سيرفر رجعت لورا ثانيتين. إيه الخطر؟
ممكن يطلع نفس الـ ID تاني، لأن الـ timestamp والـ sequence هيتكرروا.