Мобильді қосымшаларды әзірлеу: Сервермен синхрондау. Мобильді қосымшаларға арналған сервер бөлігін әзірлеу Мобильді қосымшаға арналған сервер

САҚТЫҚ КӨШІРМЕЛЕР

Неліктен сақтық көшірмелер мобильді платформада қажет

Сарапшылар кейде 1С мобильді қосымшаларының қаншалықты сенімсіз екенін біледі: қателер кез келген уақытта пайда болуы мүмкін, соның салдарынан пайдаланушы базасы жай құлайды. Бұл ретте біз құрылғылардың өздеріне сенімсіздігімен бетпе-бет келіп отырмыз: олар бұзылып, жоғалуы, ұрлануы мүмкін, ал пайдаланушылар өз деректерін сақтағысы келеді. Ал 8.3.9 нұсқасына дейін бізде платформаның сақтық көшірмесін жасау механизмі болмады.

Бұрын пайдаланушыларда «көшірмені сақтау» түймесі болмағандықтан, Boss қолданбасын әзірлеушілер сақтық көшірмелерді өздері жасауға мәжбүр болды. Біз мұны қалай жасадық?

Біз мәліметтер базасын XML форматында сақтаймыз.

Пайдаланушыға көшірмелерді сақтаудың бірнеше нұсқасын ұсынған жөн - бұл ең алдымен тұтынушыларға ыңғайлы, олар өздері үшін ең жақсы нұсқаны таңдай алады: бұлтқа жүктеп салу, оны поштасына жіберу, құрылғыда сақтау.

Осылайша, әзірлеушілер өздерін қосымша сақтандырады. Егер бірдеңе дұрыс болмаса және кенеттен Google Drive немесе Yandex Drive-та көшірме жасау механизмі бұзылса, пайдаланушыға әрқашан мынаны айта аласыз: осы сәтәзірлеуші ​​қатені шешеді, бірақ қазір ол деректерді сақтай алады балама жол. Ал пайдаланушылар қанағаттанады, өйткені олар өз деректеріне сабырлы бола алады.

Міндетті түрде назар аудару керек бұлттық қызметтер , себебі құрылғы жоғалса немесе сынса және пайдаланушы көшірмені бір құрылғыда сақтаса, деректер жоғалады.

Сондай-ақ біз пайдаланушыға сақтық көшірме жасау қажеттілігін еске салуды ұмытпаңыз.

Конфигурация өзгерсе, көшірмелерді қалай сақтауға болады?

Жаппай шешім туралы, үнемі өзгеріп отыратын, дамып, жетілдірілетін қолданба туралы айтқанда, тұтынушылардың мінез-құлқын ескеру керек. Пайдаланушы қолданбаның ескі нұсқасында сақталған сақтық көшірмені қалпына келтіргісі келуі мүмкін, мұнда мәліметтер жоқ. Содан кейін тапсырма туындайды: деректерді оқу, содан кейін қолданбаның ескі нұсқасынан жаңарту логикасына сәйкес деректерді толтыру. Бұны қалай істейді? Деректерге қосымша, кейінірек оларды қалай оқу керектігін білу үшін деректер құрылымының өзін сақтаңыз.

Бұл деректер құрылымын сақтаудың бірнеше нұсқалары бар, соның ішінде оны конфигурацияның өзінде сақтау. Яғни, әрбір жаңа нұсқаны шығарған кезде метадеректер құрылымын сақтаңыз алдыңғы нұсқасыконфигурацияда орналасу үшін.

Ұмытпаңыз, мобильді қосымшада конфигурация дәл осылай өспеуі керек, біз ондағы орынды бағалауымыз керек, біз оны мүмкіндігінше ықшамдауымыз керек. Бірақ қолданба дамып келеді және мұндай макеттер көп болады және уақыт өте келе олардың саны көбейеді.

Сондықтан, мобильді қосымшада басқа әдіс артықшылық береді - метадеректер құрылымын тікелей деректер файлында сақтаңыз. Шығаруда біз осындай файлды аламыз, онда бастапқыда кейбір көмекші деректерді - конфигурация нұсқасын, конфигурация схемасын, реттілік шекараларын сақтаймыз, содан кейін біз XML форматында пайдаланушы деректерін жазамыз. Сонымен қатар, файлдың «Көмекші деректер» бөлімінде сіз қандай да бір себептермен XML-ге жазу мүмкін болмаған басқа маңызды деректерді сақтай аласыз.

Біз файлға сақталған деректер схемасын аламыз және оның негізінде файлды оқу үшін XDTO бумасын құрастырамыз. Мәліметтер базасында ұқсас нысанды жасаймыз, оны толтырамыз, жаңарту кезінде өңдеуді аяқтаймыз және дайын объектіні мәліметтер базасына сақтаймыз.

Төменде суретте сіз осы конфигурациялардың XDTO үлгісін әдемі жазу туралы кеңесті көре аласыз. Boss қосымшасын шығарған компания мұны тәжірибеден өткізіп, бірнеше жолды тапты, бірақ метадеректер схемасын жазудың осы опциясына ғана тоқталды. Деректер файлының өзі ашылған кезде, қолданбаның барлық метадеректерін тізімдейтін кәдімгі құрылымдық XML көрінеді, оқуға болады.

// Конфигурация схемасын жазу XDTO үлгісі = XDTO зауыты.XDTO үлгісін экспорттау("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(FileUpload, ModelXDTO); // Конфигурация схемасын оқу ModelXDTO = FactoryXDTO.ReadXML(ReadingXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Модель")); Жүктеме зауыты = Жаңа XDTO зауыты (XDTO үлгісі);

Пайдаланушыны қорғау үшін оған сақтық көшірмені қалпына келтіру қажет пе, жоқ па деп қайта сұрау керек. Мүмкін ол жай ғана тәжірибе жасап, қолданбадағы барлық нәрсенің түймелерін басқан шығар :) Ал енді оның ағымдағы деректері жоғалып кетуі мүмкін. Сондықтан, ықтимал «қауіпті» әрекеттерді орындаған кезде, біз әрқашан оның мұны шынымен қалайтынын және бұл қалай болуы керек екенін түсіндіреміз. Пайдаланушы өз әрекеттерінен хабардар болуы керек.

Пайдаланушыда тек мобильді құрылғыда сақталған барлық деректер болған кезде, желіден тыс шешім туралы айтатын болсақ, сақтық көшірмелерді жасау механизмі болуы керек: пайдаланушы құрылғысын жоғалтуы мүмкін, содан кейін деректер жоғалады. Егер қолданба желіден тыс жұмыс істемесе, бірақ орталық серверге қосылған болса, пайдаланушыда мұндай мәселе болмауы керек сияқты, өйткені құрылғы жоғалса, ол серверге қосылып, оның барлық деректерін келесіден алады. сервер қайтадан, және бәрі жақсы болады.

Дегенмен, пайдаланушылар сақтық көшірмелерді әрқашан біз күткендей пайдалана бермейді :) Олар деректерді жай ғана кері қайтару үшін оларды жиі пайдаланады. Бұл шын мәнінде өте оғаш мінез-құлық, бірақ мобильді қолданба пайдаланушылары деректерді енгізу кезінде қай жерде қателесуі мүмкін екенін анықтауға тым жалқау және олар жай ғана деректерді кері айналдырып, ағымдағы күн үшін деректерді қайта бастайды. Boss қолданбасымен жұмыс істеу статистикасын талдағаннан кейін біз бұл қалыпты тәжірибе екенін және пайдаланушының мұндай әрекеті біз ойлағаннан да жиірек екенін түсіндік.

