👰🏻 🤯 🐼 हमने टारेंटूल डेटाबेस पर कैश कैसे लागू किया 🥩 👩‍🚒 👅

आपका दिन शुभ हो!

मैं आपके साथ टारेंटूल डेटाबेस पर कैश के कार्यान्वयन और मेरे काम की विशेषताओं के बारे में एक कहानी साझा करना चाहता हूं।
मैं एक दूरसंचार कंपनी में जावा डेवलपर के रूप में काम करता हूं। मुख्य कार्य: उस प्लेटफॉर्म के लिए व्यावसायिक तर्क का कार्यान्वयन जो कंपनी ने विक्रेता से खरीदा था। पहली विशेषताओं में से, यह साबुन का काम है और जेवीएम मेमोरी को छोड़कर, कैशिंग की लगभग पूर्ण अनुपस्थिति है। यह सब तब तक अच्छा है जब तक कि आवेदन की संख्या दो दर्जन से अधिक न हो जाए ...

काम के दौरान और मंच की विशेषताओं की समझ के साथ, कैशिंग करने का प्रयास किया गया था। उस समय, MongoDB पहले से ही लॉन्च किया गया था, और परिणामस्वरूप, हमें परीक्षण में कोई विशेष सकारात्मक परिणाम नहीं मिला।

मेरे अच्छे दोस्त mr_elzor से विकल्प और सलाह के लिए आगे की खोज में, टारेंटूल डेटाबेस की कोशिश करने का निर्णय लिया गया।

एक सरसरी अध्ययन में, लू में केवल संदेह प्रकट हुआ, क्योंकि मैंने उस पर "पूरी तरह से" शब्द नहीं लिखा था। लेकिन सभी संदेहों को एक तरफ धकेलते हुए, उन्होंने स्थापित करने के बारे में सोचा। बंद नेटवर्क और फ़ायरवॉल के बारे में, मुझे लगता है कि कुछ लोग रुचि रखते हैं, लेकिन मैं आपको सलाह देता हूं कि आप उनके आसपास जाने और सार्वजनिक स्रोतों से सब कुछ डालने की कोशिश करें।

विन्यास के साथ टेस्ट सर्वर: 8 सीपीयू, 16 जीबी राम, 100 जीबी एचडीडी, डेबियन 9.4।

स्थापना साइट से निर्देशों के अनुसार थी। और इसलिए मुझे एक उदाहरण विकल्प मिला। यह विचार तुरंत एक विज़ुअल इंटरफ़ेस के साथ दिखाई दिया, जिसके सहारे सुविधा काम करेगी। एक त्वरित खोज के दौरान, मैंने टैरनटूल-एडमिन को ढूंढा और कॉन्फ़िगर किया। डॉकर में काम करता है और कम से कम अभी के लिए 100% समर्थन कार्यों को शामिल करता है।

लेकिन चलो अधिक दिलचस्प बात करते हैं।

अगला विचार मास्टर में मेरे संस्करण को कॉन्फ़िगर करना था - एक ही सर्वर के भीतर दास कॉन्फ़िगरेशन, क्योंकि प्रलेखन में केवल दो अलग-अलग सर्वरों के साथ उदाहरण हैं।

कुछ समय लुआ को समझने और कॉन्फ़िगरेशन का वर्णन करने के बाद, मैं विज़ार्ड लॉन्च करता हूं।

# systemctl start tarantool@master Job for tarantool@master.service failed because the control process exited with error code. See "systemctl status tarantool@master.service" and "journalctl -xe" for details.

मैं तुरंत एक मूर्खता में पड़ जाता हूं और यह नहीं समझता कि त्रुटि क्यों है, लेकिन मैं देखता हूं कि यह "लोडिंग" स्थिति में है।

 # systemctl status tarantool@master ● tarantool@master.service - Tarantool Database Server Loaded: loaded (/lib/systemd/system/tarantool@.service; enabled; vendor preset: enabled) Active: activating (start) since Tue 2019-02-19 17:03:24 MSK; 17s ago Docs: man:tarantool(1) Process: 20111 ExecStop=/usr/bin/tarantoolctl stop master (code=exited, status=0/SUCCESS) Main PID: 20120 (tarantool) Status: "loading" Tasks: 5 (limit: 4915) CGroup: /system.slice/system-tarantool.slice/tarantool@master.service └─20120 tarantool master.lua <loading> Feb 19 17:03:24 tarantuldb-tst4 systemd[1]: Starting Tarantool Database Server... Feb 19 17:03:24 tarantuldb-tst4 tarantoolctl[20120]: Starting instance master... Feb 19 17:03:24 tarantuldb-tst4 tarantoolctl[20120]: Run console at unix/:/var/run/tarantool/master.control Feb 19 17:03:24 tarantuldb-tst4 tarantoolctl[20120]: started

