يوم جيد!
أريد أن أشارككم قصة حول تنفيذ ذاكرة التخزين المؤقت على قاعدة بيانات Tarantool وميزات العمل الخاصة بي.
أعمل كمطور جافا في شركة اتصالات. المهمة الرئيسية: تنفيذ منطق العمل للمنصة التي اشترتها الشركة من البائع. من الميزات الأولى ، هذا عمل صابون والغياب شبه الكامل للتخزين المؤقت ، إلا في ذاكرة JVM. كل هذا جيد بالطبع حتى يتجاوز عدد مثيلات التطبيق عشرين ...
في سياق العمل وفهم ميزات النظام الأساسي ، جرت محاولة للقيام بالتخزين المؤقت. في ذلك الوقت ، تم إطلاق MongoDB بالفعل ، ونتيجة لذلك ، لم نحصل على أي نتائج إيجابية خاصة كما هو الحال في الاختبار.
في بحث آخر عن البدائل والمشورة من صديقي العزيز
mr_elzor ، تقرر تجربة قاعدة بيانات Tarantool.
في دراسة سريعة ، ظهر الشك فقط في لوا ، لأنني لم أكتبها من كلمة "بالكامل". ولكن مع وضع كل الشكوك جانبا ، بدأ في التثبيت. حول الشبكات المغلقة والجدران النارية ، أعتقد أن القليل من الناس مهتمون ، لكنني أنصحك بمحاولة الالتفاف عليها ووضع كل شيء من المصادر العامة.
خوادم الاختبار مع التكوين: 8 وحدة المعالجة المركزية ، ذاكرة الوصول العشوائي 16 جيجابايت ، 100 جيجابايت محرك الأقراص الصلبة ، ديبيان 9.4.
تم التثبيت وفقًا لتعليمات الموقع. وهكذا حصلت على خيار مثال. ظهرت الفكرة على الفور عن واجهة بصرية يعمل بها الدعم بسهولة. أثناء البحث السريع ، وجدت وتكوين
tarantool-admin . يعمل في Docker ويغطي مهام الدعم بنسبة 100٪ ، على الأقل حتى الآن.
ولكن دعنا نتحدث عن أكثر إثارة للاهتمام.
كان الفكر التالي هو تهيئة الإصدار الخاص بي في تكوين السيد والعبد داخل نفس الخادم ، لأن الوثائق تحتوي فقط على أمثلة مع خادمين مختلفين.
بعد قضاء بعض الوقت في فهم lua ووصف التكوين ، أقوم بتشغيل المعالج.
أقع على الفور في ذهول ولا أفهم سبب الخطأ ، لكنني أرى أنه في حالة "التحميل".
أركض عبد:
وأرى نفس الخطأ. هنا ، عادة ما أبدأ في الضغط ولا أفهم ما يحدث ، لأنه لا يوجد شيء في الوثائق المتعلقة به على الإطلاق ... ولكن عند التحقق من الحالة ، أرى أنه لم يبدأ على الإطلاق ، رغم أنه يقول أن الحالة "قيد التشغيل":
ولكن في الوقت نفسه ، بدأ السيد العمل:
إعادة تشغيل العبد لا يساعد. أتساءل لماذا؟
أوقف السيد. وتنفيذ الإجراءات في ترتيب عكسي.
أرى أن العبد يحاول البدء.
أبدأ المعالج وأرى أنه لم يرتفع وتحولت عمومًا إلى حالة اليتيم ، بينما انخفض العبد بشكل عام.
يصبح أكثر إثارة للاهتمام.
أرى في سجلات الرقيق أنه رأى السيد وحاول المزامنة.
2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: binding to 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto/101/main I> binary: bound to 0.0.0.0:3302 2019-02-19 17:13:45.113 [20751] iproto/101/main D> binary: listening on 0.0.0.0:3302... 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] iproto D> cpipe_flush_cb: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: locking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main D> cbus_endpoint_fetch: unlocking &endpoint->mutex 2019-02-19 17:13:45.113 [20751] main/101/slave2 I> connecting to 1 replicas 2019-02-19 17:13:45.113 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECT 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t I> remote master 825af7c3-f8df-4db0-8559-a866b8310077 at 10.78.221.74:3301 running Tarantool 1.10.2 2019-02-19 17:13:45.114 [20751] main/106/applier/replicator@tarantuldb-t D> => CONNECTED 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> connected to 1 replicas 2019-02-19 17:13:45.114 [20751] coio V> loading vylog 14 2019-02-19 17:13:45.114 [20751] coio V> done loading vylog 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovery start 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> recovering from `/var/lib/tarantool/cache_slave2/00000000000000000014.snap' 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(47) = 0x7f99a4000080 2019-02-19 17:13:45.114 [20751] main/101/slave2 I> cluster uuid 4035b563-67f8-4e85-95cc-e03429f1fa4d 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(11) = 0x7f99a4004080 2019-02-19 17:13:45.114 [20751] main/101/slave2 D> memtx_tuple_new(17) = 0x7f99a4008068
وكانت المحاولة ناجحة:
2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a40004c0 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 1 to replica 825af7c3-f8df-4db0-8559-a866b8310077 2019-02-19 17:13:45.118 [20751] main/101/slave2 D> memtx_tuple_new(40) = 0x7f99a4000500 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> assigned id 2 to replica 403c0323-5a9b-480d-9e71-5ba22d4ccf1b 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> recover from `/var/lib/tarantool/slave2/00000000000000000014.xlog' 2019-02-19 17:13:45.118 [20751] main/101/slave2 I> done `/var/lib/tarantool/slave2/00000000000000000014.xlog'
حتى بدأت:
2019-02-19 17:13:45.119 [20751] main/101/slave2 D> systemd: sending message 'STATUS=running'
ولكن لأسباب غير معروفة ، فقد الاتصال وسقط:
2019-02-19 17:13:45.129 [20751] main/101/slave2 D> SystemError at /build/tarantool-1.10.2.146/src/coio_task.c:416 2019-02-19 17:13:45.129 [20751] main/101/slave2 tarantoolctl:532 E> Start failed: /usr/local/share/lua/5.1/http/server.lua:1146: Can't create tcp_server: Input/output error
محاولة لبدء الرقيق مرة أخرى لا يساعد.
الآن احذف الملفات التي أنشأتها المثيلات. في حالتي ، أحذف كل شيء من دليل / var / lib / tarantool.
أبدأ العبد أولاً ، وعندها فقط أتقن. وها هوذا ...
لم أجد أي تفسير لهذا السلوك ، باستثناء "كميزة من ميزات هذا البرنامج".
سيظهر هذا الموقف في كل مرة إذا تمت إعادة تشغيل الخادم بالكامل.
بناءً على مزيد من التحليل لبنية هذا البرنامج ، اتضح أنه من المخطط استخدام وحدة واحدة فقط من وحدة المعالجة المركزية (CPU) واحدة لمثيل واحد وأن موارد أخرى كثيرة تظل مجانية.
في أيديولوجية n vCPU ، يمكننا رفع السيد والعبد n-2 للقراءة.
بالنظر إلى أنه على خادم الاختبار 8 vCPU يمكننا رفع مستوى الماجستير و 6 حالات للقراءة.
أنا أنسخ الملف الخاص بالرقيق ، وقم بتصحيح المنافذ والتشغيل ، أي يتم إضافة عدد قليل من العبيد.
مهم! عند إضافة مثيل آخر ، يجب عليك تسجيله على المعالج.
ولكن يجب عليك أولاً أن تبدأ عبداً جديداً ، وبعد ذلك فقط تعيد تشغيل السيد.
مثال
كان لدي بالفعل تكوين يعمل مع معالج واثنين من العبيد.
قررت أن أضيف عبدا ثالثا.
قمت بتسجيله على السيد وأعدت تشغيله أولاً ، وهذا ما رأيته:
أي أصبح سيدنا وحيدًا ، وانهار التكرار.
إن البدء بعبد جديد لن يساعدك وسيؤدي إلى حدوث خطأ:
وفي السجلات رأيت إدخالاً مفيداً قليلاً:
2019-02-20 09:20:10.616 [21601] main/101/slave4 I> bootstrapping replica from 3c77eb9d-2fa1-4a27-885f-e72defa5cd96 at 10.78.221.74:3301 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t I> can't join/subscribe 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/106/applier/replicator@tarantuldb-t D> => STOPPED 2019-02-20 09:20:10.617 [21601] main/101/slave4 xrow.c:896 E> ER_READONLY: Can't modify data because this instance is in read-only mode. 2019-02-20 09:20:10.617 [21601] main/101/slave4 F> can't initialize storage: Can't modify data because this instance is in read-only mode.
نوقف المعالج ونبدأ عبدا جديدا. سيكون هناك خطأ أيضًا ، كما في البداية الأولى ، لكننا سنرى أنه يتم تحميل حالة.
ولكن عندما تبدأ سيدًا ، يتعطل العبد الجديد ، ولا يتطابق السيد مع حالة التشغيل.
في هذه الحالة ، لا يوجد سوى مخرج واحد. كما كتبت سابقًا ، أحذف الملفات التي أنشأتها المثيلات وأدير العبيد أولاً ، ثم أتقنها.
كل شيء بدأ بنجاح.
هكذا ، من خلال التجربة والخطأ ، اكتشفت كيفية تكوين النسخ المتماثل وبدءه بشكل صحيح.
نتيجة لذلك ، تم تجميع التكوين التالي:
2 خوادم.
2 سيد. احتياطي ساخن.
12 عبيدا. كلها نشطة.في منطق tarantool ، تم استخدام http.server
حتى لا يتم
حظر المحول الإضافي (تذكر البائع ، والنظام الأساسي ، والصابون) أو ربط المكتبة بكل عملية تجارية.
لتجنب التناقض بين الأساتذة أو على الموازن (NetScaler أو HAProxy أو أي مفضل آخر) ، فإننا نضع قاعدة الحجز ، أي إدراج وتحديث وحذف عمليات الانتقال فقط إلى سيد النشط الأول.
في هذا الوقت ، يقوم الثاني ببساطة بتكرار السجلات من الأول. العبيد أنفسهم مرتبطون بالسيد الأول المحدد من التكوين ، وهو ما نحتاجه في هذا الموقف.
في لوا ، نفذت عمليات CRUD لقيمة المفتاح. في الوقت الحالي ، هذا يكفي لحل المشكلة.
في ضوء ميزات العمل باستخدام الصابون ، تم تنفيذ عملية أعمال الوكيل ، حيث تم وضع منطق العمل مع الرتيلاء عبر http.
إذا كانت البيانات الرئيسية موجودة ، فسيتم إرجاعها على الفور. إذا لم يكن كذلك ، فسيتم إرسال طلب إلى النظام الرئيسي وتخزينه في قاعدة بيانات Tarantool.
نتيجة لذلك ، تقوم إحدى العمليات التجارية في الاختبارات بمعالجة ما يصل إلى 4 آلاف طلب. في هذه الحالة ، يكون زمن الاستجابة من الرتيلاء حوالي 1 مللي ثانية. متوسط زمن الاستجابة يصل إلى 3 مللي ثانية.
فيما يلي بعض المعلومات من الاختبارات:
كانت هناك 50 عملية تجارية تنتقل إلى 4 أنظمة رئيسية وبيانات ذاكرة التخزين المؤقت في ذاكرتهم. ازدواجية المعلومات في النمو الكامل في كل حالة. بالنظر إلى أن جافا تحب بالفعل الذاكرة ... فإن الاحتمال ليس هو الأفضل.
الان
50 عملية تجارية تطلب معلومات من خلال ذاكرة التخزين المؤقت. الآن يتم تخزين المعلومات من 4 مثيلات من المعالج في مكان واحد ، ولا يتم تخزينها في ذاكرة التخزين المؤقت في كل حالة. كان من الممكن تقليل العبء على النظام الرئيسي بشكل كبير ، لا توجد نسخ مكررة من المعلومات وانخفض استهلاك الذاكرة في الحالات التي يكون فيها منطق العمل.
مثال على حجم تخزين المعلومات في ذاكرة الرتيلاء:
في نهاية اليوم ، قد تتضاعف هذه الأرقام ، ولكن لا يوجد "سحب" في الأداء.
في المعركة ، ينشئ الإصدار الحالي طلبات من 2 كيلو - 2.5 كيلو في الثانية من الحمل الحقيقي. يشبه متوسط زمن الاستجابة الاختبارات التي تصل إلى 3 مللي ثانية.
إذا نظرت إلى htop على أحد الخوادم باستخدام tarantool ، فسوف نرى أنها "تبريد":
ملخص
على الرغم من كل التفاصيل الدقيقة والفروق الدقيقة في قاعدة بيانات Tarantool ، يمكنك تحقيق أداء رائع.
آمل أن يتطور هذا المشروع وسيتم حل هذه اللحظات غير المريحة.