Егер сіз басқа құрылғылармен синхрондауды пайдалансаңыз, оны өңдеу керек. Мұнда бірнеше шешімдер бар:

• ондағы деректер бұрынғы күйінде қалатынын және көшірме тек пайдаланушының құрылғысында қалпына келтірілетінін көрсете отырып, сервермен байланысты үзу;
• пайдаланушыға алдын ала осындай механизмдерді тағайындай отырып, барлық құрылғылардағы көшірмені қалпына келтіруге мүмкіндік бергені дұрыс.

Бұл жерде тағы бір мәселе бар. Осы уақытқа дейін біз сақтық көшірмелерді өзіміз сақтадық, бүкіл процесті басқардық, «көшірмені сақтау» түймесін басқан кезде пайдаланушының әрекеттерін кодта ұстадық. Мұның бәрін кейінірек өңдеуге болады. 8.3.9 платформасында платформа құралдары арқылы сақтық көшірмелерді сақтау мүмкін болды. Ал пайдаланушы мұны біздің білместен жасайды. Егер орталық дерекқормен синхрондау пайдаланылса, онда мұндай сценарий өңделуі керек. Біз өз серверімізде пайдаланушының бұрын сақталған көшірмені қалпына келтіргенін және оған қандай да бір шешім қабылдауы керек екенін білуіміз керек. Деректердің синхрондалуына жол бере алмаймыз.

АЙЫРБАСТАУ

Мобильді платформадағы жеке шешім туралы айтатын болсақ, әдетте бізде, мысалы, пайдаланғысы келетін тұтынушы болады мобильді платформаолардың сату агенттері үшін және олар үшін орталық дерекқормен деректер алмасу. Мұнда бәрі қарапайым: бір дерекқор, бірнеше құрылғы, сіз серверді көтересіз, онымен байланысты орнатасыз. Осылайша, құрылғылар арасындағы алмасу мәселесі оңай шешіледі.

Бірақ егер біз жаппай қолдану туралы айтатын болсақ, онда көптеген деректер базасы бар, олардың әрқайсысында көптеген пайдаланушылар бар, жағдай күрделене түседі. Пайдаланушылар қолданбаны нарықтан жүктеп алды және олар бір-бірімен синхрондауды қалайды. Мысалы, күйеуі жеке қаржы қолданбасын жүктеп алды және енді бір қолданбада бірге жұмыс істеу үшін әйелінің де қосылуын қалайды. Көптеген пайдаланушылар бар, қолданба дамып келеді, өсуде және үлкен, өте көп мәліметтер базасы қажет. Мұның бәрін қалай ұйымдастыруға болады? Пайдаланушылар олар үшін бөлек дерекқор жасау және синхрондауды қосу үшін әзірлеушілермен жеке байланыспайды. Олар түймені басып, барлығын бірден іске қосқысы келеді. Дәл сол сәтте.

Не істеу керек? Бұл жерде деректерді бөлу механизмі көмекке келеді. Ол бір жалпы конфигурациясы бар бір дерекқорды ұйымдастыруға мүмкіндік береді, бірақ сонымен бірге бір ортақ дерекқорда пайдаланушы деректер қорының шектеусіз саны сақталады.

Ең жақсы бөлігі - пайдаланушыларды біздің қатысуымызсыз динамикалық, бағдарламалық түрде қосуға болады. Шындығында, пайдаланушылар «серверге тіркелу» түймесін басады және бәрі өздігінен жүреді: серверде ол үшін жеке деректер базасы жасалады және ол бірден жұмыс істей алады.

Бұны қалай істейді? Бірінші және ең қарапайым шешім - бұл механизммен өзіңіздің сервер деректеріңізді жазу. Біздің компания Boss қосымшасын жасап, онымен алмасуды бастағанда, біз бірінші нұсқада дәл солай жасадық: біз деректерді ортақ пайдалану механизмі бар серверлік дерекқорды жаздық. Барлығы жұмыс істеді, әсіресе күрделі ештеңе болмағандықтан - негізгі бөлгіш жалпы атрибут болып табылады.

Бірақ содан кейін біз дөңгелекті қайта ойлап тапқанымызды түсіндік :) Шындығында, дайын шешім бар және ол біз әлі ойланбаған сәттерді ескереді. Бұл 1С: Балғын.

Қызметтің ауқымдылығы осында ойластырылған: деректер мен дерекқорлар көп болған кезде не істеу керек, онымен қалай өсуге болады. Бұл жерде құру туралы бір сәт бар сақтық көшірмелердеректер аймақтары: яғни біз бір жалпы дерекқордың сақтық көшірмесін жасамаймыз, белгілі бір пайдаланушының көшірмелерін жасаймыз. Оның үстіне, көшірмелер шынымен қажет болғанда ғана жасалатындай механизм бар. Егер пайдаланушы бір апта бойы дерекқорға кірмеген болса, онда біз оған көшірме жасамаймыз, өйткені ол жерде ештеңе өзгерген жоқ. Fresh бағдарламасының тағы бір ерекшелігі - бұл қызметте серверге жүктемені азайту механизмі бар және бұл деректер базасы көп болған кезде өте маңызды.

Жалпы, Fresh біз үшін жаңа және қызықты нәрсе. Біз оны ақырындап анықтауға тырысамыз, бірақ біз оның жұмысына ризамыз.

Деректерді тасымалдау. Құрылғылар арасында бөлісу үшін оны қалай жүзеге асыруға болады

Платформа екі механизмді ұсынады - SOAP және http қызметтері. Мұнда деректерді ортақ пайдалану механизмі қосылған кезде осы қызметтерге қалай қол жеткізуге болатыны туралы нюанстар бар. Атап айтқанда, сіз қатынасатын аймақтың нақты санын көрсететін параметрлерді қосуыңыз керек, себебі платформа пайдаланушы атынан қай дерекқорға қол жеткізу керектігін анықтай алмайды. Сонымен қатар, бір пайдаланушы бір дерекқор ішінде бірнеше деректер қорымен жұмыс істей алады (суретті қараңыз).

Қызметтер тұрғысынан Boss қолданбасы лезде бөлісуді жүзеге асырады: бір пайдаланушы деректерді енгізеді, ал екіншісі оны алады. Мобильді қосымшаны пайдаланушылар бәрі бірден болатынына үйреніп қалған, сондықтан біз қалай ойластырдық жақсырақ қызмет көрсетупайдалану үшін - SOAP немесе http. Қосылу жылдамдығы маңызды рөл атқарды. http-де қосылу жылдамдығы әлдеқайда жоғары, ал SOAP арқылы қосылу кезінде біз ауыр және ұзақ жүктелетін қызмет сипаттамасын аламыз. Платформада қызмет сипаттамасын сақтау тәсілі бар, бірақ біз динамикалық түрде қосатын параметрлерге байланысты WS сілтемелерін пайдалана алмаймыз. Сонымен қатар, біздің тәжірибемізде http қызметтеріне қол жеткізу ыңғайлырақ және икемді.

