VOL64: Deep Dive Into Redis Persistence Strategies
أهلًا وسهلا بكم في العدد الرابع والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الرابع والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Deep Dive Into Redis Persistence Strategies
How Figma Secures Internal Web Applications
Comprehensive Guide Into Prompt Engineering
How to Avoid Double Payment
الإصدار الأول من مدونات فطين في تصميم النظم
Deep Dive Into Redis Persistence Strategies
كلنا عارفين إن Redis واحدة من أسرع الـ Key-Value Stores اللي موجودة في الساحة، وأكتر استعمالتها بيكون في الـ Caching وعشان كده أكيد جه في دماغ أي حد بيستخدمها سؤال مهم: "لو حصل crash للسيرفر، إيه اللي هيحصل للداتا؟"
والإجابة هنا بتكون: على حسب إحنا مشغلين أنهي طريقة من طرق الـ Persistence (الحفاظ على البيانات) اللي Redis بتوفرها.
فورقة وقلم وتعالوا نفهم مع بعض:
يعني إيه Persistence أصلاً؟
إيه الأنواع اللي Redis بتوفرها؟ والفرق بينهم؟
أستخدم أنهي واحدة؟
Data Persistence
الـ Data Persistence معناها إن الـ data اللي في الذاكرة (RAM) ما تضيعش لما السيرفر يوقع أو يحصل فيه مشاكل أو حتى يحصله restart. وكلنا عارفين إن redis شغالة أساسًا in-memory، وده معناه إنها سريعة جدًا بس عرضة لتضيع كل البيانات لو ما فيش backup نقدر نسترجع بيه البيانات دي.
عشان كده Redis بتوفرلنا طريقتين رئيسيتين لحفظ الداتا:
1. RDB (Redis Database)
2. AOF (Append Only File)
RDB Snapshotting
في الطريقة دي Redis بتعمل snapshot من كل الداتا الموجودة في الذاكرة (RAM) وتحطها في ملف .rdb.
ازاي الـ RDB بيشتغل؟
كل شوية (حسب الـ config أو من خلال manual trigger)، Redis بتاخد نسخة Snapshot من كل البيانات اللي موجودة وتكتبها في ملف على الـ disk. فلو حصل crash لأي سبب من الأسباب للـ redis instance .. تقدر تعمل restore للداتا بشكل طبيعي من آخر snapshot حصل.
فالأول Redis بتعمل
fork(): فبيكون عندنا Parent / Child Process الـ Parent Process بتقدر تستقبل read/write requests بشكل طبيعي جدًا، في حين إن الـ child process اللي حصلها fork بتبدأ تكتب الـ snapshot في ملف مؤقّت على الـ disk.بعد ما الـ child process يخلص، الملف المؤقّت بيتغيّر للـ
dump.rdbبشكل آمن.العملية دي بتستخدم كمان الـ copy-on-write علشان تقلل التأثير على الأداء خصوصًا لو كان حجم البيانات كبير فتقدر تنقل البيانات بشكل فعال.
AOF (Append Only File)
الطريقة دي بتخلي Redis يكتب كل عملية write بتحصل (زي set, del) في ملف log. بمعنى أدق كل الـ commands اللي حصلت بتتكتب في الـ .log وبتتخزن على الـ Disk.
ازاي الـ AOF بيشتغل؟
كل ما يحصل أي تعديل في الداتا، Redis بتكتب الـ command اللي حصل في آخر ملف الـ AOF. بشكل append-only ولما يحصل وليكن restart أو crash، تقدر وقتها تقرأ كل العمليات اللي في الملف ده واحدة واحدة وترجع الداتا.
How Figma Secures Internal Web Applications
فريق الأمان في Figma بنى نظام جديد عشان يوفروا وصول آمن للتطبيقات الداخلية بتاعتهم. فخلوني اشارك معاكم إيه اللي اتعلموه من التجربة دي، وإزاي النظام اصبح جزء ومنهج شامل للأمان عندهم.
النظام ده بيتيح الوصول للتطبيقات الداخلية بشكل آمن وباستخدام Reusable Cloud Components وبعض التقنيات الحديثة والآمنة. وكانوا شايفين إن النمط ده ممكن يفيد فرق تانية في خصوصا كمان في حماية التطبيقات الداخلية الحساسة بتاعتهم.
Context
زي أغلب شركات التكنولوجيا، Figma بتعتمد على مجموعة من التطبيقات الداخلية اللي هم طوروها بنفسهم ورا الكواليس. وده بداية من الـ Software Deployments لغاية دعم العمليات المختلفة في الـ Business، وأدوات الويب اللي طوروها مهمة جدًا في الـ Workflow بتاع الموظفين عندهم.
التطبيقات دي كمان لها متطلبات أمان شديدة جدًا عشان يضمنوا إن بس الموظفين المصرح لهم يقدروا يوصلوا ليها بشكل آمن.
وطبعًا زي ماحنا عارفين ان الـ Attackers والـ Cybercriminals عندهم باع وصيت في استهداف الأنظمة الإدارية كطريقة للوصول لبيانات المستخدمين وده شوفناه على مر السنين في تجارب لشركات كتيرة واللي أصبح دلوقتي موضوع غاية في الأهمية إن كل شركة تكون عندها نظام حماية قوي لخدماتها.
وعشان يحموا المستخدمين بتوعهم وبياناتهم من ان يحصل عليها أي اختراقات، اشتغلوا على بناء نظام يقدر يوفر وصول آمن للتطبيقات الداخلية بتاعتهم وتضمن وصول آمن للتطبيقات دي.
Approach
النهج بتاعهم بيعتمد على مكونات جاهزة بدلًا من اعادة صنع العجلة وده عشان يسهلوا عملية الصيانة اللي ممكن تكون كبيرة جدًا ويستفيدوا كذلك من تأثيرات الشبكات الأمنية اللي موجودة واللي اتبذل فيها مجهود كبير، لكن في نفس الوقت بدأوا يربطوها بطرق جديدة عشان يضمنوا تحقيق الـ Security Best Practices ومن البداية، كان عندهم مجموعة من المتطلبات :
تجربة مستخدم سلسة: إنتاجية الموظفين عندهم أولوية قصوى، فعشان كده نظام الـ Authentication بتاعهم لازم يكون سريع، موثوق، وسهل الوصول ليه.
مبدأ الـ Zero-Trust: إن الموظف يسجل الدخول من شبكة "موثوقة" مش كفاية لضمان الثقة. فلما بيحصل عملية Authentication للعملاء، نموذج الأمان بتاعهم لازم يكون معتمد على تأكيدات أقوى بكتير من مجرد الاعتماد على عنوان الشبكة لوحده.
إمكانيات Authentication حديثة وقوية: هم عاوزين يستفيدوا من أحدث وأفضل تقنيات أمان الويب الموجودة لحماية التطبيقات الداخلية بتاعتهم. لإنهم عارفين أهمية موضوع زي ده ، وأي مهندس بيشتغل على تطبيق داخلي لازم يقدر بسهولة يستفيد من الدفاعات دي زي WebAuthn داخل النظام اللي بيبنوه.
الـ Centralized Authorization: فرق الـ IT والأمان عندهم لازم يقدروا يوزعوا، ويراقبوا، ويعدلوا الصلاحيات اللي بيدوها للموظفين بشكل فعال. وده لإن النظام اللي بيكون موزع بزيادة هيبقى من الصعب فهمه أو التحكم فيه بسهولة، وهيؤدي بالشكل ده إما لمنح صلاحيات زيادة كتيرة لكل موظف أو لإحباط المستخدم.
أقل جهد لفريق الأمان: باعتبار ان فريق الآمان عندهم كان صغير ومعاهم جزء كبير محتاجين يأمنوه ومهمة صعبة، الحل بتاعهم كان الوصول للتطبيقات مش لازم يتطلب شغل SRE أو عمليات Operational كتير مستمرة.
Comprehensive Guide Into Prompt Engineering
في عالم الذكاء الاصطناعي المتطور، أصبح استخدام النماذج اللغوية الضخمة (LLMs) جزءًا أساسيًا في عمل ال developers وال ML Engineers.
هنا تأتي أهمية ال Prompt Engineering، حيث نتعلم كيفية صياغة التعليمات (prompts) بطريقة تجعل الـ LLMs تنتج مخرجات دقيقة وذات مغزى. ورغم تدريب ال LLMs على كميات ضخمة من البيانات، إلا أن وضوح ال promptsيزيد من دقة النتائج.
في هذه المقالة، سنستكشف استراتيجيات الـ Prompt Engineering لتحسين أداء النماذج وتوسيع تطبيقاتها.
تعريف الـ Prompt Engineering
ببساطة، هي فن كتابة الأسئلة أو التعليمات اللي بتوجه الـ LLMs، علشان نطلع منها النتيجة اللي إحنا عايزينها. العملية دي بتعتمد على شوية إرشادات (guidelines) لو اتبعناها صح، هتحسن بشكل كبير من جودة الردود اللي بنحصل عليها.
بعض هذه الإرشادات مستمدة من تجارب المستخدمين العاديين، والبعض الآخر من تطوير OpenAI، بينما جزء منها يعتمد على فهمنا العميق لمعالجة اللغة الطبيعية (NLP).
مراحل تطورات الـ Prompt engineering
Enhanced contextual understanding: مع تطور الـ LLMs زي GPT-4، بقت قادرة على فهم السياق بشكل أدق.
Adaptive prompting techniques: الـ models دلوقتي بتتعلم ازاي تعدل ردودها حسب طريقة كتابة المستخدم. تفضيلاته وبالتالي المحادثه أصبحت natural and user-friendly
Multimodal prompt engineering: فيه تقنيات جديدة بتتعامل مع أنواع مختلفة من البيانات زي النصوص والصور.
Real-Time Prompt Optimization: تقديم ملاحظات فورية على ال prompt
Integration with Domain-Specific Models: ال Domain-Specific Models بتكون مدربه علي داته من مجال معين وبتكون متخصصه.
LLM Output Configuration
لما تختار الmodel بتاعك، لازم تكوِّن الإعدادات الخاصة بيه بشكل صحيح. أغلب ال LLMs بتوفر لك اختيارات كتير تتحكم في المخرجات.
1- طول المخرجات Output Length
هنا بحدد عدد ال tokens اللي هتطلع في الرد. تقليل ال Output length مش هيخلي الmodel يكتب بشكل مختصر أو دقيق، هو هيقول نفس الكلام بس اول ما ال capacity تخلص هيقطع كلامه.
2- التحكم في العينة Sampling Controls
الموديل بيتوقع احتمالات (probabilities) لعدد من ال tokens الي ممكن تيجي بعد الكلمة الحالية كل واحد قصاده احتماليه ان هو يكون الtoken القادم. في techniques زي Temperature وTop-K وTop-P بتساعدني أتحكم في كيفية اختيار الرموز.
1) Greedy Decoding
هو طريقة بسيطة بيستخدمها ال LLM عشان تولد الToken القادم. الطريقة دي بتعتمد على اختيار الكلمة أو الtoken اللي احتمالها أعلى (high probability) .
How to Avoid Double Payment
أحد أكبر المشاكل اللي ممكن نواجهها في تصميم الأنظمة الخاصة بالدفع , والمعاملات المالية هي أنك تدفع العميل أكتر من مرة, وعشان كده واحنا بنصمم Payment System محتاجين ناخد في الاعتبار ان عملية الدفع لازم نضمن انها هتتم مرة واحدة فقط لا غير.
وطبعًا عشان نحقق الضمان ده واللي بنسميه Exactly-Once Delivery بيقابلنا تحديات مش سهلة خصوصًا لو بنتعامل كمان مع Distributed Systems.
المعادلة الرياضية
لو جينا نبص للمشكلة اللي بنواجهها دي رياضيًا فالمفترض عشان نقول أن فيه حاجة تتم مرة واحدة بس فده معناه انها بتطبق الشروط دي:
اتنفذت على الأقل مرة
اتنفذت كحد أقصى مرة
يعني ايه الكلام الغريب ده باه ؟
بكل بساطة عشان نعالج مشكلة الـ Double Payment واننا منخليش الـ Customer يتحاسب مرتين أو أكتر, احنا عاوزين طريقة نضمن بيها , ان عملية الدفع على الأقل حصلت مرة .. وفي نفس الوقت نضمن أنها متحصلش أكتر من مرة عشان ميتحاسبش مرتين أو أكتر.
وعشان نحقق ده هنستعمل:
الـ Retryer عشان نضمن أول شرط ان عملية الدفع على الأقل حصلت مرة.
الـ Idempotency Key عشان نضمن تاني شرط وهو أن عملية الدفع ما تحصلش أكتر من مرة.
Retryer
من خلال استعمالنا للـ Retryer كده احنا هنضمن أن لو حصل أي مشكلة في عملية الدفع , سواء كانت مشكلة Network أو Timeout مثلًا أو Server Failure أو أيا كان السبب ايه .. فاحنا ضامنين أن عملية الدفع هيتعاد تنفيذها تاني لحد ما تنجح وبالتالي هنا احنا بنحقق أول شرط الا وهو الـ At Least Once Delivery.
فكده احنا حققنا أول شرط وضمنا ان لو حصل أي مشكلة في الدفع , هنحاول أكتر من مرة لحد مالعملية تنجح , فعلى الأقل مرة واحدة هتنجح.
فاحنا لو بنحاول نشتري حاجة بـ 100 جنيه , والعملية دي فشلت , ممكن نفضل نحاول لحد ما تنجح ..
طب ماذا لو نجحت , وحاولنا مرة تانية بالخطأ ؟ أو حصل هنا ان اتبعت Retrying تاني بعد ما العملية نجحت ؟ هنا هنروح لتاني حل وهو الـ Idempotency Key عشان نضمن أننا منقعش في المشكلة دي وندفع الـ Customer أكتر من مرة.
Idempotency Key
يعني ايه Idempotency ؟
الـ Idempotency معناها من وجهة نظر الـ APIs ان الـ Request مهما اتبعت هيلاقي نفس النتيجة فعشان كده مثلا بنقول أن الـ POST Request مش Idempotent لانه مع كل Request مش هيحصل على نفس النتائج عكس الـ Get على سبيل المثال.
الـ Idempotency Key محتاجين انه يكون Unique زي ما شوفنا عشان الـ Server يقدر يميز بين كل عملية دفع والتانية , وبالتالي الشائع في أغلب الشركات زي Striple , PayPal وغيرهم كتير هو استعمال الـ UUID.
طب الـ Idempotency Key ده بيتبعت ازاي ؟
المتعارف عليه والشائع انه الـ Client هو اللي بيعمله Generate وبيكون بـ Expiry معينة على سبيل المثال فبعد وقت محدد بيحصله Expiration و بيتبعت في الـ Request Headers وبيكون بالشكل الآتي :
{idempotency-key: key_value}
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
