ለ 1ሲ፡ ኢንተርፕራይዝ፡ ጃቫ፣ ፖስትግሬኤስኪኤል፣ ሃዘልካስት በከፍተኛ ደረጃ የተጫነ ሊዛናዊ አገልግሎት እንዴት እና ለምን እንደጻፍን

በዚህ ጽሑፍ ውስጥ እንዴት እና ለምን እንዳዳበርን እንነጋገራለን መስተጋብር ስርዓት - በደንበኛ አፕሊኬሽኖች እና በ1C መካከል መረጃን የሚያስተላልፍ ዘዴ፡ የኢንተርፕራይዝ ሰርቨሮች - አንድን ተግባር ከማዘጋጀት እስከ አርክቴክቸር እና አተገባበር ዝርዝሮች ድረስ ማሰብ።

የመስተጋብር ስርዓቱ (ከዚህ በኋላ - CB) የተከፋፈለ ጥፋትን የሚቋቋም የመልእክት መላላኪያ ስርዓት ሲሆን ዋስትና ያለው ማድረስ ነው። CB እንደ የመስመር ላይ አገልግሎት (በ 1C የቀረበ) እና በራሱ የአገልጋይ መገልገያዎች ላይ ሊሰማራ የሚችል የምርት ምርት ከፍተኛ አቅም ያለው ከፍተኛ ጭነት ያለው አገልግሎት ነው የተቀየሰው።

SW የተከፋፈለ ማከማቻ ይጠቀማል hazelcast እና የፍለጋ ሞተር Elasticsearch. እንዲሁም ስለ ጃቫ እና እንዴት PostgreSQL በአግድም እንደምንመዘን እንነጋገራለን ።

የችግሩ ቀመር

የመስተጋብር ስርዓቱን ለምን እንደሰራን ግልፅ ለማድረግ ፣ በ 1C ውስጥ የንግድ መተግበሪያዎችን እድገት እንዴት እንደሚሰራ ትንሽ እነግርዎታለሁ።

በመጀመሪያ፣ ስለ እኛ ገና የምናደርገውን ለማያውቁት ትንሽ :) የ 1C: ኢንተርፕራይዝ ቴክኖሎጂ መድረክን እያዘጋጀን ነው። የመሳሪያ ስርዓቱ የቢዝነስ አፕሊኬሽን ማጎልበቻ መሳሪያን እንዲሁም የንግድ አፕሊኬሽኖችን በፕላትፎርም አካባቢ ውስጥ እንዲሰሩ የሚያስችል የሩጫ ጊዜን ያካትታል።

የደንበኛ-አገልጋይ ልማት ምሳሌ

በ1C፡ኢንተርፕራይዝ የተፈጠሩ የንግድ መተግበሪያዎች በሶስት ደረጃ ይሰራሉ ደንበኛ-አገልጋይ አርክቴክቸር "DBMS - የመተግበሪያ አገልጋይ - ደንበኛ". የማመልከቻ ኮድ ተጽፏል አብሮ የተሰራ ቋንቋ 1C, በመተግበሪያው አገልጋይ ወይም በደንበኛው ላይ ሊሠራ ይችላል. ሁሉም ስራዎች ከመተግበሪያ እቃዎች (መመሪያዎች, ሰነዶች, ወዘተ) እንዲሁም የውሂብ ጎታውን ማንበብ እና መጻፍ በአገልጋዩ ላይ ብቻ ይከናወናሉ. ቅጾች እና የትዕዛዝ በይነገጽ ተግባራት በአገልጋዩ ላይም ይተገበራሉ። በደንበኛው ላይ ቅጾች ይቀበላሉ ፣ ይከፈታሉ እና ይታያሉ ፣ ከተጠቃሚው ጋር “ግንኙነት” (ማስጠንቀቂያዎች ፣ ጥያቄዎች ...) ፣ ፈጣን ምላሽ በሚፈልጉ ቅጾች ውስጥ ትናንሽ ስሌቶች (ለምሳሌ ፣ ዋጋውን በብዛት ማባዛት) ፣ ከ ጋር አብሮ በመስራት። የአካባቢ ፋይሎች, ከመሳሪያዎች ጋር በመስራት ላይ.

በመተግበሪያው ኮድ ውስጥ የሂደቶች እና የተግባሮች ራስጌዎች ኮዱ የት እንደሚተገበር በግልፅ ማመልከት አለባቸው - መመሪያዎችን &AtClient / &AtServer (&AtClient / &AtServer በእንግሊዘኛው የቋንቋው ስሪት) በመጠቀም። የ1C ገንቢዎች መመሪያዎቹ በትክክል ናቸው በማለት አሁን ያርሙኛል። ከ, ግን ለእኛ አሁን አስፈላጊ አይደለም.

የአገልጋይ ኮድ ከደንበኛ ኮድ መደወል ይችላሉ፣ ነገር ግን የደንበኛ ኮድ ከአገልጋይ ኮድ መደወል አይችሉም። ይህ በብዙ ምክንያቶች በእኛ የተሰራ መሠረታዊ ገደብ ነው. በተለይም የአገልጋይ ኮድ ከየትኛውም ቦታ ቢጠራ - ከደንበኛው ወይም ከአገልጋዩ ተመሳሳይ በሆነ መንገድ መፃፍ ስላለበት። እና ከሌላ የአገልጋይ ኮድ ወደ የአገልጋይ ኮድ ጥሪ ከሆነ እንደዚህ ያለ ደንበኛ የለም። እና የአገልጋይ ኮድ በሚፈፀምበት ጊዜ የደወለው ደንበኛ አፕሊኬሽኑን መዝጋት፣ መውጣት ይችላል እና አገልጋዩ የሚደውልለት አይኖርም።

