तेर्सो memcached मापन गर्न mcrouter प्रयोग गर्दै

कुनै पनि भाषामा उच्च-लोड परियोजनाहरू विकास गर्न विशेष दृष्टिकोण र विशेष उपकरणहरूको प्रयोग चाहिन्छ, तर जब यो PHP मा अनुप्रयोगहरू आउँछ, स्थिति यति बिग्रन सक्छ कि तपाईंले विकास गर्नुपर्छ, उदाहरणका लागि, आफ्नै आवेदन सर्भर। यस नोटमा हामी मेमक्याचमा वितरित सत्र भण्डारण र डाटा क्यासिङसँग परिचित पीडा र हामीले एउटा "वार्ड" परियोजनामा ​​कसरी यी समस्याहरू समाधान गर्यौं भन्ने बारेमा कुरा गर्नेछौं।

अवसरको नायक सिम्फनी 2.3 फ्रेमवर्कमा आधारित PHP अनुप्रयोग हो, जुन अद्यावधिक गर्ने व्यापार योजनाहरूमा समावेश छैन। धेरै मानक सत्र भण्डारण को अतिरिक्त, यो परियोजना को पूरा उपयोग गर्यो "सबै कुरा क्यास" नीति memcached मा: डाटाबेस र API सर्भरहरूमा अनुरोधहरूको प्रतिक्रियाहरू, विभिन्न झण्डाहरू, कोड कार्यान्वयन सिङ्क्रोनाइज गर्नका लागि लकहरू र अधिक। यस्तो अवस्थामा, memcached को एक ब्रेकडाउन अनुप्रयोगको सञ्चालनको लागि घातक हुन्छ। थप रूपमा, क्यास हानिले गम्भीर परिणामहरू निम्त्याउँछ: DBMS सिमहरूमा फुट्न थाल्छ, API सेवाहरूले अनुरोधहरू प्रतिबन्ध गर्न थाल्छ, आदि। स्थिति स्थिर गर्न दसौं मिनेट लाग्न सक्छ, र यस समयमा सेवा भयानक ढिलो वा पूर्ण रूपमा अनुपलब्ध हुनेछ।

हामीले उपलब्ध गराउनु पर्यो थोरै प्रयासको साथ एप्लिकेसनलाई तेर्सो मापन गर्ने क्षमता, अर्थात् स्रोत कोडमा न्यूनतम परिवर्तनहरू र पूर्ण कार्यक्षमता सुरक्षित। क्यासलाई विफलताको प्रतिरोधी मात्र बनाउनुहोस्, तर यसबाट डेटा हानि कम गर्ने प्रयास गर्नुहोस्।

memcached आफैमा के गलत छ?

सामान्यतया, PHP को लागि memcached विस्तारले बाकस बाहिर वितरित डाटा र सत्र भण्डारण समर्थन गर्दछ। सुसंगत कुञ्जी ह्यासिङको लागि संयन्त्रले तपाईंलाई धेरै सर्भरहरूमा समान रूपमा डेटा राख्न अनुमति दिन्छ, समूहबाट विशिष्ट सर्भरमा प्रत्येक विशिष्ट कुञ्जीलाई विशिष्ट रूपमा सम्बोधन गर्दै, र बिल्ट-इन फेलओभर उपकरणहरूले क्यासिङ सेवाको उच्च उपलब्धता सुनिश्चित गर्दछ (तर, दुर्भाग्यवश, डाटा छैन).

सत्र भण्डारणको साथ चीजहरू थोरै राम्रो छन्: तपाइँ कन्फिगर गर्न सक्नुहुन्छ memcached.sess_number_of_replicas, जसको फलस्वरूप डाटा एकै पटक धेरै सर्भरहरूमा भण्डारण गरिनेछ, र एउटा मेमक्याच गरिएको उदाहरणको विफलताको अवस्थामा, डाटा अरूबाट स्थानान्तरण हुनेछ। यद्यपि, यदि सर्भर डाटा बिना नै अनलाइन फर्कन्छ (जस्तै पुन: सुरु भएपछि हुन्छ), केही कुञ्जीहरू यसको पक्षमा पुन: वितरण गरिनेछ। वास्तवमा यो मतलब हुनेछ सत्र डाटा को हानिछुटेको अवस्थामा अर्को प्रतिकृतिमा "जानुहोस्" को कुनै तरिका छैन।

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

आदर्श रूपमा यो आवश्यक थियो memcached र बाइपास प्रतिकृतिहरूमा रेकर्डहरूको प्रतिकृति गल्ती वा गल्ती को मामला मा। हामीलाई यो रणनीति लागू गर्न मद्दत गर्यो mcrouter.

mcrouter

यो फेसबुक द्वारा यसको समस्या समाधान गर्न को लागी विकसित एक memcached राउटर हो। यसले memcached पाठ प्रोटोकल समर्थन गर्दछ, जसले अनुमति दिन्छ स्केल memcached स्थापनाहरू पागल अनुपातमा। mcrouter को विस्तृत विवरण मा पाउन सकिन्छ यो घोषणा। अन्य चीजहरू बीच व्यापक कार्यक्षमता यसले हामीलाई चाहिने कुरा गर्न सक्छ:

• प्रतिलिपि रेकर्ड;
• यदि त्रुटि भयो भने समूहमा अन्य सर्भरहरूमा फलब्याक गर्नुहोस्।

काममा लाग्नुहोस्!

mcrouter कन्फिगरेसन

म सिधै कन्फिगरेसनमा जान्छु:

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

किन तीन पोखरी? सर्भरहरू किन दोहोर्याइन्छ? यसले कसरी काम गर्छ भनेर पत्ता लगाउनुहोस्।

• यस कन्फिगरेसनमा, mcrouter ले अनुरोध आदेशको आधारमा अनुरोध पठाइने मार्ग चयन गर्दछ। केटाले उसलाई यो भन्छ OperationSelectorRoute.
• GET अनुरोधहरू ह्यान्डलरमा जान्छन् RandomRouteजो अनियमित रूपमा एरे वस्तुहरू बीच पूल वा मार्ग चयन गर्दछ children। यस एरेको प्रत्येक तत्व एक ह्यान्डलर हो MissFailoverRoute, जुन पोखरीमा प्रत्येक सर्भर मार्फत जान्छ जबसम्म यसले डेटाको साथ प्रतिक्रिया प्राप्त गर्दैन, जुन ग्राहकलाई फिर्ता गरिनेछ।
• यदि हामीले विशेष रूपमा प्रयोग गर्यौं भने MissFailoverRoute तीन सर्भरहरूको पूलको साथ, त्यसपछि सबै अनुरोधहरू पहिलो मेमक्याच गरिएको उदाहरणमा आउँछन्, र बाँकीले डेटा नभएको अवस्थामा अवशिष्ट आधारमा अनुरोधहरू प्राप्त गर्नेछन्। यस्तो दृष्टिकोणले नेतृत्व गर्नेछ सूचीमा पहिलो सर्भरमा अत्यधिक लोड, त्यसैले यो विभिन्न अनुक्रम मा ठेगाना संग तीन पूल उत्पन्न गर्न र अनियमित चयन गर्ने निर्णय गरियो।
• अन्य सबै अनुरोधहरू (र यो रेकर्ड हो) प्रयोग गरी प्रशोधन गरिन्छ AllMajorityRoute। यो ह्यान्डलरले पूलमा भएका सबै सर्भरहरूलाई अनुरोधहरू पठाउँछ र तिनीहरूमध्ये कम्तिमा N/2 + 1 बाट प्रतिक्रियाहरूको लागि पर्खन्छ। प्रयोगबाट AllSyncRoute यस विधिबाट सकारात्मक प्रतिक्रिया चाहिने हुनाले लेखन कार्यहरू त्याग्नुपर्ने थियो всех समूहमा सर्भरहरू - अन्यथा यो फिर्ता हुनेछ SERVER_ERROR। यद्यपि mcrouter ले डाटा उपलब्ध क्यासहरूमा थप्नेछ, कलिङ PHP प्रकार्य त्रुटि फिर्ता गर्नेछ र सूचना उत्पन्न गर्नेछ। AllMajorityRoute यति कडा छैन र माथि वर्णन गरिएका समस्याहरू बिना नै आधा एकाइहरूलाई सेवाबाट बाहिर निकाल्न अनुमति दिन्छ।

मुख्य हानि यो योजना यो हो कि यदि त्यहाँ क्यासमा साँच्चै कुनै डाटा छैन भने, ग्राहक N बाट प्रत्येक अनुरोधको लागि memcached लाई वास्तवमा कार्यान्वयन गरिनेछ - को सबैलाई पोखरीमा सर्भरहरू। हामी पूलहरूमा सर्भरहरूको संख्या घटाउन सक्छौं, उदाहरणका लागि, दुईमा: भण्डारण विश्वसनीयताको बलिदान, हामी पाउँछौंоअनुरोधबाट हराइरहेको कुञ्जीहरूमा उच्च गति र कम लोड।

NB: तपाईले mcrouter सिक्नको लागि उपयोगी लिङ्कहरू पनि फेला पार्न सक्नुहुन्छ विकिमा कागजात и परियोजना मुद्दाहरू (बन्द भएकाहरू सहित), विभिन्न कन्फिगरेसनहरूको सम्पूर्ण भण्डारको प्रतिनिधित्व गर्दै।

निर्माण र चलिरहेको mcrouter

हाम्रो एप्लिकेसन (र memcached आफैं) Kubernetes मा चल्छ - तदनुसार, mcrouter पनि त्यहाँ अवस्थित छ। को लागी कन्टेनर विधानसभा हामी प्रयोग गर्छौ वाफ, जसको लागि कन्फिगरेसन यस्तो देखिन्छ:

NB: लेखमा दिइएका सूचीहरू भण्डारमा प्रकाशित छन् flant/mcrouter.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

... र यसलाई बाहिर स्केच गर्नुहोस् हेलम चार्ट। चाखलाग्दो कुरा यो हो कि त्यहाँ प्रतिकृतिहरूको संख्यामा आधारित कन्फिगरेसन जनरेटर मात्र छ (यदि कसैसँग अधिक संक्षिप्त र सुरुचिपूर्ण विकल्प छ भने, टिप्पणीहरूमा साझा गर्नुहोस्):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|pool%02d" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
   {
     "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
     "route": {
       "type": "OperationSelectorRoute",
       "default_policy": "AllMajorityRoute|Pool|pool00",
       "operation_policies": {
         "get": {
           "type": "RandomRoute",
           "children": {{- keys $pools | toJson }}
         }
       }
     }
   }

(10-mcrouter.yaml)

हामी यसलाई परीक्षण वातावरणमा रोल आउट गर्छौं र जाँच गर्छौं:

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

त्रुटिको पाठ खोजी गर्दा कुनै नतिजा आएन, तर क्वेरीको लागि "माइक्रोउटर php"अग्रणीमा परियोजनाको सबैभन्दा पुरानो समाधान नभएको समस्या थियो - समर्थनको अभाव memcached बाइनरी प्रोटोकल।

NB: memcached मा ASCII प्रोटोकल बाइनरी एक भन्दा ढिलो छ, र लगातार कुञ्जी ह्यासिङ को मानक माध्यम बाइनरी प्रोटोकल संग मात्र काम गर्दछ। तर यसले कुनै विशेष केसको लागि समस्या सिर्जना गर्दैन।

चाल झोलामा छ: तपाईले गर्नु पर्ने भनेको ASCII प्रोटोकलमा स्विच गर्नु हो र सबै कुराले काम गर्नेछ। तर, यस अवस्थामा, जवाफ खोज्ने बानी php.net मा दस्तावेज एक क्रूर मजाक खेले। तपाईंले त्यहाँ सहि उत्तर फेला पार्नुहुनेछैन... जबसम्म, तपाईंले अन्त्यमा स्क्रोल गर्नुभयो, जहाँ खण्डमा "प्रयोगकर्ताको योगदान नोटहरू" विश्वासी हुनेछन् र अनुचित रूपमा अस्वीकार गरिएको जवाफ.

हो, सही विकल्प नाम हो memcached.sess_binary_protocol। यो असक्षम हुनुपर्छ, जस पछि सत्रहरूले काम गर्न सुरु गर्नेछ। अब बाँकी रहेको कन्टेनरलाई mcrouter को PHP को साथ पोडमा राख्नु हो!

निष्कर्षमा

यसैले, केवल पूर्वाधार परिवर्तनहरूको साथ हामीले समस्या समाधान गर्न सक्षम भयौं: मेमक्याच गरिएको दोष सहिष्णुताको साथ समस्या समाधान गरिएको छ, र क्यास भण्डारणको विश्वसनीयता बढाइएको छ। एप्लिकेसनका लागि स्पष्ट फाइदाहरूको अतिरिक्त, यसले प्लेटफर्ममा काम गर्दा पैंतरेखाको लागि ठाउँ दियो: जब सबै कम्पोनेन्टहरूसँग रिजर्भ हुन्छ, प्रशासकको जीवन धेरै सरलीकृत हुन्छ। हो, यो विधिमा पनि यसको कमजोरीहरू छन्, यो "बैसाखी" जस्तो लाग्न सक्छ, तर यदि यसले पैसा बचत गर्छ, समस्यालाई गाड्छ र नयाँ कारण बनाउँदैन - किन होइन?

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• "dapp संग अभ्यास" (उदाहरणको रूपमा symfony-डेमो प्रयोग गर्दै): भाग १ (साधारण अनुप्रयोगहरू निर्माण गर्ने) и भाग २ (हेल्म प्रयोग गरेर कुबेरनेटमा डकर छविहरू प्रयोग गर्दै);
• «Kubernetes को साथ जीवनबाट: HTTP सर्भरले स्पेनियार्डहरूलाई कसरी समर्थन गरेन"।

स्रोत: www.habr.com