मैं गुलाम चलाता हूं:

 # systemctl start tarantool@slave2 Job for tarantool@slave2.service failed because the control process exited with error code. See "systemctl status tarantool@slave2.service" and "journalctl -xe" for details.

और मैं वही गलती देखता हूं। यहां, मैं आम तौर पर तनाव शुरू करता हूं और समझ नहीं पाता कि क्या हो रहा है, क्योंकि इसके बारे में प्रलेखन में कुछ भी नहीं है ... लेकिन स्थिति की जांच करते समय, मैं देखता हूं कि यह बिल्कुल भी शुरू नहीं हुआ था, हालांकि यह कहता है कि स्थिति "चल रही है":

 # systemctl status tarantool@slave2 ● tarantool@slave2.service - Tarantool Database Server Loaded: loaded (/lib/systemd/system/tarantool@.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-02-19 17:04:52 MSK; 27s ago Docs: man:tarantool(1) Process: 20258 ExecStop=/usr/bin/tarantoolctl stop slave2 (code=exited, status=0/SUCCESS) Process: 20247 ExecStart=/usr/bin/tarantoolctl start slave2 (code=exited, status=1/FAILURE) Main PID: 20247 (code=exited, status=1/FAILURE) Status: "running" Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Unit entered failed state. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Failed with result 'exit-code'. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Service hold-off time over, scheduling restart. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: Stopped Tarantool Database Server. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Start request repeated too quickly. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: Failed to start Tarantool Database Server. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Unit entered failed state. Feb 19 17:04:52 tarantuldb-tst4 systemd[1]: tarantool@slave2.service: Failed with result 'exit-code'.

लेकिन एक ही समय में, मास्टर ने काम करना शुरू कर दिया:

 # ps -ef | grep taran taranto+ 20158 1 0 17:04 ? 00:00:00 tarantool master.lua <running> root 20268 2921 0 17:06 pts/1 00:00:00 grep taran

गुलाम को बहाल करने से कोई फायदा नहीं होता। मुझे आश्चर्य है कि क्यों?

मैं गुरु को रोकता हूं। और क्रियाओं को उल्टे क्रम में करें।

मैं देखता हूं कि गुलाम शुरू करने की कोशिश कर रहा है।

 # ps -ef | grep taran taranto+ 20399 1 0 17:09 ? 00:00:00 tarantool slave2.lua <loading>

मैं विज़ार्ड शुरू करता हूं और देखता हूं कि यह बढ़ नहीं गया है और आम तौर पर अनाथ स्थिति में बदल गया है, जबकि दास आम तौर पर गिर गया।

 # ps -ef | grep taran taranto+ 20428 1 0 17:09 ? 00:00:00 tarantool master.lua <orphan>

यह और भी दिलचस्प हो जाता है।

मैं दास पर लॉग में देखता हूं कि उसने मास्टर को भी देखा और सिंक्रनाइज़ करने की कोशिश की।

 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 निर्देशिका से सब कुछ हटा देता हूं।

मैं पहले गुलाम होना शुरू करता हूं, और उसके बाद ही मास्टर। और लो और निहारना ...

 # ps -ef | grep tara taranto+ 20922 1 0 17:20 ? 00:00:00 tarantool slave2.lua <running> taranto+ 20933 1 1 17:21 ? 00:00:00 tarantool master.lua <running>

मुझे इस व्यवहार के लिए कोई स्पष्टीकरण नहीं मिला, सिवाय "इस सॉफ्टवेयर की विशेषता के।"
यह स्थिति हर बार दिखाई देगी यदि आपका सर्वर पूरी तरह से रिबूट हो गया है।