የአዝራር ጠቅታ የሚያስተናግድ ኮድ፡ የአገልጋይ አሰራርን ከደንበኛው መጥራት ይሰራል፣ የደንበኛ አሰራርን ከአገልጋዩ መጥራት አይሰራም

ይህ ማለት ከአገልጋዩ ወደ ደንበኛው መተግበሪያ አንዳንድ መልእክት ለመላክ ከፈለግን ለምሳሌ "የረጅም ጊዜ መጫወት" ሪፖርት መመስረቱ አብቅቷል እና ሪፖርቱ ሊታይ ይችላል, እንደዚህ አይነት መንገድ የለንም. ዘዴዎችን መጠቀም አለብህ፣ ለምሳሌ፣ በየጊዜው አገልጋዩን ከደንበኛ ኮድ ጠይቅ። ነገር ግን ይህ አቀራረብ ስርዓቱን አላስፈላጊ ጥሪዎችን ይጭናል, እና በአጠቃላይ በጣም የሚያምር አይመስልም.

እና ደግሞ ፍላጎት አለ, ለምሳሌ, ስልክ ጊዜ የ SIP-call፣ስለዚህ የደንበኛ አፕሊኬሽኑን በተጓዳኝ ዳታቤዝ ውስጥ በጠዋዩ ቁጥር እንዲያገኘው እና ስለ ጥሪው ተጓዳኝ መረጃ ለተጠቃሚው ያሳውቁ። ወይም፣ ለምሳሌ፣ ትእዛዝ ወደ መጋዘኑ ሲደርስ፣ ስለዚህ ጉዳይ ለደንበኛው ደንበኛ ማመልከቻ ያሳውቁ። በአጠቃላይ እንዲህ ዓይነቱ ዘዴ ጠቃሚ የሚሆንባቸው ብዙ አጋጣሚዎች አሉ.

በትክክል ማቀናበር

የመልእክት መላላኪያ ዘዴ ይፍጠሩ። ፈጣን፣ አስተማማኝ፣ ዋስትና ያለው ማድረስ፣ ለመልእክቶች ተለዋዋጭ ፍለጋ ዕድል ያለው። በስልቱ ላይ በመመስረት በ1C መተግበሪያዎች ውስጥ የሚሰራ መልእክተኛ (መልእክቶች፣ የቪዲዮ ጥሪዎች) ተግብር።

ስርዓቱን በአግድም ሊሰፋ የሚችል ዲዛይን ያድርጉ። እየጨመረ የሚሄድ ጭነት በኖዶች ቁጥር መጨመር መሸፈን አለበት.

ትግበራ

የ CB አገልጋይ ክፍል በቀጥታ ወደ 1C: የድርጅት መድረክ ላለመክተት ወስነናል ፣ ግን እንደ የተለየ ምርት ለመተግበር ፣ ኤፒአይ ከ 1C መተግበሪያ መፍትሄዎች ኮድ ሊጠራ ይችላል። ይህ የተደረገው በበርካታ ምክንያቶች ነው, ዋናው ነገር በተለያዩ የ 1C አፕሊኬሽኖች (ለምሳሌ በንግድ እና አካውንቲንግ መምሪያ መካከል) መካከል መልዕክቶችን ለመለዋወጥ ነበር. የተለያዩ የ1C አፕሊኬሽኖች በተለያዩ የ1C፡የኢንተርፕራይዝ መድረክ፣በተለያዩ አገልጋዮች ላይ ሊገኙ፣ወዘተ ሊሰሩ ይችላሉ። በእንደዚህ ዓይነት ሁኔታዎች የ CB ን እንደ የተለየ ምርት መተግበር, በ 1C ጭነቶች "በጎን" ላይ የተቀመጠው, በጣም ጥሩው መፍትሄ ነው.