Сонымен, біздің мақсатымыз нақты уақыт режимінде алмасуды жүзеге асыру. Яғни, біз оны пайдаланушы бір жерге баруы керек етіп жасамауға тырысамыз, қандай да бір түймені басу керек, оның деректері қаншалықты жаңартылғанын, оны жаңарту керек пе дегенді ойластырамыз ... Пайдаланушыларда әрқашан соңғы жаңалықтар болуы керек. -күн деректері. Олар мессенджерлерде жұмыс істеуге үйренген - бірі деректерді жіберсе, екіншісі оны бірден алды. Барлығы бірден болады. Бұл бизнеске қатысты өтініштерге де қатысты: бір сатушы сатуды шығарды, екіншісі ешқандай әрекет жасамай, ағымдағы жағдайды дереу көруі керек.

Сондықтан, Boss қолданбасы алмасулар үшін фондық тапсырмаларды пайдаланады. Дерекқорға әрбір деректер енгізілгеннен кейін алмасуды бастайтын фондық тапсырма іске қосылады. Бірінші бөлім деректерді серверге жіберу болып табылады. Содан кейін басқа құрылғылар жаңа деректер бар екенін білуі керек. Ол үшін PUSH хабарландыруларын қолданамыз. Бұл схема қазірдің өзінде жұмыс істейді және ол жеткілікті жылдам жұмыс істейді.

Бірақ біз бұдан да жылдамырақ болғымыз келеді, өйткені біз нақты уақытта жұмыс істейміз және әдетте деректеріміз аз. Бізде шағын XML бар, бірақ сонымен бірге біз бірінші құрылғыдан серверге осы деректермен хабарлама жібереміз, сервер басқа құрылғыға PUSH жібереді, содан кейін екінші құрылғы PUSH алғаннан кейін өз тарапынан алмасуды бастайды, серверге қатынасады және деректерді сұрайды, осы деректерді алады, содан кейін деректер алынғаны туралы жауапты жібереді. Бұл ұзақ уақыт, бірақ деректер өте аз болды.

Біз бұл процесті қалай жеделдетуге болатынын ойладық.

Ол үшін біз PUSH құрамында не бар, оны қалай қолдануға болатынын анықтадық. PUSH құрамында деректер мен мәтін сияқты өрістер бар екені анықталды. IOS және Android үшін құжаттама PUSH хабарламаларының көлеміне шектеулерді көрсетеді, бірақ бұл бізге жеткіліксіз болып көрінді және біз оны өзіміз анықтағымыз келді. Біз iOS үшін рұқсат етілген таңбалар қосындысы 981 таңба, ал Android үшін 3832 таңба екенін тексердік. Соңғы жағдайда шектеуді қолдану әбден мүмкін, бір немесе бірнеше негізгі нысандарды осындай көлемге итермелеуге болады. Содан кейін компанияның әзірлеушілері схеманы сәл өзгертті. Деректер көп болмаған кезде, біз оны бір құрылғыдан жібереміз, оны серверде аламыз, оны PUSH ішіне жинап, оны тікелей басқа құрылғыға жібереміз. Схема қысқарды және алмасу одан да жылдам болды :)

PUSH қолданудың маңызды тұсы – ол пайдаланушыларды тітіркендірмейді.

Бұл жағдайдан құтылу өте оңай: пайдаланушыға PUSH хабарламаларын көп жібермеңіз :) Егер ол қазір қолданбада жұмыс істеп тұрса, сіз көптеген хабарламаларды жібере аласыз. Платформа жұмыс істеп тұрғанда, пайдаланушы PUSH көрмейді, ол үшін бәрі автоматты түрде болады. Бірақ қолданба жабылған кезде, клиентте көп нәрсе бар оқылмаған хабарламалар. Сондықтан, құрылғыдан қолданба жұмыс істеп тұрғаны, белсенді екендігі және алдыңғы PUSH өңделгені туралы жауап алынбайынша, ешбір жағдайда келесі PUSH жібермеу керек.

Биржаның тағы бір нюансы - бұл веб арқылы жұмыс. Біз асинхронияны мүмкіндігінше пайдалануымыз керек. Сіз әдеттегідей жұмыс істей алмайсыз - кодты жазыңыз - функцияны шақырыңыз - оның орындалуын күтіңіз - жауап алыңыз - бәрі жақсы. Егер сіз веб арқылы жұмыс жасасаңыз, тұрақсыз Интернет, ұзақ операцияларды орындау кезінде күту уақыттары сияқты белгілі бір шектеулерге кезігесіз. Сондықтан архитектураны алдын ала ойластыру керек.

Пайдаланушы тіркелгісі келгенде қолданбада не болатынын құрылғыны тіркеу мысалын қарастырайық. Ол біраз уақыт жазбаларды жүргізеді, ол көптеген деректерді енгізді, бірақ содан кейін ол сатушының да осы базамен жұмыс істегенін қалайды. Пайдаланушы «тіркеу» түймесін басады. Бастапқыда бәрі өте қарапайым болды: олар оның деректерін алып, оны серверге жазды және, сіз жұмыс істеп, пайдаланушыларды қоса аласыз. Бірақ содан кейін біз кейбір пайдаланушылар үшін құрылғыдағы деректер базасы тіркеу кезінде айтарлықтай өскен жағдайға тап болдық. Және бұл схема бұдан былай жұмыс істемеді, өйткені. бүкіл дерекқор серверде жазылып жатқанда, қосылым күту уақыты іске қосылды немесе Интернет жай ғана үзілді. Сондықтан біз бір синхронды қоңырауды көптеген қысқа қоңырауларға ауыстырдық. Деректер енді бір уақытта тасымалданбайды. Біз кез келген жағдайда сервер деректерді өңдеуді және жазуды күтпейміз. Деректерді жібердік, деректер алынды деген жауап алдық, қосылымды жаптық. Мерзімді түрде серверде не болып жатқанын және қалай болып жатқанын сұрау керек, ал бұл уақытта алынған деректерді жазатын серверде фондық тапсырма орындалады. Бұл көптеген сервер қоңырауларын жасайды, бірақ бізде бәрі жақсы болатынына кепілдік бар. Күту уақыты да, Интернеттің тұрақсыздығы да серверге барлық деректерді жүктеп салуға кедергі болмайды.

ЖАҢАЛЫҚТАР

Әртүрлі қолданба нұсқалары бар құрылғылар арасында ортақ пайдалану

Біз нарыққа шығарылатын жаппай қосымша туралы айтып отырғандықтан, жаңарту және деректер алмасу процесінің кейбір ерекшеліктерін ескеру қажет.

Егер сіз бір кәсіпорын үшін қосымшаны шығарсаңыз және оны жаңартуды шешсеңіз, әдетте сіз барлық қызметкерлерге бірауыздан жаңа қосымшаны орнату туралы бұйрық бересіз. Қолданбаны нарықтан жүктеп алған пайдаланушылармен мұны істеу мүмкін емес. Сіз оларға не істеу керектігін айта алмайсыз. Мысалы, олар қолданбада жұмыс істейді және оны қазір немесе ешқашан жаңартқысы келмейді. Оларда автоматты жаңарту жоқ, сондықтан бұл өте жиі кездесетін жағдай орталық базабірнеше құрылғылар қосылды және олардың барлығы әртүрлі нұсқалары бар. Бұл құбылыстың тағы бір себебі - нарықтардағы жарияланым уақыты: iOS және Android үшін бұл әртүрлі. Біз маңызды қателерді түзету сияқты негізгі нәрселерді жиі шығарамыз және iOS-тың жаңа нұсқасын сынау үшін екі апта күткіміз келмейді, біз кем дегенде Android үшін ғана алғымыз келеді, бірақ жаңартуды дәл қазір шығарамыз.

