,
15 tweets,
3 min read
Read on Twitter
بما أنا ضيوف تويتر , فسأبدأ بشرح مختصر لبعض التقنيات التي يستخدمها و لماذا , احب ان انوه إلى أن تويتر بيئة ديناميكية أي تغير تقنياتها بسرعة و لذا سأكتب باختصار عن ما استطعت رصده من خلال مدونات مهندسي تويتر و متكلميهم في المؤتمرات بالاضافة إلى المقالات العامة .
في البداية عندما نكتب twitter.com و قبل ان نصل إلىه كانت تتلقفنا خدمة GeoDNS التي تقوم بمعرفة موقعنا الجغرافي من خلال IP المتصل ثم تحوله لDataCenter الأقرب له , غيرّها تويتر لاحقاً و استخدم BGP Anycast
اشترك Twitter في تلك الخدمتين المزودتين للDNS لأجل السرعة .
اشترك Twitter في تلك الخدمتين المزودتين للDNS لأجل السرعة .
و صلنا إلى اقرب DataCenter وواجهنا في البداية Web Server من نوع Nginx على Linux, لكن تويتر لا تستخدمه كـweb server و انما كـLoad Balancer . و ظيفته توزيع الطلبات و الحِمل على اكثر من Web Servers .
في تلك الWeb Servers التي تسمى flapps يوجد موقع Twitter الذي حولوه منذ 3 اشهر فقط على تقنية Nodejs + Express بالإضافة إلى خدمات صممت بلغة Scala و هذه اللغة تعمل على JVM كما تعمل Java إلا انها هي و Clojure تستخدمان الFunctional Programming.
الأن بدأ العمل على سحب البيانات الخاصة بصفحة الدخول , بالنسبة لتسجيل الدخول - سنتجاهل الكيفية و الجانب الأمني - يقوم تويتر باسترجاع بيانات المستخدم الرئيسية فقط مباشرة من قواعد بيانات من نوع MySQL . فلا مكان هنا للCache حيث ان Consistency مهم جداً .
مفهوم الConsistency جداً مهم , اذا لاحظت في صفحة تويتر فإن بيانات عدد التغريدات او الاعجاب قد تختلف من صفحة إلى اخرى و قد تتأخر الإشعارات , كما أن كثير من تغريدات الذين تتابعهم قد تصل إلى اصدقائك قبلك , هذا يعني أنه يتم خدمتكم من خلال Servers مختلفة .
فال Availability للخدمة لدى Twitter أهم من الConsistency . لكن ليس عندما يتعلق الأمر بالUsers و الدخول فالـ C و الP ( Persistent ) أهم من الـA . هذا يسمى مبدأ CAP و فحواه أنه لا يمكنك الحصول على الثلاثة معاً و يجب عليك ان تضحي بواحد .
تم تسجيل الدخول بنجاح و بدأ العمل الصعب , قبل أن ابدأ في شرح كيف يتم استرجاع بيانات التغريدات , حيث تقوم تويتر بتخزين المستخدمين و التغريدات و في MySQL . اما علاقات المستخدمين ( Follows ) كونها معقدة قليلاً فتتم في MySQL و FlockDB.
FlockDB هي قاعدة بيانات NoSQL من نوع Graph
تخزن فيها العلاقة كالتالي ( user1 --- follows ----> user2 ) فإذا حذفت العلاقة لا يحذف السجل . و حتى في MySQL لا يقومون بأي عملية حذف بل يغيرون Flag ليظهر كمحذوف .
تخزن فيها العلاقة كالتالي ( user1 --- follows ----> user2 ) فإذا حذفت العلاقة لا يحذف السجل . و حتى في MySQL لا يقومون بأي عملية حذف بل يغيرون Flag ليظهر كمحذوف .
اما الصور و مقاطع الفيديو فيتم تخزينها في قاعدة بيانات صممتها تويتر اسمها Blobstore . اما البث الحي فيتم من خلال Spark Streaming و الإشعارات من خلال الربط مع خدمة الإشعارات لدى Google Notification Service , كما أن المحادثات من خلال Kafka .
من خلال Kafka فأي عملية نقوم بها من Follow أو Like او Tweet او Retweet
توزع على Kafka Servers اولاً , ثم بواسطة انظمة بلغة Scala تُقرأ من هناك ثم تنتقل إلى الMySQL الذي يقوم بعملية Horizental Partioning إلى سيرفرات اخرى عادة 3 في اثنين او ثلاثة DataCenter مختلفة .
توزع على Kafka Servers اولاً , ثم بواسطة انظمة بلغة Scala تُقرأ من هناك ثم تنتقل إلى الMySQL الذي يقوم بعملية Horizental Partioning إلى سيرفرات اخرى عادة 3 في اثنين او ثلاثة DataCenter مختلفة .
لأن هناك تقسيم افقي للبيانات في MySQL فإنها لا تستخدم تويتر auto_sequence او UUID للIDs و انما تقوم بإنشائها عن طريق Twitter Snowflake لانه اقل 64bit و يسهل عمل Index له . الان تم تخزين البيانات , لكن لم تنتهي .
فلدى تويتر نوعين اخرين من قواعد البيانات يقوم بنقل البيانات إليها بواسطة أداة ETL اسمها Crane ( اسم على مسمى ) النوع الأول هو FlockDB للعلاقات و الآخر Apache HBase لعمليات التحليل .
ما ذكرته في الاعلى موزع على الاف من اجهزة الخوادم بعضها متطابق و بعضها لا , يتم ادارتها من خلال ادوات مثل Apache Mesos و Apache ZooKeeper و Puppet . لا اضمن ان ماذكرته مطابق للواقع فكما ذكرت كل شيء معرض للتغيير و الهدف ثقافي فقط .
إلى الان لم نصل إلى كيف تعرض تويتر التغريدات للمستخدمين في الTimeline , فهذا فقط الجزء الأول . اعتذر عن عدم تزويد الشرح برسومات لضيق الوقت و حتى لا تعتمد من احد .
دمتم بخير .
دمتم بخير .