ስለዚህ, CB እንደ የተለየ ምርት ለመሥራት ወሰንን. ለአነስተኛ ኩባንያዎች ከአካባቢው አገልጋይ ጭነት እና ውቅረት ጋር የተያያዘውን ትርፍ ለማስቀረት በደመናችን ላይ የጫንነውን የCB አገልጋይ (ws://1cdialog.com) እንዲጠቀሙ እንመክራለን። ትላልቅ ደንበኞች ግን የራሳቸውን የCB አገልጋይ በተቋሞቻቸው ላይ መጫን ጠቃሚ እንደሆነ አድርገው ሊቆጥሩት ይችላሉ። በእኛ የዳመና SaaS ምርት ውስጥ ተመሳሳይ አካሄድ ተጠቀምን። 1c ትኩስ - በደንበኞች ለመጫን እንደ የማምረቻ ምርት ይለቀቃል, እና በእኛ ደመና ውስጥም ይሠራል https://1cfresh.com/.

ትግበራ

ለጭነት ስርጭት እና ስህተት መቻቻል አንድ የጃቫ መተግበሪያን አናሰማራም ፣ ግን ብዙ ፣ የጭነት ሚዛን ከፊት ለፊታቸው እናስቀምጣለን። መልእክት ከኖድ ወደ መስቀለኛ መንገድ መላክ ከፈለጉ በ Hazelcast ውስጥ ማተም/ደንበኝነት መመዝገብን ይጠቀሙ።

በደንበኛው እና በአገልጋዩ መካከል ግንኙነት - በዌብሶኬት በኩል። ለእውነተኛ ጊዜ ስርዓቶች በጣም ተስማሚ ነው.

የተከፋፈለ መሸጎጫ

በRedis፣ Hazelcast እና Ehcache መካከል ይምረጡ። ውጪ በ2015። ሬዲስ አዲስ ክላስተር ለቋል (በጣም አዲስ፣ አስፈሪ)፣ ብዙ ገደቦች ያለው ሴንቲነል አለ። Ehcache እንዴት እንደሚሰበስብ አያውቅም (ይህ ተግባር በኋላ ላይ ታየ)። በ Hazelcast 3.4 ለመሞከር ወስነናል።
Hazelcast ከሳጥኑ ውስጥ ተሰብስቧል። በነጠላ መስቀለኛ መንገድ, በጣም ጠቃሚ አይደለም እና እንደ መሸጎጫ ብቻ ሊገጣጠም ይችላል - መረጃን ወደ ዲስክ እንዴት መጣል እንዳለበት አያውቅም, ብቸኛው መስቀለኛ መንገድ ከጠፋ, ውሂቡ ይጠፋል. በርካታ Hazelcasts አሰማርተናል፣ በመካከላቸውም ወሳኝ ውሂብ ምትኬ እናደርጋለን። መሸጎጫውን ምትኬ አናደርግለትም - ለእሱ አያዝንም።

ለእኛ Hazelcast ይህ ነው፡-

• የተጠቃሚ ክፍለ-ጊዜዎች ማከማቻ. ለአንድ ክፍለ ጊዜ ወደ ዳታቤዝ ለመሄድ ረጅም ጊዜ ይወስዳል፣ ስለዚህ ሁሉንም ክፍለ-ጊዜዎች በ Hazelcast ውስጥ እናስቀምጣለን።
• መሸጎጫ የተጠቃሚ መገለጫን በመፈለግ ላይ - በመሸጎጫው ውስጥ ያረጋግጡ. አዲስ መልእክት ጻፈ - በመሸጎጫው ውስጥ ያስቀምጡት.
• የመተግበሪያ ምሳሌዎችን የግንኙነት ርዕሶች. መስቀለኛ መንገድ አንድ ክስተት ያመነጫል እና በ Hazelcast ርዕስ ላይ ያስቀምጠዋል. ለዚህ ርዕስ የተመዘገቡ ሌሎች የመተግበሪያ አንጓዎች ክስተቱን ተቀብለው ያስተናግዳሉ።
• የክላስተር መቆለፊያዎች. ለምሳሌ፣ ውይይትን በልዩ ቁልፍ እንፈጥራለን (ውይይት-ነጠላ በ 1C መሠረት ማዕቀፍ)፡-

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

ቻናል እንደሌለ አረጋግጠናል። መቆለፊያውን ወስደዋል, እንደገና ፈትሸው, ፈጠሩት. መቆለፊያውን ከወሰዱ በኋላ ካላረጋገጡ, በዚያን ጊዜ ሌላ ክር የመፈተሽ እድል አለ እና አሁን ተመሳሳይ ውይይት ለመፍጠር ይሞክራል - እና አስቀድሞም አለ. በተመሳሰለ ወይም በመደበኛ ጃቫ መቆለፊያ በኩል መቆለፊያ ማድረግ አይቻልም። በመሠረቱ በኩል - ቀስ ብሎ, እና መሰረቱ አሳዛኝ ነው, በ Hazelcast በኩል - የሚፈልጉትን.

ዲቢኤምኤስ መምረጥ

ከ PostgreSQL ጋር ሰፊ እና የተሳካ ልምድ አለን እና ከዚህ DBMS ገንቢዎች ጋር በመተባበር።

በክላስተር፣ PostgreSQL ቀላል አይደለም - አለ። XL, XC, Citusነገር ግን፣ በአጠቃላይ፣ ከሳጥኑ ውስጥ የሚለካው noSQL አይደለም። NoSQL እንደ ዋና ማከማቻ ተደርጎ አልተወሰደም, ከዚህ በፊት ያልሰራነውን Hazelcast ን መውሰድ በቂ ነበር.

ተዛማጅ ዳታቤዝ ማመጣጠን ስለሚያስፈልግ፣ ማለት ነው። ሻርዲንግ. እንደምታውቁት፣ ስናጋራ፣ ዳታቤዙን ወደ ተለያዩ ክፍሎች እንከፋፍለን እያንዳንዳቸው በተለየ አገልጋይ ላይ እንዲቀመጡ እናደርጋለን።

የመጀመሪያው የሻርዲንግ እትማችን እያንዳንዱን የመተግበሪያችን ሰንጠረዦች በተለያየ መጠን ወደተለያዩ አገልጋዮች የማሰራጨት ችሎታ አስቦ ነበር። በአገልጋይ ሀ ላይ ብዙ መልእክት - እባኮትን የዚህን ሰንጠረዥ የተወሰነ ክፍል ወደ አገልጋይ B እናንቀሳቅስ። ይህ ውሳኔ ያለጊዜው ስለማሻሻል ብቻ ይጮሃል፣ ስለዚህ እራሳችንን በብዙ ተከራይ መንገድ ለመገደብ ወሰንን።

ስለ ብዙ ተከራይ ለምሳሌ በድር ጣቢያው ላይ ማንበብ ይችላሉ Citus ውሂብ.

በ SV ውስጥ የመተግበሪያው እና የደንበኝነት ተመዝጋቢው ጽንሰ-ሐሳቦች አሉ. አፕሊኬሽን እንደ ኢአርፒ ወይም አካውንቲንግ ያሉ ከተጠቃሚዎቹ እና ከንግድ ውሂቡ ጋር የተወሰነ የንግድ መተግበሪያ ጭነት ነው። ተመዝጋቢ ማለት አፕሊኬሽኑ በCB አገልጋይ የተመዘገበ ድርጅት ወይም ግለሰብ ነው። የደንበኝነት ተመዝጋቢው ብዙ አፕሊኬሽኖች ሊመዘገብ ይችላል፣ እና እነዚህ መተግበሪያዎች እርስ በእርስ መልእክት መለዋወጥ ይችላሉ። ተመዝጋቢው በእኛ ስርዓት ተከራይ ሆነ። የበርካታ ተመዝጋቢዎች መልእክቶች በአንድ አካላዊ መሠረት ውስጥ ሊገኙ ይችላሉ; አንዳንድ የደንበኝነት ተመዝጋቢዎች ብዙ ትራፊክ ማመንጨት እንደጀመሩ ከተመለከትን ወደተለየ አካላዊ ዳታቤዝ (ወይም የተለየ የውሂብ ጎታ አገልጋይ እንኳን) እንወስደዋለን።

የማዞሪያ ጠረጴዛው የሚቀመጥበት ዋና ዳታቤዝ አለን።

ዋናው ዳታቤዝ ማነቆ እንዳይሆን፣ የማዞሪያ ሰንጠረዡን (እና ሌሎች በተደጋጋሚ የሚጠየቁ መረጃዎች) በመሸጎጫው ውስጥ እናስቀምጣለን።

የደንበኝነት ተመዝጋቢው የውሂብ ጎታ ፍጥነት መቀነስ ከጀመረ, ውስጡን ወደ ክፍልፋዮች እንቆርጣለን. በሌሎች ፕሮጀክቶች ላይ ትላልቅ ጠረጴዛዎችን ለመከፋፈል, እንጠቀማለን pg_pathman.

የተጠቃሚ መልዕክቶችን ማጣት መጥፎ ስለሆነ የውሂብ ጎታዎቻችንን ቅጂዎች እናስቀምጠዋለን። የተመሳሰለ እና ያልተመሳሰሉ ቅጂዎች ጥምረት ዋናውን የውሂብ ጎታ መጥፋት ዋስትና እንዲሰጡ ያስችልዎታል። የመልእክት መጥፋት የሚከሰተው በአንድ ጊዜ የዋናው ዳታቤዝ ውድቀት እና የተመሳሰለ ቅጂው ሲከሰት ብቻ ነው።

የተመሳሰለው ቅጂ ከጠፋ፣ ያልተመሳሰለው ቅጂ ይመሳሰላል።
ዋናው ዳታቤዝ ከጠፋ፣ የተመሳሰለው ቅጂ ዋናው የውሂብ ጎታ ይሆናል፣ ያልተመሳሰለው ቅጂ የተመሳሰለ ቅጂ ይሆናል።

ለፍለጋ Elasticsearch

ከሌሎች ነገሮች በተጨማሪ, CB እንዲሁ መልእክተኛ ስለሆነ, እዚህ ፈጣን, ምቹ እና ተለዋዋጭ ፍለጋ እንፈልጋለን, ሞርፎሎጂን ከግምት ውስጥ በማስገባት ትክክለኛ ያልሆኑ ግጥሚያዎች. መንኮራኩሩን እንደገና ላለመፍጠር ወስነናል እና በቤተ-መጽሐፍት መሠረት የተፈጠረውን ነፃ የElasticsearch የፍለጋ ፕሮግራም ሉሲኔ. እንዲሁም የመተግበሪያ ኖዶች ብልሽት ሲያጋጥም ችግሮችን ለማስወገድ Elasticsearchን በክላስተር (ማስተር - ዳታ - ዳታ) እናሰማራለን።

በ github ላይ አግኝተናል የሩሲያ ሞርፎሎጂ ተሰኪ ለ Elasticsearch እና ይጠቀሙበት. በ Elasticsearch ኢንዴክስ ውስጥ የቃላት ስሮች (ፕለጊኑ የሚገልጸው) እና ኤን-ግራም እናከማቻለን. ተጠቃሚው ለመፈለግ ጽሑፍ ሲያስገባ፣ የተተየበው ጽሑፍ በN-grams መካከል እንፈልጋለን። ወደ መረጃ ጠቋሚው ሲቀመጥ “ጽሁፎች” የሚለው ቃል በሚከተለው ኤን-ግራም ይከፈላል፡

[te፣ ቴክ፣ ቴክስት፣ ጽሑፍ፣ ጽሑፎች፣ ek, eks, ext, exts, ks, kst, ksty, st, sty, you]

እና ደግሞ "ጽሑፍ" የሚለው ቃል ሥር ይድናል. ይህ አቀራረብ በመጀመሪያ, በመሃል እና በቃሉ መጨረሻ ላይ ለመፈለግ ያስችልዎታል.

አጠቃላይ ፎቶ

ከአንቀጹ መጀመሪያ ጀምሮ ምስሉን መድገም ፣ ግን ከማብራሪያዎች ጋር-

• ከበይነመረቡ ጋር የተጋለጠ ሚዛን; nginx አለን, ማንኛውም ሊሆን ይችላል.
• የጃቫ አፕሊኬሽን ጉዳዮች በ Hazelcast በኩል ይገናኛሉ።
• ከድር ሶኬት ጋር ለመስራት, እንጠቀማለን ኔቲ.
• በጃቫ 8 የተፃፈ የጃቫ አፕሊኬሽን ጥቅሎችን ያቀፈ ነው። ኦኤስጂ. እቅዶቹ ወደ ጃቫ 10 መሰደድ እና ወደ ሞጁሎች መቀየር ናቸው።

ልማት እና ሙከራ

የ CB ልማት እና ሙከራ ወቅት, እኛ የምንጠቀመው ምርቶች በርካታ አስደሳች ባህሪያት አጋጥሞታል.

የመጫን ሙከራ እና የማስታወስ ፍሳሾች

የእያንዳንዱ ሲቢ ልቀት መለቀቅ የጭነት ሙከራ ነው። በተሳካ ሁኔታ አልፏል፡-

• ፈተናው ለብዙ ቀናት ሰርቷል እና ምንም የአገልግሎት ውድቀቶች አልነበሩም
• ለቁልፍ ስራዎች የምላሽ ጊዜ ከምቾት ገደብ አልበለጠም።
• ከቀዳሚው ስሪት ጋር ሲነፃፀር የአፈጻጸም መበስበስ ከ 10% አይበልጥም.

የሙከራ ዳታቤዙን በውሂብ እንሞላለን - ለዚህም በጣም ንቁ የደንበኝነት ተመዝጋቢ መረጃን ከምርት አገልጋዩ እናገኛለን ፣ ቁጥሮቹን በ 5 (የመልእክት ፣ የውይይት ብዛት ፣ የተጠቃሚዎች ብዛት) እናባዛለን እና እንሞክራለን።

የግንኙነት ስርዓቱን ጭነት በሦስት አወቃቀሮች እናከናውናለን-

1. የጭንቀት ፈተና
2. ግንኙነቶች ብቻ
3. የደንበኝነት ምዝገባ

በጭንቀት ፈተና ወቅት, ብዙ መቶ ክሮች እንጀምራለን, እና ስርዓቱን ሳያቋርጡ ይጭናሉ: መልዕክቶችን ይፃፉ, ውይይቶችን ይፍጠሩ, የመልእክቶችን ዝርዝር ይቀበሉ. የተራ ተጠቃሚዎችን ድርጊት እናስመስላለን (ያልተነበቡ መልእክቶቼን ዝርዝር አግኝ፣ ለአንድ ሰው ጻፍ) እና የፕሮግራም ውሳኔዎችን (ጥቅል ወደ ሌላ ውቅር ያስተላልፉ፣ ማንቂያ እንሰራለን)።

ለምሳሌ፣ የጭንቀት ፈተናው ክፍል ይህን ይመስላል፡-

• ተጠቃሚ ገብቷል።
  • ያልተነበቡ ክሮችዎን ይጠይቃል
  • መልዕክቶችን ለማንበብ 50% ዕድል
  • መልዕክቶችን የመፃፍ 50% ዕድል
  • ቀጣይ ተጠቃሚ፡-
    • አዲስ ክር ለመፍጠር 20% ዕድል
    • ማንኛውንም ውይይቶቹን በዘፈቀደ ይመርጣል
    • ወደ ውስጥ ይገባል
    • መልዕክቶችን፣ የተጠቃሚ መገለጫዎችን ይጠይቃል
    • ከዚህ ተከታታይ ለነሲብ ተጠቃሚዎች የሚላኩ አምስት መልዕክቶችን ይፈጥራል
    • ከውይይት ውጪ
    • 20 ጊዜ ይደግማል
    • ዘግቶ ወጥቷል፣ ወደ ስክሪፕቱ መጀመሪያ ይመለሳል

  • አንድ ቻትቦት ወደ ስርዓቱ ይገባል (ከተተገበሩ መፍትሄዎች ኮድ መልእክት መላላኪያን ያሳያል)
    • አዲስ የውሂብ ቻናል ለመፍጠር 50% ዕድል (ልዩ ውይይት)
    • በማናቸውም ነባር ቻናሎች መልእክት ለመፃፍ 50% ዕድል

የ"ግንኙነቶች ብቻ" ትዕይንት በምክንያት ታየ። አንድ ሁኔታ አለ: ተጠቃሚዎች ስርዓቱን ያገናኙ, ግን እስካሁን አልተሳተፉም. እያንዳንዱ ተጠቃሚ በጠዋቱ 09፡00 ኮምፒዩተሩን ያበራ፣ ከአገልጋዩ ጋር ግንኙነት ይፈጥራል እና ዝም ይላል። እነዚህ ሰዎች አደገኛ ናቸው, ብዙዎቹም አሉ - ከፓኬቶች ውስጥ ፒንግ / PONG ብቻ አላቸው, ግን ከአገልጋዩ ጋር ያለውን ግንኙነት ያስቀምጣሉ (ማቆየት አይችሉም - እና በድንገት አዲስ መልእክት). ብዙ ቁጥር ያላቸው እንደዚህ ያሉ ተጠቃሚዎች በግማሽ ሰዓት ውስጥ ወደ ስርዓቱ ለመግባት ሲሞክሩ ፈተናው ሁኔታውን እንደገና ያባዛል. የጭንቀት ፈተና ይመስላል, ነገር ግን ትኩረቱ በትክክል በዚህ የመጀመሪያ ግቤት ላይ ነው - ምንም ውድቀቶች እንዳይኖሩ (አንድ ሰው ስርዓቱን አይጠቀምም, ግን ቀድሞውኑ እየወደቀ ነው - የከፋ ነገር ለማምጣት አስቸጋሪ ነው).

የደንበኝነት ተመዝጋቢው ምዝገባ ሁኔታ ከመጀመሪያው ጅምር ይጀምራል። የጭንቀት ፈተናን አደረግን እና ስርዓቱ በደብዳቤዎች ውስጥ እንደማይቀንስ እርግጠኛ ነበርን። ግን ተጠቃሚዎች ሄደዋል እና ምዝገባው በጊዜ ማብቂያ መውደቅ ጀመረ። ስንመዘግብ እንጠቀም ነበር። / dev / በዘፈቀደ, ከስርአቱ ኢንትሮፒ ጋር የተያያዘ. አገልጋዩ በቂ ኢንትሮፒን ለመሰብሰብ ጊዜ አልነበረውም እና አዲስ ሴኪዩር ራንደም ሲጠየቅ ለአስር ሰኮንዶች ቀዘቀዘ። በዚህ ሁኔታ ውስጥ ብዙ መንገዶች አሉ, ለምሳሌ: ወደ ያነሰ አስተማማኝ / dev / urandom ይቀይሩ, ኢንትሮፒን የሚያመነጭ ልዩ ሰሌዳ ይጫኑ, የዘፈቀደ ቁጥሮችን አስቀድመው ያመነጩ እና በገንዳ ውስጥ ያስቀምጧቸው. ችግሩን ለጊዜው ከገንዳው ጋር ዘግተናል፣ ነገር ግን ከዚያን ጊዜ ጀምሮ አዲስ ተመዝጋቢዎችን ለመመዝገብ የተለየ ሙከራ እያካሄድን ነው።

እንደ ጭነት ማመንጫ እንጠቀማለን ጄሜተር. ከዌብሶኬት ጋር እንዴት እንደሚሰራ አያውቅም, ተሰኪ ያስፈልጋል. ለጥያቄው "jmeter websocket" በፍለጋ ውጤቶቹ ውስጥ የመጀመሪያው ናቸው። BlazeMeter ጋር ጽሑፎችእነሱ የሚመክሩበት ተሰኪ በ Maciej Zaleski.

ለመጀመር የወሰንነው እዚያ ነው።

ከባድ ምርመራ ከተጀመረ በኋላ ወዲያውኑ የማስታወስ ችሎታ መፍሰስ በጄሜትሮች መጀመሩን ደርሰንበታል።

ፕለጊኑ የተለየ ትልቅ ታሪክ ነው፣ 176 ኮከቦች ያሉት በ github ላይ 132 ሹካዎች አሉት። ደራሲው እ.ኤ.አ. ከ 2015 ጀምሮ (እ.ኤ.አ. በ 2015 ወስደነዋል ፣ ከዚያ ጥርጣሬን አላስነሳም) ፣ ስለ ማህደረ ትውስታ መፍሰስ ብዙ የጊትዩብ ጉዳዮች ፣ 7 ያልተዘጋ የመሳብ ጥያቄዎች ።
በዚህ ተሰኪ ሙከራን ለመጫን ከመረጡ፣ እባክዎ የሚከተሉትን ውይይቶች ያስተውሉ፡

1. ባለብዙ-ክር አካባቢ, መደበኛ LinkedList ጥቅም ላይ ውሏል, በውጤቱም, አገኘን NPE በሂደት ላይ የሚፈታው ወደ ConcurrentLinkedDeque በመቀየር ወይም በተመሳሰሉ ብሎኮች ነው። የመጀመሪያውን አማራጭ ለራሳችን መርጠናልhttps://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. የማህደረ ትውስታ መፍሰስ፣ ግንኙነት ሲቋረጥ የግንኙነት መረጃ አይሰረዝም (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. በዥረት ሁነታ (ዌብሶኬት በናሙናው መጨረሻ ላይ ካልተዘጋ ነገር ግን በእቅዱ ውስጥ የበለጠ ጥቅም ላይ ሲውል) የምላሽ ቅጦች አይሰሩም (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

ይህ github ላይ ካሉት አንዱ ነው። ያደረግነው፡-

1. ወስደዋል የኤሊራን ኮጋን ሹካ (@elyrank) - ጉዳዮችን 1 እና 3 ያስተካክላል
2. ችግር ተፈቷል 2
3. ከ 9.2.14 ወደ 9.3.12 የተሻሻለ ጄቲ
4. የተጠቀለለ SimpleDate ፎርማት በ ThreadLocal; SimpleDateFormat በሂደት ጊዜ ወደ NPE የሚያደርስ ደህንነቱ የተጠበቀ ክር አይደለም።
5. ሌላ የማህደረ ትውስታ ፍሰት ተስተካክሏል (ግንኙነቱ ሲቋረጥ በስህተት ተዘግቷል)

እና አሁንም ይፈስሳል!

ትውስታ ማለቅ የጀመረው በአንድ ቀን ሳይሆን በሁለት ነው። ምንም ጊዜ አልነበረም, ጥቂት ክሮች ለማሄድ ወስነናል, ነገር ግን በአራት ወኪሎች ላይ. ይህ ቢያንስ ለአንድ ሳምንት በቂ መሆን ነበረበት.

ሁለት ቀን ሆኖታል...

አሁን Hazelcast የማስታወስ ችሎታ እያለቀ ነው። ምዝግብ ማስታወሻዎቹ እንደሚያሳዩት ከተወሰኑ ቀናት ሙከራ በኋላ ሃዘልካስት በማስታወስ እጥረት ማጉረምረም ጀመረ እና ከጥቂት ጊዜ በኋላ ክላስተር ተለያይቷል እና አንጓዎቹ አንድ በአንድ መሞታቸውን ቀጥለዋል። JVisualVMን ከ hazelcast ጋር አገናኘን እና “ወደ ላይ ያለውን መጋዝ” አየን - በመደበኛነት ጂሲ ይባላል ፣ ግን ማህደረ ትውስታውን በምንም መንገድ ማጽዳት አልቻለም።

በ hazelcast 3.4 ውስጥ ካርታ / መልቲ ካርታ (map.destroy ()) ሲሰርዝ ማህደረ ትውስታው ሙሉ በሙሉ አልተለቀቀም.

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

ስህተቱ አሁን በ3.5 ተስተካክሏል፣ ነገር ግን ያኔ ችግር ነበር። አዲስ መልቲ ካርታ በተለዋዋጭ ስሞች ፈጠርን እና እንደ አመክንዮአችን ተሰርዘናል። ኮዱ ይህን ይመስላል።

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

Выzov:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

መልቲ ካርታ ለእያንዳንዱ የደንበኝነት ምዝገባ ተፈጠረ እና በማይፈለግበት ጊዜ ተወግዷል። ካርታ ለመጀመር ወሰንን ቁልፉ የደንበኝነት ምዝገባው ስም ይሆናል, እና እሴቶቹ የክፍለ ጊዜ መለያዎች ይሆናሉ (በዚህም አስፈላጊ ከሆነ የተጠቃሚ መለያዎችን ማግኘት ይችላሉ).

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

ሰንጠረዦቹ ተሻሽለዋል።

ስለ ጭነት ሙከራ ሌላ ምን ተማርን።

1. JSR223 በጉሮሮ ውስጥ መፃፍ እና የተቀነባበረ መሸጎጫ ማካተት አለበት - በጣም ፈጣን ነው። ማያያዣ.
2. Jmeter-Plugins ገበታዎች ከመደበኛው ለመረዳት ቀላል ናቸው። ማያያዣ.

ስለ Hazelcast ያለን ልምድ

Hazelcast ለእኛ አዲስ ምርት ነበር፣ ከእሱ ጋር ከስሪት 3.4.1 ጋር መስራት ጀመርን፣ አሁን በአምራች አገልጋያችን ላይ ስሪት 3.9.2 አለን።

መታወቂያ ማመንጨት

በኢንቲጀር መለያዎች ጀመርን። ለአዲስ አካል ሌላ ረጅም እንደሚያስፈልገን እናስብ። በመረጃ ቋቱ ውስጥ ያለው ቅደም ተከተል ተስማሚ አይደለም ፣ ሰንጠረዦች በሻርዲንግ ውስጥ ይሳተፋሉ - በዲቢ1 ውስጥ የመልእክት መታወቂያ = 1 እና በ DB1 ውስጥ የመልእክት መታወቂያ = 2 እንዳለ ፣ ይህንን መታወቂያ በ Elasticsearch ፣ በ Hazelcast ውስጥም ማድረግ አይችሉም ፣ ግን በጣም መጥፎው ነገር መረጃን ከሁለት የውሂብ ጎታዎች ወደ አንድ መቀነስ ከፈለጉ (ለምሳሌ አንድ የውሂብ ጎታ ለእነዚህ ተመዝጋቢዎች በቂ መሆኑን መወሰን) ነው። በ Hazelcast ውስጥ ብዙ AtomicLongs ሊኖርዎት እና ቆጣሪውን እዚያው ማቆየት ይችላሉ፣ ከዚያ አዲስ መታወቂያ የማግኘት አፈጻጸም ይጨምራልእና በ Hazelcast ውስጥ ለመጠየቅ ጊዜ ያግኙ። ግን Hazelcast የበለጠ ጥሩ ነገር አለው - FlakeIdGenerator። በሚገናኙበት ጊዜ እያንዳንዱ ደንበኛ የተለያዩ መታወቂያዎችን ይሰጣል ፣ ለምሳሌ ፣ የመጀመሪያው - ከ 1 እስከ 10 ፣ ሁለተኛው - ከ 000 እስከ 10 ፣ ወዘተ. አሁን ደንበኛው የተሰጠው ክልል እስኪያልቅ ድረስ አዲስ መለያዎችን በራሱ መስጠት ይችላል። በፍጥነት ይሰራል፣ ነገር ግን መተግበሪያውን እንደገና ማስጀመር (እና የ Hazelcast ደንበኛ) አዲስ ቅደም ተከተል ይጀምራል - ስለዚህ መዝለሎቹ ፣ ወዘተ. በተጨማሪም፣ መታወቂያዎች ለምን ኢንቲጀር እንደሆኑ ለገንቢዎች በጣም ግልፅ አይደለም፣ ነገር ግን በጣም የሚጋጩ ናቸው። ሁሉንም ነገር በመመዘን ወደ UUIDs ቀይረናል።

በነገራችን ላይ, እንደ ትዊተር ለመሆን ለሚፈልጉ, እንደዚህ ያለ የበረዶ ላይብረሪ አለ - ይህ በ Hazelcast አናት ላይ የበረዶ ቅንጣት አተገባበር ነው. እዚህ ማየት ይችላሉ፡

github.com/noctarius/snowcast
github.com/twitter/snowflake

ግን እስካሁን አልደረስንበትም።

TransactionalMap.ተካ

ሌላ አስገራሚ ነገር፡ TransactionalMap.replace አይሰራም። ፈተና ይህ ነው፡-

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

getForUpdateን በመጠቀም የራሴን ምትክ መጻፍ ነበረብኝ፡-

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

መደበኛ የውሂብ አወቃቀሮችን ብቻ ሳይሆን የግብይት ስሪቶቻቸውንም ይሞክሩ። IMap ሲሰራ ይከሰታል፣ ግን TransactionalMap ከአሁን በኋላ የለም።

ያለእረፍት ጊዜ አዲስ JAR ያያይዙ

በመጀመሪያ፣ የክፍሎቻችንን እቃዎች ለሃዘልካስት ለመፃፍ ወሰንን። ለምሳሌ፣ የአፕሊኬሽን ክፍል አለን፣ ማከማቸት እና ማንበብ እንፈልጋለን። አስቀምጥ፡

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

ለምሳሌ፡

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

ሁሉም ነገር እየሰራ ነው። ከዚያ እሱን ለመፈለግ በ Hazelcast ውስጥ ኢንዴክስ ለመገንባት ወሰንን-

map.addIndex("subscriberId", false);

እና አዲስ አካል ሲጽፉ፣ ClassNotFoundException መቀበል ጀመሩ። Hazelcast ወደ መረጃ ጠቋሚው ለመጨመር ሞክሯል፣ ነገር ግን ስለ ክፍላችን ምንም የሚያውቀው ነገር የለም እና ከዚህ ክፍል ጋር JAR ማስቀመጥ ፈለገ። እኛ ያንን አደረግን ፣ ሁሉም ነገር ሠርቷል ፣ ግን አዲስ ችግር ታየ - ክላስተርን ሙሉ በሙሉ ሳያቆሙ JAR ን እንዴት ማዘመን እንደሚቻል? Hazelcast በእያንዳንዱ መስቀለኛ መንገድ ዝማኔ ላይ አዲስ JAR አያነሳም። በዚህ ጊዜ, ያለ ጠቋሚ ፍለጋዎች መኖር እንደምንችል ወሰንን. ደግሞም Hazelcast ን እንደ ቁልፍ እሴት መደብር ከተጠቀሙ ሁሉም ነገር ይሰራል? እውነታ አይደለም. እዚህ እንደገና የተለየ የIMAp እና የግብይት ካርታ ባህሪ። IMap ግድ በሌለው ቦታ፣ TransactionalMap ስህተት ይጥላል።

አይማፕ 5000 እቃዎችን እንጽፋለን, እናነባለን. ሁሉም ነገር ይጠበቃል.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

ነገር ግን በግብይት ውስጥ አይሰራም፣ ClassNotFoundException እናገኛለን፡-

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

በ 3.8 ውስጥ የተጠቃሚ ክፍል መዘርጋት ዘዴ ታየ። አንድ ዋና ኖድ መሰየም እና የJAR ፋይልን በእሱ ላይ ማዘመን ይችላሉ።

አሁን አካሄዳችንን ሙሉ ለሙሉ ቀይረነዋል፡ እኛ እራሳችን በተከታታይ ወደ JSON እና ወደ Hazelcast ቆጥበዋል። Hazelcast የክፍሎቻችንን መዋቅር ማወቅ አያስፈልገውም፣ እና ያለማቋረጥ ማዘመን እንችላለን። የጎራ ዕቃዎች ሥሪት በመተግበሪያው ቁጥጥር ይደረግበታል። የተለያዩ የመተግበሪያው ስሪቶች በተመሳሳይ ጊዜ ሊከፈቱ ይችላሉ, እና አዲስ መተግበሪያ እቃዎችን በአዲስ መስኮች ሊጽፍ ይችላል, አሮጌው ስለእነዚህ መስኮች እስካሁን አያውቅም. እና በተመሳሳይ ጊዜ, አዲሱ አፕሊኬሽኑ አዲስ መስኮች የሌላቸው በአሮጌው መተግበሪያ የተፃፉትን ነገሮች ያነባል. በመተግበሪያው ውስጥ እንደዚህ ያሉ ሁኔታዎችን እንይዛለን, ነገር ግን ለቀላልነት እኛ መስኮችን አንቀይርም ወይም አናስወግድም, አዳዲስ መስኮችን በመጨመር ክፍሎችን ብቻ እናራዝማለን.

ከፍተኛ አፈፃፀምን እንዴት እንደምናቀርብ

ወደ Hazelcast አራት ጉዞዎች ጥሩ ነው፣ ወደ ዳታቤዝ ሁለት ጉዞዎች መጥፎ ናቸው።

በመሸጎጫው ውስጥ ውሂብ መፈለግ ሁልጊዜ ከመረጃ ቋቱ የተሻለ ነው, ነገር ግን ያልተጠየቁ መዝገቦችን ማከማቸት አይፈልጉም. ምን መሸጎጫ እንዳለ መወሰን እስከ መጨረሻው የእድገት ደረጃ ይቀራል። አዲሱ ተግባር ኮድ ሲደረግ፣ ሁሉንም ጥያቄዎች በPostgreSQL (log_min_duration_statement to 0) ውስጥ መግባትን እናነቃለን እና የጭነት ሙከራን ለ20 ደቂቃዎች እናካሂዳለን። እንደ pgFouine እና pgBadger ያሉ መገልገያዎች በተሰበሰቡ ምዝግብ ማስታወሻዎች ላይ በመመስረት ትንታኔያዊ ሪፖርቶችን መገንባት ይችላሉ። በሪፖርቶች ውስጥ በዋናነት ቀርፋፋ እና ተደጋጋሚ ጥያቄዎችን እንፈልጋለን። ለዝግተኛ መጠይቆች፣ የማስፈጸሚያ እቅድ (ማብራራት) እንገነባለን እና እንደዚህ አይነት መጠይቅ መፋጠን ይቻል እንደሆነ እንገመግማለን። ለተመሳሳይ ግቤት ተደጋጋሚ ጥያቄዎች ወደ መሸጎጫው በሚገባ ይስማማሉ። መጠይቆችን "ጠፍጣፋ" ለማቆየት እንሞክራለን, በአንድ መጠይቅ አንድ ጠረጴዛ.

ክዋኔ

የተለየ የCB ምርት በኖቬምበር 2017 (በዚያን ጊዜ በቅድመ-ይሁንታ ስሪት) ስለተለቀቀ CB እንደ የመስመር ላይ አገልግሎት በ 2017 ጸደይ ተጀመረ።

ከአንድ አመት በላይ በሚሰራበት ጊዜ, በ CB የመስመር ላይ አገልግሎት ውስጥ ምንም አይነት ከባድ ችግሮች አልነበሩም. በመስመር ላይ አገልግሎቱን እንከታተላለን ዚብሊክስ, መሰብሰብ እና ማሰማራት ከ ሸምበቆ.

የ CB አገልጋይ ስርጭቱ በአገርኛ ጥቅሎች መልክ ይመጣል፡ RPM፣ DEB፣ MSI። በተጨማሪም፣ ለዊንዶውስ፣ አገልጋዩን፣ Hazelcast እና Elasticsearchን በአንድ ማሽን ላይ የሚጭን ነጠላ ጫኝን በአንድ EXE መልክ እናቀርባለን። በመጀመሪያ ይህንን የመጫኛ እትም "demo" ብለን እንጠራዋለን, አሁን ግን ይህ በጣም ታዋቂው የማሰማራት አማራጭ እንደሆነ ግልጽ ሆኗል.

ምንጭ: hab.com