इस सॉफ्टवेयर की वास्तुकला के आगे के विश्लेषण पर, यह पता चला है कि यह एक उदाहरण के लिए केवल एक वीसीपीयू का उपयोग करने की योजना है और कई और संसाधन मुफ्त में उपलब्ध हैं।

N vCPU की विचारधारा में, हम पढ़ने के लिए मास्टर और n-2 दास उठा सकते हैं।

यह देखते हुए कि परीक्षण सर्वर 8 vCPU पर हम मास्टर और पढ़ने के लिए 6 उदाहरण उठा सकते हैं।
मैं दास के लिए फ़ाइल की प्रतिलिपि बनाता हूं, बंदरगाहों को सही करता हूं और चलाता हूं, अर्थात। कुछ और दास जोड़े जाते हैं।

महत्वपूर्ण! एक और उदाहरण जोड़ते समय, आपको इसे विज़ार्ड पर पंजीकृत करना होगा।
लेकिन आपको पहले एक नया दास शुरू करना होगा, और उसके बाद ही मास्टर को पुनरारंभ करें।

उदाहरण

मेरे पास पहले से ही एक विज़ार्ड और दो दासों के साथ एक कॉन्फ़िगरेशन चल रहा था।

मैंने तीसरा दास जोड़ने का फैसला किया।

मैंने इसे मास्टर पर पंजीकृत किया और पहले मास्टर को फिर से शुरू किया, और यही मैंने देखा:

 # ps -ef | grep tara taranto+ 20922 1 0 Feb19 ? 00:00:29 tarantool slave2.lua <running> taranto+ 20965 1 0 Feb19 ? 00:00:29 tarantool slave3.lua <running> taranto+ 21519 1 0 09:16 ? 00:00:00 tarantool master.lua <orphan>

यानी हमारा स्वामी कुंवारा हो गया, और प्रतिकृति टूट गई।

नया दास शुरू करने से अब मदद नहीं मिलेगी और परिणाम में त्रुटि होगी:

 # systemctl restart tarantool@slave4 Job for tarantool@slave4.service failed because the control process exited with error code. See "systemctl status tarantool@slave4.service" and "journalctl -xe" for details.

और लॉग में मैंने थोड़ी जानकारीपूर्ण प्रविष्टि देखी:

 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.

हम विज़ार्ड को रोकते हैं और एक नया दास शुरू करते हैं। पहली शुरुआत में भी एक त्रुटि होगी, लेकिन हम देखेंगे कि यह लोडिंग स्थिति है।

 # ps -ef | grep tara taranto+ 20922 1 0 Feb19 ? 00:00:29 tarantool slave2.lua <running> taranto+ 20965 1 0 Feb19 ? 00:00:30 tarantool slave3.lua <running> taranto+ 21659 1 0 09:23 ? 00:00:00 tarantool slave4.lua <loading>

लेकिन जब आप मास्टर शुरू करते हैं, तो नया दास क्रैश हो जाता है, और मास्टर रनिंग स्टेटस के साथ नहीं जाता है।

 # ps -ef | grep tara taranto+ 20922 1 0 Feb19 ? 00:00:29 tarantool slave2.lua <running> taranto+ 20965 1 0 Feb19 ? 00:00:30 tarantool slave3.lua <running> taranto+ 21670 1 0 09:23 ? 00:00:00 tarantool master.lua <orphan>

इस स्थिति में, केवल एक ही रास्ता है। जैसा कि मैंने पहले लिखा था, मैं उदाहरणों द्वारा बनाई गई फ़ाइलों को हटाता हूं और पहले दासों को चलाता हूं, और फिर मास्टर।

 # ps -ef | grep tarantool taranto+ 21892 1 0 09:30 ? 00:00:00 tarantool slave4.lua <running> taranto+ 21907 1 0 09:30 ? 00:00:00 tarantool slave3.lua <running> taranto+ 21922 1 0 09:30 ? 00:00:00 tarantool slave2.lua <running> taranto+ 21931 1 0 09:30 ? 00:00:00 tarantool master.lua <running>

सब कुछ सफलतापूर्वक शुरू हुआ।

यह है कि, परीक्षण और त्रुटि के माध्यम से, मुझे पता चला कि कैसे कॉन्फ़िगर करें और प्रतिकृति को सही ढंग से शुरू करें।

परिणामस्वरूप, निम्न कॉन्फ़िगरेशन को इकट्ठा किया गया था:

2 सर्वर।
२ गुरु। हॉट रिजर्व।
12 दास। सभी सक्रिय हैं।

टारेंटूल के तर्क में, http.server का उपयोग किया गया ताकि अतिरिक्त एडॉप्टर को ब्लॉक न करें (विक्रेता, प्लेटफ़ॉर्म और साबुन याद रखें) या प्रत्येक व्यावसायिक प्रक्रिया के लिए लाइब्रेरी को फास्ट करें।

मास्टर्स के बीच विसंगति से बचने के लिए, बैलेंसर (नेटस्क्लेर, हैप्रॉक्सी या किसी अन्य अपने पसंदीदा) पर, हम रिजर्व नियम, अर्थात् सेट करते हैं। सम्मिलित करें, अपडेट करें, हटाएं संचालन केवल पहले सक्रिय मास्टर पर जाएं।

इस समय, दूसरा केवल पहले से रिकॉर्ड दोहराता है। दास स्वयं कॉन्फ़िगरेशन से पहले निर्दिष्ट मास्टर से जुड़े होते हैं, जो हमें इस स्थिति में चाहिए।

लुआ पर, कुंजी-मूल्य के लिए CRUD संचालन लागू किया। फिलहाल, यह समस्या को हल करने के लिए पर्याप्त है।

साबुन के साथ काम करने की विशेषताओं को देखते हुए, एक प्रॉक्सी व्यवसाय प्रक्रिया को लागू किया गया था, जिसमें http के माध्यम से टारेंटयुला के साथ काम करने का तर्क रखा गया था।

यदि मुख्य डेटा मौजूद है, तो इसे तुरंत लौटा दिया जाता है। यदि नहीं, तो एक अनुरोध मास्टर सिस्टम को भेजा जाता है, और टारेंटूल डेटाबेस में संग्रहीत किया जाता है।

नतीजतन, परीक्षणों में एक व्यावसायिक प्रक्रिया 4k अनुरोधों तक प्रक्रिया करती है। इस मामले में, टारेंटयुला से प्रतिक्रिया समय ~ 1ms है। औसत प्रतिक्रिया समय 3ms तक है।

यहाँ परीक्षणों से कुछ जानकारी है:

50 व्यावसायिक प्रक्रियाएं थीं जो उनकी स्मृति में 4 मास्टर सिस्टम और कैश डेटा पर जाती हैं। प्रत्येक उदाहरण में पूर्ण वृद्धि में सूचना का दोहराव। यह देखते हुए कि जावा पहले से ही स्मृति से प्यार करता है ... संभावना सबसे अच्छी नहीं है।

अभी

50 व्यावसायिक प्रक्रियाएं कैश के माध्यम से जानकारी का अनुरोध करती हैं। अब विज़ार्ड के 4 उदाहरणों की जानकारी एक स्थान पर संग्रहीत की जाती है, और प्रत्येक उदाहरण में मेमोरी में कैश नहीं किया जाता है। मास्टर सिस्टम पर लोड को काफी कम करना संभव था, जानकारी की कोई डुप्लिकेट नहीं हैं, और व्यावसायिक तर्क के साथ उदाहरणों पर मेमोरी की खपत कम हो गई है।

टारेंटयुला मेमोरी में सूचना भंडारण के आकार का एक उदाहरण:

दिन के अंत में, ये संख्या दोगुनी हो सकती है, लेकिन प्रदर्शन में कोई "कमी" नहीं है।

लड़ाई में, वर्तमान संस्करण वास्तविक लोड के प्रति 2k - 2.5k अनुरोध बनाता है। औसत प्रतिक्रिया समय 3ms तक के परीक्षण के समान है।

यदि आप टारेंटूल वाले सर्वरों में से किसी एक को देखते हैं, तो हम देखेंगे कि वे "कूलिंग" हैं।

परिणाम

टारनटूल डेटाबेस की सभी सूक्ष्मताओं और बारीकियों के बावजूद, आप शानदार प्रदर्शन प्राप्त कर सकते हैं।

मुझे उम्मीद है कि यह परियोजना विकसित होगी और इन असहज क्षणों को हल किया जाएगा।

हमने टारेंटूल डेटाबेस पर कैश कैसे लागू किया

उदाहरण

अभी

परिणाम

More articles: