كيف بنوها؟ : تويتر Twitter

عام 0 geek4arab
Spread the love

لا احتاج ان اعرف تويتر متأكد ان الغالبية العظمى تستخدم هذه الخدمة بشكل يومي و طبعا هذه الخدمة اكبر مما يتوقعه البعض لكن سأركز على خدمة التايملاين Timeline Service لأنها الأكثر استخداما في نظري و سأتحدث عن بعض المشاكل و كيف تم حلها من قبل تويتر.

 

اولا نستعرض ما يتم استخدامه في تويتر:
Front-End : Ruby in Rails , Javascript
Middle-Tier: Ruby on Rails, Scala
Backend: Java, Scala C++ (Scribe)
Database: MySQL , FlockDB , Redis
طبعا و غيرها لكن هذه اهمها.

 

جميعنا نكتب تغريدات و تظهر على صفحتنا و معها تغريدات من نتابعهم و ايضا Retweets لكن ماذا يحصل عندما نكتب تغريده؟

سواء كنت تستخدم الويب او تطبيق ما سيتم الاتصال بالواجهة البرمجية Twitter API و سيتم تخزين التغريدة في نظام مغلق المصدر يسمى T-Bird و منها الى قواعد البيانات mySQL المنتشرة و المقسمة Sharded في مركز البيانات لكن عدد التغريدات مهول جدا و يجب ان يكون لكل تغريدة رقم تعريفي.

 

مثلا هذه التغريدة

 

الرقم التعريفي لها هو 274451543296708608 و هذا رقم كبير جدا على يتم انشائه بشكل متدرج من MySQL اذن ماذا عملت تويتر؟
انشأت نظام مفتوح المصدر اسمه Snowflake يتكفل بعملية الانشاء و الفرز ، بالتأكيد بشكل متوازي بسبب العدد الضخم من العمليات ( مثال هذا المشروع يقوم بانشاء 10 الآف تعريف في الثانية على الأقل) و بذلك يتم وضع رقم تعريفي لتغريدتك و طبعا هذا المشروع مكتوب بلغة Scala و هي لغة برمجة وظيفية و تقنيات البرمجة الوظيفية لها اثر واضح في الأنظمة المتوازية.

 

بعد ذلك يجب تحديد هذه التغريدة تذهب لمن و هنا يأتي دور FlockDB و هي قاعدة بيانات لا تعتمد على لغة SQL للاستعلام و مبنية على اساسيات Graph Theory و هي تفيد لتحديد علاقة من يتابع من و هكذا ببساطة هي مخزن كبير لقائمة من يجاورك و في هذه الحالة من يتابعك او من تتابعه لكن لماذا اختارت تويتر ان تبني هذه الأداة و تجعلها فوق MySQL على الرغم من امكانية عمل هذه بجدولين جدول للمستخدم و جدول ربط رقم تعريف المستخدم مع رقم تعريف من يتابع؟

السبب يعود للعدد الكبير جدا جدا في قائمة المتابعة خصوصا للمشاهير و قد تقول ان الحل هو عمل فهرسة و تخزينها في الذاكرة المؤقتة؟ هذه الطريقة لا تنجح لأن مجموع الفهرسة قد يتجاوز حجم الذاكرة و بذلك يكون هناك خلل و ايقاف و هذه كانت من اسباب سقوط تويتر بكثرة في المرحلة الماضية ، و كان هناك حل اخر و هو التخلص من عملية الـNormaliztion و تقسيمها على حزم. وهذا الحل كان ممتازا للعناصر الصغيرة لكن مشكلة كبرى لمن لديهم الكثير من المتابعين حيث عملية الحذف كانت تأخذ وقت كبير و ايضا في عملية الرد او المنشن يجب ان يتم التعرف على المستخدمين الذين يتابعون المرسل و المستقبل لكي يروا التغريدة.

 

كيف حلت FlockDB هذه المشكلة؟
في البداية يجب ان نعرف شي اساسي في نظرية المخططات Graph Theory و هي قائمة الجوار Adjacency List

الشرح في هذه الصورة.

بامكانك التخيل من هذه الصورة ان القائمة ستكون اضخم و مليئة بالارقام و الأرقام تمثل تعريف المستخدم UserID و حين عملية تحديد القائمة التي سترى تغريدتك ، سيتم فقط جلب قائمة من يتابعك ووضعها في التايملاين الخاص بهم و هذا اسرع بكثير و ايضا بالامكان معرفة من حظر من ، وفي عمليات اعقد اقتراح حسابات للمتابعة (Graph Analysis)

FlockDB ايضا مكتوب بلغة Scala.

 

بعد عملية التحديد ستكون هناك عملية اضافة التغريدة في تايملاين كل متابع و هنا يأتي دور Kestrel وهو Message Queuing System يتكفل بعملية Fanout لتايملاين المتابعين بشكل متوازي ( 4000 متابع لكل عملية). و Kestrel ليس مخصصا للتايملاين فقط بل يستخدم في انظمة كثيرة في تويتر و ايضا تستخدمها Instagram لاصدار اكثر من مساحة للصورة. Kestrel مكتوب بلغة Scala ايضا و هو البديل الناجح لنظام Scarling المكتوب بلغة Ruby.

 

التايملاين المخصص لكل مستخدم في تويتر مخزنة في الذاكرة مسبقا Cached باستخدام Redis و هي قاعدة بيانات لا تعتمد على SQL و ميزتها انها سريعة و لها قدرة على تخزين هياكل لبيانات مختلفة

اذاً التايملاين للمستخدم الواحد هي عبارة عن Instance من Redis مكررة في اكثر من سيرفر لكن لماذا التكرار؟ السبب هنا لتفادي الأخطاء ، لنفترض ان سيرفر ما في مركز البيانات تعطل و فيه التايملاين الخاص بك لن تشعر بذلك لأنه سيتجه الى نسخة اخرى منها مباشرة.

 

لكن كيف هو شكل التايملاين في Redis!! ، اذا هي فقط تخزن هياكل بيانات مثل lists – int – string.

الشكل بسيط جدا في حالة التغريدات و الرد

في حالة الريتويت يجب ان يكون هناك مؤشر للتغريدة الأصلية

بعد هذا كله يتم تحضير التايملاين و اضافة التغريدات حال صدورها.

 

معظم هذه العمليات تحصل فقط في ضغطة زر و ايضا هناك عمليات اخرى مثل المتابعة حينما تتابع انت تضاف الى قائمة المتابعة بشكل مباشر و تأتيك اي تغريدة جديدة من ذلك المستخدم ، وهناك عملية البحث وتويتر يستخدم اصدار معدل من مشروع Lucene المكتوب بالجافا.

لكن كيف يتم التواصل بين هذه الأنظمة على الرغم من اختلاف اللغات في معظم الأحيان و ايضا التباعد؟

هنا يأتي دور RPC Frameworks و طبعا من اشهرها Thrift و الذي بنته فيسبوك و تستخدمه شركات كثيرة و المشروع مفتوح المصدر و مكتوب بلغة C++.

 

اتمنى ان اكون وفقت في الكتابة و الشرح و اتمنى ترشيح تطبيق او موقع اخر لشرحه و شكرا لكم.

الكاتب geek4arab

geek4arab

مواضيع متعلقة

التعليقات مغلقة