ال thread دى هكمل كلام فيها شوية عن ال implementation وازاى تحط الداتا بتاعتك بشكل يساعدك تقدر تستخدمها بسهولة ، خلاص انت قررت تستخدم كافكا وعارف هتعمل ايه تعالى بئا نشوف حكاية ال implementation اول حاجة كدا kafka does not support ordering across partitions طيب ايه حكاية ال
ال partition وليه انا محتاج اخلى ال topic يكون له اكتر من بارتشن ببساطة البارتشن هيقدر يخليك توزع ال offsets على اكتر من جزء ودا بيخلى ال consumers تقدر تسحب الداتا parallel يعنى لو عندك توبيك عليه 3 بارتشن تقدر تقوم 3 consumer instances جوا group فى حالة دى هتقدر تسحب الداتا من
التوبك بدون تعارض يعنى كل كونسيمر هيسحب من بارتشن طيب لو عندك 3 بارتشن وواحد كونسيومر هيسحب من ال 3 عادى بس فى الحالة دى هيكون ابطئ من 3 شغالين بس خلى بالك عدد البارتشنز الكتير ممكن يعملcpu and memory overhead بس عندك انت مش عندك كافكا يعنى جهازك او الابلكشن بتاعك هيستهلك
ريسورسس كتيرة عموما لو عندك 3 ريبلكا ف 3 بارتشن معقول ودا مش شرط لكن شوف الى يناسبك طيب نعمل ايه عشان نخلى المسج مترتبة يعنى in order فى حالة دى الداتا إلى محتاجة تيجى ورا بعضها ادي المسج دائما نفس ال partition key فى الحالة دى كافكا بيحط كل المسج دى فى نفس البارتشن بس خلى بالك
من الالجوريثم إلى هتعمل بيها key لانها فى النهاية ممكن توصل لأن بارتشن يكون مليان والباقى idle ممكن تكون ال hash function مناسبة ليك وممكن لأ فدى ترجعلك الطريقة إلى هتوزع بيها الداتا بتاعتك بشكل يحقق لك ال business goal بتاعك فدى من أهم الحاجات إلى ممكن تودي ال consistency
فاى events محتاجة تكون in fixed order محتاج يروح نفس التوبك نفس البارتشن
طيب بالنسبة الداتا وعلاقتها ببعض هل لو عندى events بتتكلم عن different entities تروح نفس ال topic ولا توبك مختلفة دى بئا it depends زى ما اخوانا الاركتكتس بيقولوا لو عندك entity معتمد على واحد تانى زى مثلا
طيب بالنسبة الداتا وعلاقتها ببعض هل لو عندى events بتتكلم عن different entities تروح نفس ال topic ولا توبك مختلفة دى بئا it depends زى ما اخوانا الاركتكتس بيقولوا لو عندك entity معتمد على واحد تانى زى مثلا
Customer , customer address فالافضل يروحوا نفس التوبك ، لو ملهمش علاقة ببعض وكمان تحت تصرف اكتر من فريق عمل فكدا أفصلهم افضل ، نقطة تانية مهمة لو عندك events ل entity ال rate بتاعها أعلى من entity التانية بشكل ملحوظ يفضل فصلهم ، طيب لو عندنا بئا event لأكتر من entity
زى مشتريات عميل بالبرودكتس الأفضل هنا انك تبعتهم فى atomic message واحدة ومتوزعهمش على اكتر من مسج لااكتر من توبك عشان تقدر توصل لمستوى كويس من consistency لما الداتا دى توصل ، نقطة تانية ممكن نبص عليها أن لو عندك مجموعة من ال consumers بيقرأوا نفس المجموعة من التوبكس الأفضل
انك تدمج التوبكس دى فى توبك واحدة ، بردوا لو بتستخدم KTable ودا اسمه change log topic يفضل يكون معزول عن بقية التوبكس , نقطة تانية بردوا أن كافكا ستريم internal بيكريت توبكس من التوبك إلى انت اصلا بتعمل عليه ستريم بنفس الكونفجريشن ، يفضل استخدام scheme registery عشان مش اى حد
يبعت على التوبك اى زبالة ممكن تعمل بريك لل consumers بتوعك يعطلك البزنس
نقطة أخيرة كافكا حاليا بيسبورت ال authentication and ACL بطرق مختلفة فالسكيورتى مهمة لو الكافكا متاح لأكتر من فريق عمل أو exposed externally
جاري تحميل الاقتراحات...