Біздің пайдаланушыларға бұйрық беруге құқығымыз жоқ. Қаласа, жаңартады, ал болмаса, ештеңе жасамайды. Суретте GooglePlay нұсқалары бойынша Boss қолданбасын орнатулардың арақатынасы, сондай-ақ біздің сервердің статистикасы – өткен аптада сервермен деректер алмасатын құрылғыларда орнатылған қолданба нұсқаларының нақты арақатынасы көрсетілген. Мұнда жұмыс істеуге арналған жиынтық бар. Бұл әртүрлі нұсқалар және әртүрлі метадеректер. Біз бір уақытта қалыпты алмасуды ұйымдастыруымыз керек :)

Әзірлеушілер келесі қиындықтарға тап болады:

• Мұның бәрі жұмыс істеуі керек. Пайдаланушылар жаңартуды ұмытып кеткеніне өкінбеуі керек. Олар мұны мүлдем байқамауы керек. Жаңартылған - бұл жақсы болды, жақсы, жақсы.
• Біз деректердің қауіпсіздігін қамтамасыз етуіміз керек. Мысалы, бір пайдаланушының каталогы мен жаңа төлсипаты болса, екіншісінде әлі жоқ. Сонымен қатар, егер жаңа мәліметтері жоқ пайдаланушы өз құрылғысында бірдеңені өзгертсе, басқа құрылғылардағы деректер жоғалмауы керек.
• Жаңа нұсқаға ауысқан кезде деректердің жаңартылуын қамтамасыз ету қажет. Пайдаланушы жаңартуға дайын деп шешкен кезде, ол ескі нұсқасы болғандықтан, ол жоқ барлық жаңа ақпаратты автоматты түрде алуы керек.

Біз мұны қалай жасадық?

1. Біз серверде 2 алмасу жоспарын қолданамыз. Біріншісі құрылғылар арасында ортақ пайдалануға арналған, екіншісі жаңартуларға арналған. Мысалы, пайдаланушыға каталог жібердік, бірақ оның өлшем бірліктері жоқ, яғни толық емес деректер. Біз мұны есте сақтауымыз керек. Және ол жаңартылған кезде біз оған ондағы жоқ ақпаратты жіберуіміз керек. Ол үшін екінші алмасу жоспары қажет.

2. Объектілерді жазу және оқу үшін біз сақтық көшірме жасау үшін қолданылатын механизмді қолданамыз, яғни метадеректер нұсқасын сақтаймыз. Бұл жағдайда біз сервермен жұмыс істеп жатырмыз және біз конфигурацияға қалаған кез келген нәрсені тікелей қосуға мүмкіндік аламыз, сондықтан біз жай ғана конфигурацияға метадеректер схемаларын қолданбаның дамуы кезінде орналасулар түрінде қосамыз.

Биржадағы және сервердегі үлкен қателерді қалай бақылауға болады

Біріншіден, сіз сервердің қол жетімділігін бақылауыңыз керек. Серверлерде бұл орын алады - олар құлап кетеді. Біз бақылау үшін арнайы ештеңе ойлап таппадық, бірақ бірдеңе дұрыс емес болса айқайлайтын телеграммадан ботты таптық. Ол минут сайын сервердің жұмысын тексереді, егер кенеттен сервер қол жетімсіз болса, ол айқайлай бастайды, әкімшілер мұны көріп, серверді көтереді.

Сондай-ақ журналдан қателер журналын жинаймыз. Сондай-ақ табиғаттан тыс ештеңе жоқ - әр үш сағат сайын біз қателер журналын жинаймыз, оларды поштаға жібереміз, мерзімді түрде қарап шығыңыз. Бұл жалпы проблемаларды және кейбір ерекше жағдайларды көруге көмектеседі. Поштаны қарау, қадағалау және қателерді жылдам түзету қиын емес. Бірақ бұл мәліметтер базасының өсуіне байланысты өсуі мүмкін мәселелерді тез анықтауға және шешуге мүмкіндік береді.

Көбірек маңызды нүкте- пайдаланушыға міндетті түрде «шағымдану» мүмкіндігін беріңіз. Бұл олардың көз алдында біздің мәртебемізді жақсартады және бізді құтқарады. Біз оларды «истерика» деп атайтын пайдаланушылар бар, олар азғантай қателескен кезде бізге пошта арқылы ештеңе жұмыс істемейтін, деректер базасы жүктелмейтін, бәрі өте нашар хабарламалар жібере бастайды. Бірақ кейде олар бізді шынымен құтқарады, өйткені кейде олар қалғандары әлі керемет түрде ашпаған қателерді, елеулі қателерді табады.

Пайдаланушы қорықпауы керек. Ешқандай қорқынышты хабарламалар, басқа ештеңе жоқ. Олар бәрін әдемі түсіндіріп, шағымдануды ұсынуы керек. Ал біз бәрін шешуге уәде береміз. Сонда қолданушылар көңілінен шығады, өйткені олар өздеріне қамқорлық жасалып жатқанын көріп, көмектесетініне бірден сенеді :)

Бұл мақала INFOSTART EVENT 2016 DEVELOPER конференциясында оқылған баяндаманың нәтижелері бойынша жазылған. Қосымша мақалаларды оқуға болады.

2020 жылы біз барлығын 7 аймақтық кездесуге, сондай-ақ Мәскеуде өтетін мерейтойлық INFOSTART EVENT 2020 шарасына қатысуға шақырамыз.

Бұрын желіден тыс, бүгін желіде болу міндетті болып табылады. Кем дегенде, қазіргі бизнес әлемі үшін. Брендтердің өнімдері мен қызметтерінің тұсаукесері, онлайн тапсырыс беру және жеткізу, тұтынушылар базасын қолдау, тұтынушылармен байланыс және т.б. - мұның бәрі Интернетсіз мүмкін емес. Егер сізге қолданба қажет болса, сізде Front-end (веб-интерфейс) және Back-End (қолданбаңыздың сервер жағы) болуы керек. Ал егер қосымшаның мазмұнын әзірлеушілердің қатысуынсыз өңдей алғыңыз келсе, сізге жақсы басқару панелі қажет.

Мобильді қосымшалардағы фронт-end X-Code және Java сияқты технологияларды қолдану арқылы құрастырылғанымен, дерекқор мен барлық қолданба логикасы сақталатын бэк-энд серверлік бағдарламалау тілін кәсіби білуді талап етеді. жақсы үлгібұл PHP, ол кез келген дерлік бэк-енді әзірлеу үшін қолданылатын ең танымал бағдарламалау тілі болып табылады. Бұл сөзсіз көшбасшы.

PHP үшін көптеген қосымшалар бар: статикалық және динамикалық веб-сайттар + пайдаланушы мазмұнды басқару жүйелері, әлеуметтік желілер, арнайы CRM жүйелері, электрондық коммерция бағдарламалық құралы және т.б. Әрине, тегін немесе арзан сервер бөліктері мен басқару тақталары бар. Дегенмен, көп жағдайда олар ыңғайлылықтың, теңшеудің және жаңартудың қажетті деңгейін қамтамасыз етпейді.

Біздің бағдарламашылар әртүрлі бизнес мақсаттары, қажеттіліктері мен талаптары үшін кең ауқымды шешімдерді енгізуге мүмкіндік беретін технологиялармен жұмыс істейді. Біз әрбір жоба үшін жүйелік талаптарды жеке талдаймыз және мобильді қосымшаңыздың оңтайлы өнімділігі үшін әртүрлі мамандандырылған серверлік бағдарламалық құралды қолданамыз.

Қолданбаны нөлден құруға немесе тамаша пайдаланушы тәжірибесі үшін барын қалпына келтіруге арналған ең ақылды және үнемді шешімге апаратын топ іздесеңіз, бұдан әрі іздемеңіз. Appsmob сізге ең жақсы шешімді табуға көмектесуге дайын.

Қолданбаның серверлік жағын әзірлеу

Кіріспе

Интернетте болу қазіргі заманғы компаниялар үшін қажеттілікке айналды. Онсыз тұтынушылармен толыққанды өзара әрекеттесу құру мүмкін емес. Көбінесе мұндай мәселені шешу үшін олар клиент-сервер қосымшаларын жасауға жүгінеді. Олардың әрқайсысы клиент бөлігінен және бэк-эндтен тұрады. Соңғы термин қолданбаның сервер жағына қатысты. Болашақта мазмұнды өзіңіз өзгерту қажет болса мобильді бағдарлама, содан кейін Back-end әсіресе жоғары сапалы жасалуы керек. Appomart қойылған міндеттердің талаптарға сәйкес орындалуына кепілдік береді. Сондықтан, серверлік қосымшаларды жасауға тапсырыс бергенде, сіз дұрыс нәтижеге сенімді бола аласыз.

Back-end не үшін қажет?

Клиент-сервер қосымшаларын әзірлеу екі бөлікті құруды қамтиды. Бірінші, Front-end, пайдаланушылардың сұрауларын қабылдайды. Ол экрандардан көрінеді мобильді құрылғыларклиенттер. Екіншісі, серверлік қосымша, қабылданған сұраныстарды өңдейді және әкімшілік панель ретінде әрекет етеді. Мұнда деректер базасы мен бағдарлама логикасы сақталады. Онсыз ешбір клиент-сервер қолданбасы жұмыс істемейді. Шын мәнінде, бэк-энд бағдарламаның жүрегі болып табылады. Бұл тұтынушылардың сұрауларын өңдеуге, қолданбаның жылдамдығына жауап беретін интеллект. Сондықтан сәулет маңызды сервер қолданбасыТіпті жоғары жүктелген қызметтердің бірқалыпты және жылдам жұмыс істеуі үшін ең кішкентай бөлшектерге дейін ойластырылған.

Бағдарламалау тілін қалай таңдауға болады?

Дайындықта техникалық тапсырма(жобаға арналған жұмыс құжаттамасының бөліктері), сәулетші мәліметтер қоры жүйесін және сілтемелерін жобалайды, объектілерді және олардың қасиеттерін сипаттайды және қажетті сервер әдістерін әзірлейді (сервермен байланысқан кезде мобильді қосымшалардың «пайдаланатынын» сұрайды).

Құжаттаманың және тоқтатылған жобалардың маңыздылығы

Appomart-қа басқа мердігерлер бір немесе басқа себептермен «тастап кеткен» тұтынушылар жиі хабарласады. Біз біреудің, кейде тіпті дұрыс жұмыс істемейтін жобасын аламыз, біз оның аудитін жүргіземіз, содан кейін қайта қарап, қолдау көрсетеміз. Оқу процесінде бастапқы коджәне тапсырыс берушіден алынған материалдар, біз көптеген әзірлеушілер клиентті өздерімен байланыстыру үшін сервер әдістерін әдейі құжаттамайтындығымен бетпе-бет келдік, себебі жобаны басқа әзірлеушіге қолдау көрсетуге аударуға жұмсалатын еңбек шығындарының сәйкес келмеуі салдарынан сервер бөлігі үшін құжаттаманың жоқтығына, кейде жай ғана кәсіби еместігі үшін. Бұл факт, өкінішке орай, қайғылы ғана емес, сонымен қатар кең таралған. Бұл жағдайда тапсырыс беруші жобаны қолдаудың тиімділігін, ыңғайлылығын және орындылығын бағалау мүмкін болмас бұрын, бар жобаның құжаттамасын әзірлеуге, сондай-ақ бастапқы кодтың аудитіне ақы төлеуі керек. Appomart кейінірек пайдалану үшін Postman және Swagger қолдайтын пішімдегі бэк-әдістердің электрондық құжаттамасын жүргізеді.

Келісімшартқа қол қоймас бұрын мердігерді қалай тексеруге болады?

Мердігерді мұқият таңдап, тек қана тартымды бағаға ғана емес, сонымен қатар жобамен бірге алатын құжаттар тізіміне, сондай-ақ бастапқы кодты беру шарттарына және кодты жабуға назар аударуға шақырамыз. түсініктемелер, дерекқор схемалары (бұл Mongo DB немесе MySQL болсын). Табыстың кілті, әдетте, жұмыстың әрбір кезеңі аяқталғаннан кейін сізге берілетін материалдарға қойылатын талаптарды нақты көрсететін құзыретті жұмыс құжаттамасы болып табылады.

Даму ерекшеліктері

серверге арналған PHP

Қолданбалардың серверлік жағын құру («аппараттық құрал» немесе компьютерлер сияқты серверлермен шатастырмау керек, өйткені біз бағдарламалық жасақтама жағы туралы айтып отырмыз) сервер жағында қолданылатын бағдарламалау тілін білу және арнайы кәсіби дағдыларды қажет етеді. Клиент-сервер қосымшаларының мысалдарын қарастырсақ, РНР танымал екенін көреміз. Бұл серверлік қосымшаларды әзірлеудегі сөзсіз көшбасшы. Әлемдегі сайттардың жартысынан көбі осы тілде бір немесе басқа конфигурацияда жазылған. РНР-ді әзірлеу және қолдау оңай, сонымен қатар PHP-де дамуды тездететін арнайы фреймворктар бар.

Рамка

Framework (бағдарламалық қамтамасыз ету платформасы) – жобаны икемді және масштабталатын етіп жасайтын абстракция деңгейін ұйымдастыру және арттыру үшін қолданылады. Дегенмен, жобаның жұмыс құжаттамасын терең талдау негізінде негізді дұрыс таңдау керек екенін түсіну керек, онсыз сапалы өнімді әзірлеу мүмкін емес.

Delphi, JAVA, Python

Back-end жасау үшін қолданылатын басқа тілдер бар. Сонымен, жылы құрылған Delphi ортасысерверлік қолданбалар. Оның көмегімен бағдарлама жөндеуді жақсартады, сонымен қатар ортада бірегей бағдарламаларды жасау оңай, ол қамтамасыз етілген. визуалды жасау, бұл әдемі, түсінікті және жасауға мүмкіндік береді пайдаланушыға ыңғайлы интерфейс. Java серверлік қосымшалары да танымал болды. Олар оңай толықтырылады, кез келген платформада оңай орындалады және лайықты қауіпсіздік деңгейіне ие. Тағы бір танымал тіл - Python. Оның көмегімен серверлік қосымшалар тез, қарапайым, елеулі шығындарсыз жасалады.

Тарату

Клиент-сервер қосымшаларын құру корпоративтік ортада сұранысқа ие. Жиі ұқсас бағдарламаларжұмыс топтары немесе кәсіпорын ішінде ақпараттық жүйелерді құру үшін пайдаланылады. Клиентпен байланысты қолдауға арналған мобильді қосымшалардың басым көпшілігінде де ұқсас архитектура бар. Танымалдығы сервер мүмкіндіктерін пайдалану желі жүктемесін азайта отырып, жүйені басқаруды және тұтастығын қамтамасыз етуге мүмкіндік беретіндігіне байланысты.

Біз жоғары сапалы және уақытылы Android, iOS үшін клиент-сервер қосымшасын жасаймыз

Кілтке тапсыру

Appomart бағдарламашылары әртүрлі деңгейдегі тапсырмаларды орындау үшін тәжірибелі және білікті. Біз әлеуметтік желілерді, жоғары жүктемелі бизнес жобаларды немесе бағдарламалық қамтамасыз ету бөлігішағын стартаптар үшін. Қажет болса, біз қолданбаның клиент бөлігін жасаймыз Android басқару, бар қажеттіліктерге, талаптарға сәйкес iOS.

Appomart сайтындағы бэк-end

Біздің бағдарламашылар әртүрлі технологиялармен жұмыс істейді және оны бірдей жақсы орындайды. Appomart-та ​​сіз Java, PHP және Node.JS тіліндегі клиент-сервер қолданбасына тапсырыс бере аласыз. Жүйе талаптарыжобалардың әрқайсысы бойынша жеке талданады, бұл бағдарламаның оңтайлы орындалуын қамтамасыз етуге мүмкіндік береді. Біз Java, PHP және Node.JS клиент-сервер қолданбасын нөлден жасаймыз немесе жақсартулар мен жаңартуларға қолдау көрсету үшін барын аламыз. Жаңа сервер бөлігін әзірлеуге немесе бұрыннан барын қолдауға қызығушылық танытсаңыз, жұмыс құнының егжей-тегжейлі есебін және ынтымақтастық нұсқаларын алу үшін сұрау қалдырыңыз.

қарама - қарсы беті мобильді клиенттер- сервер.

Қосымша талаптар қолданбаның ерекшеліктеріне байланысты:
сервердің ауқымдылығы - SaaS үшін, келушілердің үлкен ағыны күтілетін әлеуметтік қолданбалар үшін бұл шарт міндетті болып табылады. Пайдаланушылар санына шектеулер бар немесе болжамды саны бар іскери қолданбалар үшін бұл сипат талап етілмейді;
интерактивтілік: бірқатар қосымшаларды хабарландыру механизмімен қамтамасыз ету қажет - қосымшаны (пайдаланушыны) белгілі бір оқиғалардың орын алуы туралы хабардар ету, пайдаланушыға хабарлама жіберу. Бұл меншікте, мысалы, алмасу жүйесі немесе болуы керек автоматты диспетчерТакси.
Open API: үшінші тарап әзірлеушілері құжатталған хаттама арқылы жүйенің функционалдығын пайдалана алады деп болжанады. Өйткені, клиент мобильді және сыртқы сервер қосымшасы бола алады.
басқа талаптар...

Команда

Мұқият оқырман сервер қосымшасын жазған жағдайда мұны байқайды GUI, мысалы, HTML5-де сақтауға болады. Бұл жағдайда клиенттік қосымшаларды әзірлеу қажет емес - пайдаланушы интерфейсін браузер қамтамасыз етеді. Бұл мақалада мұндай жағдай қарастырылмайды, біз мобильді құрылғыларға арналған «туған» (туған) қосымшаларды әзірлеу туралы айтып отырмыз.

Менде толық комплементі бар командада жұмыс істеу мүмкіндігі болды, бірақ шынайы болыңыз - әрқашан адам ресурстары мен бюджет мұндай команданы жинауға мүмкіндік бермейді. Ал кейде рөлдерді біріктіруге тура келеді: жоба менеджері + сервер қосымшасын жасаушы, клиенттік қосымшаны әзірлеуші ​​+ сынақшы.

Технологиялар, құралдар, кітапханалар

Жүйенің ерекшелігіне және оған қойылатын талаптарға байланысты деректер алмасу хаттамасын жүзеге асырудың 2 нұсқасының бірін қолданамын.
Кросс-платформалық, жылдамдық, қарапайымдылық, тиімділік, ауқымдылық, ашық API қажет болғанда, мен Jersey - REST веб-қызметтерін (RESTful Web қызметтерін) жүзеге асыруды аламын. Бұл кітапхана JSON немесе/және XML пішімінде деректерді сериялауды пайдалануға мүмкіндік береді. REST конфигурациясы аннотациялар арқылы сақталады. Мобильді құрылғылармен алмасу үшін JSON пішімі оның клиенттік жағында жеңілірек іске асырылуы (осы себепті біз «классикалық» веб-қызметтерді пайдаланбаймыз), трафиктің аз мөлшері жасалғандықтан алынды. Джерси JSON-тың ең қолайлы «түріне» баптауға мүмкіндік береді.
Әйтпесе, егер сізге кросс-платформалық, жоғары өнімділік, қарапайымдылық, тиімділік, интерактивтілік қажет болса, мен қабылдаймын
Apache MINA - желілік қосымшаларды жасауға арналған құрылым,
Google protobuf — құрылымдық деректерді кодтау және декодтау кітапханасы. Деректер құрылымы *.proto тақырып файлдарымен анықталады, компилятор олардан Java класстарын жасайды (оларды басқа бағдарламалау тілдері үшін де генерациялауға болады: C++, Objective-C және т.б. платформалар аралық қасиетін қамтамасыз етеді). ;
java.util.concurrent – ​​стандартты пакетті пайдаланыңыз.
Бұл опцияны масштабтауға болады, бірақ оны бизнес логикасын ескере отырып, сәулет деңгейінде жобалау кезеңінде жоспарлау қажет.

Адамдарға қажетті қызметтерді немесе жұмыстарды орындауға тапсырыс беруге, ал ұйымдар өз кезегінде олар үшін өз ұсыныстарын қалдыруға мүмкіндік беретін нақты SaaS қызметі үшін технологияларды таңдау мысалын қолданып гипотетикалық тапсырманы қарастырыңыз - «Auknem Services аукционы». . Біз барлық негізгі талаптарды әдепкі бойынша қабылдаймыз. Бұл жүйеде тіркелу тегін және тегін екенін ескере отырып, оларға ауқымдылықты қосу қажет. Интерактивтілік туралы не деуге болады? Мердігерлерді (орындаушыларды) жаңа тапсырыстарды құру туралы хабардар ету және тапсырыс берушілерді өтінімде бір уақытта алынған ұсыныстар туралы хабардар ету жақсы болар еді электрондық пошта. Осының негізінде біз енгізу үшін Apache MINA, Google протобуфын аламыз. Біз келесі сипатты қарастырамыз - Open API. Қызмет жалпыға қолжетімді, сондықтан сыртқы әзірлеушілер онымен интеграциялануға мүдделі болуы мүмкін делік. Күте тұрыңыз! Қарапайым емес. Apache MINA негізіндегі хаттама толығымен іске асыруға тәуелді және нюанстарды білмей интеграция ешбір жағдайда ашық емес. Мұндай жағдайда қай фактордың маңыздырақ екенін өлшеп, таңдау жасауға тура келеді.

Қорытынды

Клиент-сервер қосымшасының серверлік жағын әзірлеу архитектуралық дизайннан басталады. Көп нәрсе архитектураға байланысты: қолданбаның кеңеюінен оның өнімділігіне және қолдау/техникалық қызмет көрсетудің қарапайымдылығына дейін.

Ең алдымен, деректердің серверге қалай орналастырылатынын және клиенттен келетін сұраулар қалай өңделетінін анықтау керек. Сондай-ақ серверлік деректерді кэштеуді ұйымдастыруды ойластыру қажет.

Деректер алмасу хаттамалары мен деректерді беру форматтары туралы шешім қабылдау қажет.

API (application programming interface) – интерфейс қолданбалы бағдарламалау. Неғұрлым түсінікті тілде бұл серверге сұраныстар жиынтығы, соңғысы оны түсінеді және дұрыс жауап бере алады. API сервер логикасының функционалдығын анықтайды, ал API бұл функцияның жүзеге асырылу жолын қысқартуға мүмкіндік береді. Басқаша айтқанда, API жалпы клиент-сервер инфрақұрылымының қажетті бөлігі болып табылады.

JSON және XML салыстырыңыз. Қолдану түріне байланысты хаттамаларға мысал келтіріңіз.

Көп ағынды

Қазіргі бағдарламалаудың негізгі аспектілерінің бірі - көп ағындылық. Көп ағынның көмегімен біз бір уақытта әртүрлі тапсырмаларды орындайтын қолданбадағы бірнеше ағындарды ажырата аламыз.

Multithreading платформаның қасиеті болып табылады (мысалы, операциялық жүйе, виртуалды машинат.б.) немесе операциялық жүйеде пайда болған процесс «параллельді» орындалатын, яғни уақыт бойынша белгіленген тәртіпсіз бірнеше ағындардан тұруы мүмкін екендігінен тұратын қолданба.

Көп ағынның мәні бір орындалатын процесс деңгейіндегі квази-көп тапсырмалылық болып табылады, яғни барлық ағындар процестің адрестік кеңістігінде орындалады. Сонымен қатар, процестің барлық ағындарында жалпы адрестік кеңістік қана емес, сонымен қатар жалпы файл дескрипторлары болады. Іске қосылған процесте кемінде бір (басты) ағын бар.

Көп ағынды (бағдарламалау доктринасы ретінде) көп тапсырманы немесе көп өңдеуді шатастырмау керек, тіпті көп тапсырманы жүзеге асыратын операциялық жүйелер көп ағынды да жүзеге асыруға бейім.

Бағдарламалауда көп ағынның артықшылықтарына мыналар жатады:

Кейбір жағдайларда жалпы мекенжай кеңістігін пайдалану арқылы бағдарламаны жеңілдету.

Процесске қатысты ағынды жасауға аз уақыт жұмсалады.

Процессор есептеулері мен енгізу/шығару операцияларын параллельдеу арқылы процесс өнімділігін жақсарту.

Ағын(ағын) – орындалатын кодтың басқарылатын бірлігі. Ағынға негізделген көп тапсырмалы ортада барлық орындалатын процестерде міндетті түрде негізгі ағын болады, бірақ одан да көп болуы мүмкін. Бұл бір бағдарлама бірнеше тапсырмаларды асинхронды түрде орындай алатынын білдіреді. Мысалы, мәтінді өңдеу мәтіндік редакторбасып шығару уақытында, өйткені екі тапсырма әртүрлі ағындарда орындалады.

Кәдімгі процессорда ағынды басқару операциялық жүйемен өңделеді. Аппараттық үзіліс орын алғанша ағын орындалады, жүйелік қоңыраунемесе операциялық жүйе оған бөлінген уақыт біткенше. Осыдан кейін процессор ағынның күйін (оның контекстін) сақтайтын операциялық жүйе кодына ауысады немесе басқа ағынның күйіне ауысады, оған да орындауға уақыт бөлінеді. Осындай көп ағынмен бұл жеткілікті көп саны CPU циклдері контексттерді ауыстыратын операциялық жүйе кодына жұмсалады. Егер ағынды қолдау аппараттық құралда жүзеге асырылса, онда процессордың өзі ағындар арасында ауыса алады және идеалды жағдайда әр тактілік цикл үшін бір уақытта бірнеше ағындарды орындай алады.

– Уақытша көп ағынды (бір ағын)

– Бір мезгілде көп ағынды (бір уақытта бірнеше ағындар)

Көп ағынды бағдарламалау және кодты орындаудың кең таралған моделі ретінде бірнеше ағындарды бір процесс ішінде іске қосуға мүмкіндік береді. Бұл орындалу ағындары процестің ресурстарын ортақ пайдаланады, бірақ сонымен бірге өздігінен жұмыс істей алады. Көп ағынды бағдарламалау моделі әзірлеушілерге параллель орындаудың ыңғайлы абстракциясын береді. Дегенмен, мүмкін, технологияның ең қызықты қолданылуы оның көп процессорлы жүйеде параллель орындалуына мүмкіндік беретін бір процесске қолданылуы болып табылады.

Көп ағынды бағдарламаның бұл артықшылығы оның жылдам жұмыс істеуіне мүмкіндік береді компьютерлік жүйелер, оларда бірнеше процессорлар, бірнеше ядролары бар процессорлар немесе машиналар кластерінде - бағдарламаны орындау ағындары процестердің шын мәнінде параллель орындалуына табиғи түрде қарыз беретіндіктен. Бұл жағдайда бағдарламашы жарыс жағдайларынан және басқа интуитивті емес әрекеттерден аулақ болу үшін өте сақ болуы керек. Деректерді дұрыс өңдеу үшін орындалу ағындары деректерді дұрыс ретпен өңдеу үшін жиі кездесу процедурасынан өтуі керек. Орындау ағындары ортақ деректердің бір уақытта өзгертілуін немесе модификация процесі кезінде оқылуын болдырмау үшін мутекстерді де қажет етуі мүмкін (олар жиі семафорлар арқылы жүзеге асырылады). Мұндай примитивтерді абайсыз пайдалану тығырыққа әкелуі мүмкін.

Көп ағынды қолданудың тағы бір түрі, тіпті бірпроцессорлық жүйелер үшін де, қолданбаның енгізуге жауап беру мүмкіндігі. Бір ағынды бағдарламаларда орындаудың негізгі ағыны ұзақ орындалатын тапсырманы орындау арқылы бұғатталған болса, бүкіл қолданба мұздатылған күйде болуы мүмкін. Ұзақ орындалатын тапсырмаларды негізгі ағынмен параллель жұмыс істейтін жұмыс ағынына жылжыту арқылы тапсырмалар орындалып жатқанда қолданбалардың пайдаланушы енгізуіне жауап беруін жалғастыру мүмкін болады. фон. Екінші жағынан, көп жағдайда көп ағындылық бағдарламаны жауап берудің жалғыз жолы емес. Дәл осыған асинхронды енгізу/шығару немесе UNIX жүйесіндегі сигналдар арқылы қол жеткізуге болады.

Көп тапсырманың екі түрі бар: процеске негізделгенжәне ағынға негізделген. Процесс негізіндегі және ағындық көптапсырманың айырмашылығы келесідей: процеске негізделген көптапсырма бағдарламаларды параллель орындау үшін ұйымдастырылған, ал ағын негізіндегі көптапсырма бір бағдарламаның жеке бөліктерін параллель орындауға арналған.

Ағынның екі түрі бар:

Алдыңғы ағындар немесе алдыңғы план. Әдепкі бойынша, Thread.Start() әдісі арқылы жасалған әрбір ағын автоматты түрде алдыңғы қатарға айналады. Бұл түріАғындар ағымдағы қолданбаны тоқтатудан қорғауды қамтамасыз етеді. Жалпы тілдің орындалу уақыты барлық алдыңғы ағындар аяқталғанша қолданбаны тоқтатпайды.

Фондық ағындар. Демон ағындары деп те аталатын ағындардың бұл түрі кез келген уақытта еленбейтін кеңейтілетін орындау жолдары ретінде жалпы тілдің орындалу уақыты арқылы өңделеді. Осылайша, барлық алдыңғы ағындар аяқталса, қолданба домені жүктелген кезде барлық фондық ағындар автоматты түрде жойылады. Фондық ағындарды жасау үшін IsBackground сипатын шын мәніне орнату керек.

Жіптердің күйлері туралы айтыңыз: жүгіру, ілулі, жүгіру, бірақ бір нәрсені күту.

Тақырыпты синхрондау мәселесі және ортақ ресурстар.

Жіптің өзара әрекеттесуі

Көп ағынды ортада параллель орындалатын ағындар арқылы бірдей деректерді немесе құрылғыларды пайдаланумен байланысты мәселелер жиі кездеседі. Мұндай есептерді шешу үшін мутекстер, семафорлар, критикалық бөлімдер және оқиғалар сияқты ағынның өзара әрекеттесу әдістері қолданылады.

Мутекссинхрондау нысаны болып табылады, ол кез келген ағынмен қамтылмаған кезде арнайы сигналдық күйге орнатылады. Бұл нысанды кез келген уақытта тек бір ағын иеленеді, демек, мұндай нысандардың атауы (ағылшын тілінен өзара эксклюзивті қатынас - өзара эксклюзивті қатынас) - ортақ ресурсқа бір мезгілде қол жеткізу алынып тасталады. Барлық қажетті әрекеттерден кейін басқа ағындарға ортақ ресурсқа кіруге мүмкіндік беретін мутекс шығарылады. Нысан сол ағынмен екінші рет рекурсивті түсіруді қолдай алады, ағынды блоктамастан есептегішті ұлғайтады, содан кейін бірнеше шығарылымдарды қажет етеді. Бұл, мысалы, Win32-дегі маңызды бөлім. Дегенмен, бұған қолдау көрсетпейтін кейбір іске асырулар бар және рекурсивті түсіру әрекеті кезінде ағынды тығырыққа тірейді. Бұл Windows ядросындағы FAST_MUTEX.

семафорларресурс пулы бос болғанша бір уақытта бірнеше ағындар арқылы алуға болатын қолжетімді ресурстарды көрсетеді. Содан кейін қосымша ағындар ресурстардың қажетті көлемі қайтадан қол жетімді болғанша күтуі керек. Семафорлар өте тиімді, өйткені олар ресурстарға бір мезгілде қол жеткізуге мүмкіндік береді.

Оқиғалар. «Сигнал берілген немесе жоқ» 1 бит ақпаратты сақтайтын объект, онда «сигнал», «сигналсыз күйге қалпына келтіру» және «күту» операциялары анықталады. Белгіленген оқиғаны күту - бұл жіптің орындалуын дереу жалғастырумен операцияның болмауы. Сигналсыз оқиғаны күту басқа ағын (немесе ОЖ ядросындағы үзу өңдеушісінің екінші фазасы) оқиғаға сигнал бергенше ағынның орындалуын тоқтатады. «Кез келген» немесе «барлығы» режимдерінде бірнеше оқиғаны күтуге болады. Сондай-ақ, бірінші және жалғыз күту ағынын оятқаннан кейін сигналсыз күйге автоматты түрде қалпына келтірілетін оқиғаны жасауға болады (мұндай нысан «сыни бөлім» нысанын іске асыру үшін негіз ретінде пайдаланылады). MS Windows жүйесінде пайдаланушы режимінде де, ядро ​​режимінде де белсенді қолданылады. Linux ядросында kwait_queue деп аталатын ұқсас нысан бар.

Сыни бөлімдерсыни бөлімдерді көрсететін нысандар бір процесте қол жетімді болатынын қоспағанда, мутекстер сияқты синхрондауды қамтамасыз етеді. Оқиғаларды, мутекстерді және семафорларды бір процесті қолданбада да пайдалануға болады, дегенмен кейбір операциялық жүйелерде (мысалы, Windows NT) маңызды бөлімдерді іске асыру өзара ерекше синхрондау үшін жылдам және тиімді механизмді қамтамасыз етеді - алу және босату критикалық бөлімдегі операциялар ОЖ ядросына апаратын жүйелік шақыруларды болдырмау үшін бір ағынды жағдайға оңтайландырылған (қайшылық жоқ). Мутекстер сияқты, маңызды бөлімді білдіретін нысан бір уақытта тек бір ағынмен пайдаланылуы мүмкін, бұл оларды ортақ ресурстарға қол жеткізуді шектеуде өте пайдалы етеді.

Шартты айнымалылар(кондварлар). Оқиғаларға ұқсас, бірақ олар жадты алатын объектілер емес – тек айнымалының адресі пайдаланылады, «айнымалының мазмұны» түсінігі жоқ, шарт айнымалысы ретінде ерікті объектінің адресі пайдаланылуы мүмкін. Оқиғалардан айырмашылығы, айнымалы мәнде күтіп тұрған ағындар болмаса, шарт айнымалы мәнін сигналдық күйге орнату ешқандай нәтиже бермейді. Ұқсас жағдайда оқиғаны орнату оқиғаның өзінде «сигнал» күйін сақтауды талап етеді, содан кейін оқиғаны күтуді қалайтын кейінгі ағындар тоқтаусыз орындауды дереу жалғастырады. Мұндай нысанды толық пайдалану үшін «мутексті босату және шарттың айнымалысын атомдық түрде күту» операциясы да қажет. UNIX тәрізді операциялық жүйелерде белсенді қолданылады. Оқиғалар мен шарт айнымалыларының артықшылықтары мен кемшіліктері туралы талқылау оқиғалар мен шарт айнымалыларының артықшылықтары мен кемшіліктері туралы талқылаулардың маңызды бөлігі болып табылады. Windows жүйесінің кемшіліктеріжәне UNIX.

Енгізу/шығаруды аяқтау порты(IO аяқтау порты, IOCP). ОЖ ядросында енгізілген және жүйелік шақырулар арқылы қолжетімді, «құрылымды кезектің соңына қою» және «кезек басынан келесі құрылымды алу» операциялары бар «кезек» объектісі – соңғы шақыру орындауды тоқтатады. ағынның кезегі бос болса және басқа ағын қою шақыруын жасамайынша. IOCP-тің ең маңызды ерекшелігі - құрылымдарды пайдаланушы режимінен жүйелік шақыру арқылы ғана емес, сонымен қатар файлдың бірінде асинхронды енгізу-шығару операциясының аяқталуы нәтижесінде ОЖ ядросының ішіне жасырын түрде орналастыруға болады. дескрипторлар. Бұл әсерге қол жеткізу үшін «файл дескрипторын IOCP-мен байланыстыру» жүйелік шақыруын пайдалану керек. Бұл жағдайда кезекке орналастырылған құрылымда енгізу-шығару операциясының қате коды, сондай-ақ осы операция сәтті болған жағдайда нақты енгізілген немесе шығыс байттардың саны болады. Аяқтау портын іске асыру құрылымды кезектен алғаннан кейін бір процессорда/ядрода орындалатын ағындардың санын шектейді. Нысан MS Windows жүйесіне тән және ағындар саны клиенттер санынан аз болуы мүмкін архитектурада серверлік бағдарламалық құралда кіріс қосылым сұраулары мен деректер бөліктерін өңдеуге мүмкіндік береді (ресурспен бөлек ағынды құру талап етілмейді. әрбір жаңа клиент үшін шығындар).

Жіп пулы

Жіп пулы туралы айтыңыз