Сайн уу? Намайг Алексей Пянков гэдэг, би Sportmaster компанийн хөгжүүлэгч. Тэр нь Би 2012 онд Sportmaster вэб сайтын ажил хэрхэн эхэлсэн, бид ямар санаачилга дэвшүүлж, эсрэгээр нь ямар тармуур цуглуулсан талаар хэлсэн.
Өнөөдөр би өөр сэдвийг дагаж буй бодлоо хуваалцахыг хүсч байна - сайтын админ хэсэгт java backend-д зориулсан кэшийн системийг сонгох. Энэ үйл явдал миний хувьд онцгой утга учиртай - түүх ердөө 2 сарын хугацаанд өрнөсөн ч энэ 60 хоногийн хугацаанд бид 12-16 цаг ажиллаж, нэг ч өдөр ч амралтгүй ажилласан. Ийм шаргуу ажиллах боломжтой гэж би хэзээ ч бодож байгаагүй, төсөөлж ч байгаагүй.
Тиймээс би текстийг бүрэн ачаалахгүйн тулд 2 хэсэгт хуваасан. Эсрэгээр, эхний хэсэг нь маш хөнгөн байх болно - бэлтгэл, танилцуулга, кэш гэж юу болох талаар зарим анхаарах зүйлс. Хэрэв та аль хэдийн туршлагатай хөгжүүлэгч эсвэл кэштэй ажиллаж байсан бол техникийн талаасаа энэ нийтлэлд шинэ зүйл байхгүй байх магадлалтай. Харин бага насны хүүхдийн хувьд ийм жижиг тойм нь ийм уулзварт орвол аль зүг рүү харахыг хэлж чадна.
Sportmaster вэб сайтын шинэ хувилбарыг үйлдвэрлэлд оруулахад мэдээллийг бага зэрэг хэлэхэд тийм ч тохиромжтой биш байдлаар хүлээн авсан. Үүний үндэс нь сайтын өмнөх хувилбарт (Bitrix) зориулж бэлтгэсэн хүснэгтүүд байсан бөгөөд үүнийг ETL-д татаж, шинэ хэлбэрт оруулж, олон арван системээс янз бүрийн жижиг зүйлээр баяжуулах шаардлагатай байв. Сайт дээр шинэ зураг эсвэл бүтээгдэхүүний тайлбар гарч ирэхийн тулд та дараагийн өдөр хүртэл хүлээх хэрэгтэй болсон - зөвхөн шөнийн цагаар, өдөрт нэг удаа шинэчлэгддэг.
Эхэндээ, үйлдвэрлэлд орсон эхний долоо хоногоос маш их санаа зовдог байсан тул агуулгын менежерүүдэд ийм төвөг учруулах нь өчүүхэн зүйл байв. Гэхдээ бүх зүйл шийдэгдмэгц төслийн хөгжил үргэлжилсээр - хэдэн сарын дараа, 2015 оны эхээр бид админ самбарыг идэвхтэй хөгжүүлж эхэлсэн. 2015, 2016 онд бүх зүйл сайхан болж байна, бид тогтмол гаргадаг, админ самбар нь өгөгдөл бэлтгэх илүү олон ажлыг хамардаг бөгөөд удахгүй манай багт хамгийн чухал бөгөөд төвөгтэй зүйл болох бүтээгдэхүүнийг даатгах болно гэдэгт бэлдэж байна. хэлхээ (бүх бүтээгдэхүүний мэдээллийг бүрэн бэлтгэх, засвар үйлчилгээ). Гэвч 2017 оны зун, түүхий эдийн хэлхээг эхлүүлэхийн өмнөхөн төсөл нь кэштэй холбоотой асуудлаас болж маш хүнд байдалд орох болно. Би энэ хоёр хэсэгтэй нийтлэлийн хоёрдугаар хэсэгт энэ ангийн талаар ярихыг хүсч байна.
Гэхдээ энэ нийтлэлд би алсаас эхлэх болно, би зарим нэг бодлыг танилцуулах болно - кэш хийх талаархи санаанууд нь томоохон төслийн өмнө гүйлгэх сайн алхам болно.
Кэш хийх ажил гарах үед
Кэш хийх ажил зүгээр л гарч ирдэггүй. Бид хөгжүүлэгчид, програм хангамжийн бүтээгдэхүүн бичиж, эрэлт хэрэгцээтэй байгаасай гэж хүсдэг. Бүтээгдэхүүн нь эрэлт хэрэгцээтэй, амжилттай байвал хэрэглэгчид ирнэ. Мөн илүү их ирдэг. Тэгээд дараа нь маш олон хэрэглэгчид байдаг бөгөөд дараа нь бүтээгдэхүүн маш их ачаалалтай болдог.
Эхний үе шатанд бид оновчлол, кодын гүйцэтгэлийн талаар боддоггүй. Хамгийн гол нь функциональ байдал, нисгэгчийг хурдан гаргаж, таамаглалыг турших явдал юм. Хэрэв ачаалал нэмэгдвэл бид төмрийг шахдаг. Бид хоёр гурав дахин, тав дахин, магадгүй 10 дахин нэмэгддэг. Энд хаа нэгтээ - санхүү үүнийг цаашид зөвшөөрөхгүй. Хэрэглэгчдийн тоо хэд дахин нэмэгдэх вэ? Энэ нь 2-5-10 шиг биш, амжилттай бол 100-1000-аас 100 мянган дахин их байх болно. Өөрөөр хэлбэл, эрт орой хэзээ нэгэн цагт та оновчлол хийх хэрэгтэй болно.
Кодын зарим хэсэг (энэ хэсгийг функц гэж нэрлэе) зохисгүй урт хугацаа шаарддаг тул гүйцэтгэлийн хугацааг багасгахыг хүсч байна гэж бодъё. Функц нь өгөгдлийн санд хандах эсвэл ямар нэгэн нарийн төвөгтэй логикийн гүйцэтгэл байж болно - гол зүйл нь үүнийг дуусгахад удаан хугацаа шаардагддаг. Гүйцэтгэлийн хугацааг хэр багасгаж чадах вэ? Хязгаарт та үүнийг тэг болгож бууруулж болно, цаашилдаггүй. Гүйцэтгэлийн хугацааг хэрхэн тэг болгож бууруулах вэ? Хариулт: гүйцэтгэлийг бүрмөсөн арилгах. Үүний оронд үр дүнг нэн даруй буцааж өгнө үү. Үр дүнг хэрхэн олж мэдэх вэ? Хариулт: нэг бол тооцоол, эсвэл хаа нэгтээ хай. Тооцоолоход нэлээд хугацаа шаардагддаг. Мөн тагнуул гэдэг нь жишээлбэл, ижил параметрээр дуудагдсан функц хамгийн сүүлд гарсан үр дүнг санах явдал юм.
Өөрөөр хэлбэл, функцийг хэрэгжүүлэх нь бидэнд чухал биш юм. Үр дүн нь ямар параметрээс хамаарч байгааг мэдэхэд л хангалттай. Дараа нь параметрийн утгууд нь зарим санах ойд түлхүүр болгон ашиглаж болох объект хэлбэрээр дүрслэгдсэн бол тооцооллын үр дүнг хадгалж, дараагийн удаа хандах үед уншиж болно. Хэрэв энэ үр дүнг бичих, унших нь функцийг гүйцэтгэхээс илүү хурдан байвал бид хурдны хувьд ашигтай байна. Ашгийн хэмжээ 100, 1000, 100 мянгад хүрч болно (10^5 нь үл хамаарах зүйл боловч нэлээд хоцрогдсон суурьтай тохиолдолд энэ нь бүрэн боломжтой).
Кэшийн системд тавигдах үндсэн шаардлага
Кэшийн системд тавигдах хамгийн эхний зүйл бол хурдан унших хурд, бага зэрэг бичих хурд юм. Энэ нь үнэн, гэхдээ бид системийг үйлдвэрлэлд нэвтрүүлэх хүртэл л.
Энэ хэргийг тоглоцгооё.
Бид одоогийн ачааллыг техник хангамжаар хангаж, кэшийг аажмаар нэвтрүүлж байна гэж бодъё. Хэрэглэгчдийн тоо бага зэрэг нэмэгдэж, ачаалал нэмэгддэг - бид бага зэрэг кэш нэмж, энд тэнд шургуулдаг. Энэ нь хэсэг хугацаанд үргэлжилж байгаа бөгөөд одоо хүнд функцууд бараг дуудагдахаа больсон - үндсэн ачаалал бүхэлдээ кэш дээр унадаг. Энэ хугацаанд хэрэглэгчдийн тоо N дахин нэмэгджээ.
Хэрэв техник хангамжийн анхны нийлүүлэлт 2-5 дахин их байж болох юм бол кэшийн тусламжтайгаар бид гүйцэтгэлийг 10 дахин эсвэл сайн тохиолдолд 100 дахин, зарим газарт магадгүй нэг хүчин зүйлээр нэмэгдүүлэх боломжтой. -ийн 1000. Өөрөөр хэлбэл, ижил техник хангамж дээр бид 100 дахин илүү хүсэлтийг боловсруулдаг. Гайхалтай, та цагаан гаатай талх авах эрхтэй!
Харин одоо нэг сайхан мөчид санамсаргүй байдлаар систем эвдэрч, кэш унав. Ямар ч онцгой зүйл байхгүй - эцэст нь кэшийг "унших, бичих өндөр хурд, бусад нь хамаагүй" гэсэн шаардлагад үндэслэн сонгосон.
Гарааны ачаалалтай харьцуулахад манай төмрийн нөөц 2-5 дахин, энэ хугацаанд ачаалал 10-100 дахин нэмэгдсэн. Кэшийг ашигласнаар бид хүнд функцүүдийн дуудлагыг арилгасан тул бүх зүйл ажилласан. Одоо, кэшгүй бол манай систем хэдэн удаа удаашрах вэ? Бидэнд юу тохиолдох вэ? Систем унана.
Хэдийгээр бидний кэш гацаагүй ч хэсэг хугацаанд цэвэрлэгдсэн байсан ч үүнийг дулаацуулах шаардлагатай бөгөөд үүнд бага зэрэг хугацаа шаардагдана. Мөн энэ хугацаанд гол ачаа нь функциональ байдалд унах болно.
Дүгнэлт: Ачаалал ихтэй үйлдвэрлэлийн төслүүд нь кэшийн системийг зөвхөн унших, бичих өндөр хурдтай байхаас гадна мэдээллийн аюулгүй байдал, эвдрэлд тэсвэртэй байхыг шаарддаг.
Сонгосон гурил
Админ самбар бүхий төсөлд сонголт дараах байдалтай байсан: эхлээд бид Hazelcast суулгасан, учир нь Үндсэн сайтын туршлагаас бид энэ бүтээгдэхүүнийг аль хэдийн мэддэг байсан. Гэхдээ энд энэ сонголт амжилтгүй болсон - бидний ачааллын дагуу Hazelcast зүгээр л удаан биш, гэхдээ маш удаан байдаг. Тэр үед бид аль хэдийн гарах өдрөө бүртгүүлчихсэн байсан.
Спойлер: Бид ийм том зүйлийг алдаж, хурц, хурцадмал байдалд орсон нөхцөл байдал яг яаж бий болсныг би хоёрдугаар хэсэгт хэлье - бид хэрхэн төгсөж, яаж гарсан бэ. Гэхдээ одоо би энэ бол маш их стресс байсан гэж хэлэх болно, мөн "бодох - ямар нэг байдлаар би бодож чадахгүй байна, бид лонхыг сэгсэрч байна" гэж хэлье. "Савыг сэгсрэх нь" нь бас спойлер, дараа нь дэлгэрэнгүй.
Бидний хийсэн зүйл:
- Бид Google болон StackOverflow-ийн санал болгож буй бүх системийн жагсаалтыг гаргадаг. 30 гаруйхан настай
- Бид үйлдвэрлэлийн ердийн ачаалалтай туршилтуудыг бичдэг. Үүнийг хийхийн тулд бид үйлдвэрлэлийн орчинд системээр дамждаг өгөгдлийг бүртгэсэн бөгөөд энэ нь сүлжээнд биш, харин систем доторх өгөгдлийг олж авах нэг төрлийн мэдрэгч юм. Туршилтанд яг энэ өгөгдлийг ашигласан.
- Бүхэл бүтэн баг хамт олон хүн бүр жагсаалтаас дараагийн системийг сонгож, тохируулж, туршилтыг явуулдаг. Энэ нь шалгалтанд тэнцээгүй, ачаа үүрдэггүй - бид үүнийг хаяж, дараагийн эгнээнд шилждэг.
- 17-р систем дээр бүх зүйл найдваргүй болох нь тодорхой болов. Лонхыг сэгсрэхээ боль, нухацтай бодох цаг болжээ.
Гэхдээ энэ нь урьдчилан бэлтгэсэн тестүүд дээр "хурдыг давах" системийг сонгох шаардлагатай үед сонголт юм. Хэрэв тийм тест хараахан гараагүй байгаа бөгөөд та хурдан сонгохыг хүсч байвал яах вэ?
Энэ хувилбарыг загварчилж үзье (дунд+ хөгжүүлэгч нь вакуум орчинд амьдардаг гэж төсөөлөхөд бэрх бөгөөд сонгон шалгаруулалтын үед аль бүтээгдэхүүнийг эхлээд туршиж үзэхээ хараахан албан ёсоор хараахан хараахан хараахан амжаагүй байна. Тиймээс цаашдын үндэслэл нь онолч/философи) юм. бага насны тухай).
Шаардлагуудыг шийдсэний дараа бид хайрцагнаас шийдлийг сонгож эхэлнэ. Яагаад дугуйг дахин зохион бүтээх вэ: бид очоод бэлэн кэшийн системийг авах болно.
Хэрэв та дөнгөж эхэлж байгаа бол google-ээс хайж байгаа бол захиалга өгөх эсвэл аваарай, гэхдээ ерөнхийдөө заавар нь ийм байх болно. Юуны өмнө та Редистэй таарах болно, энэ нь хаа сайгүй сонсогддог. Дараа нь та EhCache бол хамгийн эртний бөгөөд хамгийн батлагдсан систем гэдгийг олж мэдэх болно. Дараа нь бид шийдлийн өвөрмөц талтай дотоодын бүтээн байгуулалт болох Тарантоолын талаар бичих болно. Мөн түүнчлэн Ignite, учир нь энэ нь одоо алдартай болж, SberTech-ийн дэмжлэгийг авдаг. Төгсгөлд нь Hazelcast бас байдаг, учир нь бизнесийн ертөнцөд энэ нь ихэвчлэн томоохон компаниудын дунд гарч ирдэг.
Жагсаалт нь бүрэн биш бөгөөд олон арван системүүд байдаг. Мөн бид зөвхөн нэг зүйлийг л гашилгана. "Гоо сайхны тэмцээн"-д сонгогдсон 5 системийг аваад сонголтоо хийцгээе. Хэн ялагч болох вэ?
Redis
Тэдний бичсэн зүйлийг бид албан ёсны вэбсайтаас уншдаг.
- нээлттэй эхийн төсөл. Санах ойд өгөгдөл хадгалах, дискэн дээр хадгалах, автоматаар хуваах, өндөр хүртээмжтэй байх, сүлжээний тасалдлаас сэргээх боломжийг санал болгодог.
Бүх зүйл зүгээр юм шиг санагдаж байна, та үүнийг авч, боолт хийж болно - танд хэрэгтэй бүх зүйл энэ болно. Гэхдээ зүгээр л хөгжилтэй байхын тулд бусад нэр дэвшигчдийг харцгаая.
EhCache
- "Java-д хамгийн өргөн хэрэглэгддэг кэш" (албан ёсны вэбсайтаас уриа лоозонгийн орчуулга). Мөн нээлттэй эх сурвалж. Дараа нь бид Redis нь java-д зориулагдсан биш, харин ерөнхий гэдгийг ойлгодог бөгөөд үүнтэй харилцахын тулд танд боодол хэрэгтэй болно. Мөн EhCache илүү тохиромжтой байх болно. Систем өөр юу амлаж байна вэ? Найдвартай байдал, батлагдсан, бүрэн ажиллагаатай. За, энэ нь бас хамгийн түгээмэл зүйл юм. Мөн терабайт өгөгдлийг кэш.
Редис мартагдсан, би EhCache сонгоход бэлэн байна.
Гэхдээ эх оронч үзэл намайг Тарантоолын сайн сайхныг олж мэдэхэд түлхэж байна.
Тарантуул
- "Бодит цагийн өгөгдлийг нэгтгэх платформ" гэсэн тэмдэглэгээг хангасан. Энэ нь маш төвөгтэй сонсогдож байгаа тул бид хуудсыг нарийвчлан уншиж, "RAM дахь өгөгдлийг 100% кэш болгодог" гэсэн чанга мэдэгдлийг олдог. Энэ нь асуултуудыг төрүүлэх ёстой - эцэст нь санах ойноос хамаагүй илүү өгөгдөл байж болно. Тайлбар нь Tarantool нь санах ойноос диск рүү өгөгдөл бичихийн тулд цуваажуулалтыг ажиллуулдаггүй гэсэн үг юм. Үүний оронд санах ойг маш сайн оролт гаралтын гүйцэтгэлтэй файлын системд буулгах үед системийн доод түвшний функцуудыг ашигладаг. Ерөнхийдөө тэд гайхалтай, гайхалтай зүйл хийсэн.
Хэрэгжилтийг харцгаая: Mail.ru корпорацийн хурдны зам, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Хэрэв Tarantool-ийн талаар эргэлзэж байсан хэвээр байвал Mastercard дээр хэрэгжсэн хэрэг намайг дуусгах болно. Би Tarantool авч байна.
Гэхдээ ямар ч байсан…
гал авалцаж
… өөр бас байна уу , нь "санах ой доторх тооцоолох платформ... санах ойн хурд нь петабайт өгөгдөл" гэж тооцогддог. Энд бас олон давуу тал бий: тархсан санах ойн кэш, хамгийн хурдан түлхүүр-утга хадгалах болон кэш, хэвтээ масштаб, өндөр хүртээмжтэй байдал, хатуу бүрэн бүтэн байдал. Ерөнхийдөө хамгийн хурдан нь Ignite гэдэг нь харагдаж байна.
Хэрэгжилт: Сбербанк, American Airlines, Yahoo! Япон. Тэгээд би Ignite нь зөвхөн Сбербанканд хэрэгждэггүй, харин SberTech-ийн баг бүтээгдэхүүнээ боловсронгуй болгохын тулд Ignite баг руу хүмүүсээ илгээдэг болохыг олж мэдэв. Энэ бол үнэхээр сэтгэл татам бөгөөд би Ignite-ийг авахад бэлэн байна.
Яагаад гэдэг нь бүрэн тодорхойгүй байна, би тав дахь цэгийг харж байна.
Хазелкаст
Би сайт руу очдог , унших. Түгээмэл кэш хийх хамгийн хурдан шийдэл бол Hazelcast юм. Энэ нь бусад бүх шийдлүүдээс хамаагүй хурдан бөгөөд ерөнхийдөө санах ойн мэдээллийн сүлжээний салбарт тэргүүлэгч юм. Үүний цаана өөр зүйлийг авах нь өөрийгөө хүндлэх явдал биш юм. Мөн өгөгдөл алдагдуулахгүйгээр кластерыг тасралтгүй ажиллуулахын тулд нэмэлт мэдээллийн санг ашигладаг.
Ингээд л би Hazelcast-ыг авахад бэлэн байна.
Харьцуулалт
Харин харвал таван нэр дэвшигч бүгдээрээ шилдэг нь байхаар дүрслэгдсэн байдаг. Хэрхэн сонгох вэ? Бид аль нь хамгийн алдартай болохыг харж болно, харьцуулалт хайж, толгой өвдөх болно.
Бид ийм нэгийг олдог , манай 5 системийг сонго.
Энд тэдгээрийг эрэмбэлсэн: Redis дээд талд, Hazelcast хоёрдугаарт, Tarantool болон Ignite алдартай болж байна, EhCache хэвээр байгаа бөгөөд хэвээр байна.
Гэхдээ харцгаая : вэб сайтын холбоосууд, системийн ерөнхий сонирхол, ажлын санал - гайхалтай! Өөрөөр хэлбэл, миний систем бүтэлгүйтвэл би: "Үгүй ээ, найдвартай! Маш олон ажлын санал байна..." Ийм энгийн харьцуулалт хийхгүй.
Эдгээр бүх системүүд нь зөвхөн кэшийн систем биш юм. Тэд мөн маш олон функцтэй байдаг, тухайлбал өгөгдлийг боловсруулахын тулд үйлчлүүлэгч рүү шахдаггүй, харин эсрэгээр: өгөгдөл дээр ажиллах шаардлагатай код сервер рүү шилжиж, тэнд ажиллаж, үр дүн нь буцаж ирдэг. Мөн тэдгээрийг кэш хийх тусдаа систем гэж тийм ч их үздэггүй.
За, бууж өгөхгүй, системүүдийн шууд харьцуулалтыг олъё. Редис, Хазелкаст гэсэн хоёр шилдэг сонголтыг авч үзье. Бид хурдыг сонирхож байгаа бөгөөд бид энэ параметр дээр үндэслэн тэдгээрийг харьцуулах болно.
Hz vs Redis
Бид үүнийг олдог :
Цэнхэр нь Редис, улаан нь Хазелкаст. Hazelcast хаа сайгүй ялдаг бөгөөд үүнд үндэслэл бий: энэ нь олон урсгалтай, маш оновчтой, утас бүр өөрийн гэсэн хуваалттай ажилладаг тул блоклох зүйл байхгүй. Redis нь нэг урсгалтай бөгөөд орчин үеийн олон цөмт CPU-ээс ашиг тусаа өгөхгүй. Хазелкаст асинхрон оролт/гаралттай, Редис-Жедис блоклох залгууртай. Эцсийн эцэст, Hazelcast нь хоёртын протокол ашигладаг бөгөөд Редис нь текст төвтэй бөгөөд энэ нь үр ашиггүй гэсэн үг юм.
Ямар ч тохиолдолд харьцуулах өөр эх сурвалж руу хандъя. Тэр бидэнд юу үзүүлэх вэ?
Редис vs Гц
Өөр нэг нь :
Энд эсрэгээр улаан бол Редис юм. Өөрөөр хэлбэл, Редис нь гүйцэтгэлийн хувьд Hazelcast-аас илүү байдаг. Эхний харьцуулалтад Хазелкаст, хоёрдугаарт Редис түрүүлсэн. Өмнөх харьцуулалтад Хазелкаст яагаад ялсныг маш нарийн тайлбарлав.
Эхнийх нь үр дүн нь үнэн хэрэгтээ хуурамч байсан нь харагдаж байна: Редисийг үндсэн хайрцагт авч, Хазелкастыг туршилтын тохиолдолд тохируулсан. Дараа нь: нэгдүгээрт, бид хэнд ч итгэж чадахгүй, хоёрдугаарт, системээ сонгохдоо бид үүнийг зөв тохируулах шаардлагатай хэвээр байна. Эдгээр тохиргоонууд нь хэдэн арван, бараг зуу зуун параметрүүдийг агуулдаг.
Лонхыг сэгсрэх
Би одоо бидний хийсэн бүх үйл явцыг "Савыг сэгсрэх" зүйрлэлээр тайлбарлаж чадна. Өөрөөр хэлбэл, одоо та програмчлах шаардлагагүй, одоо гол зүйл бол stackoverflow-ийг унших чадвартай байх явдал юм. Миний багт эгзэгтэй мөчид яг ингэж ажилладаг мэргэжлийн хүн бий.
Тэр юу хийж байна вэ? Тэр эвдэрсэн зүйлийг харж, стекийн ул мөрийг харж, түүнээс хэдэн үг авдаг (энэ нь түүний програмын туршлагатай), Google-ээс хайлт хийж, хариултуудын дунд stackoverflow-ийг олдог. Уншихгүйгээр, бодолгүйгээр, асуултын хариултуудын дотроос тэр "үүнийг хий" гэсэн өгүүлбэртэй хамгийн төстэй зүйлийг сонгодог (ийм хариултыг сонгох нь түүний авъяас чадвар юм, учир нь тэр үргэлж хамгийн их лайк авсан хариулт байдаггүй) хамааралтай , харагдах: хэрэв ямар нэг зүйл өөрчлөгдсөн бол гайхалтай. Хэрэв өөрчлөгдөөгүй бол буцааж эргүүлнэ үү. Мөн эхлүүлэх-шалгах-хайлтыг давт. Энэхүү зөн совингийн тусламжтайгаар тэрээр хэсэг хугацааны дараа код ажиллахыг баталгаажуулдаг. Тэр яагаад гэдгийг мэдэхгүй, юу хийснээ мэдэхгүй, тайлбарлаж ч чадахгүй. Гэхдээ! Энэ халдвар ажилладаг. Мөн "Гал унтарлаа." Одоо бид юу хийснийг олж мэдье. Хөтөлбөр ажиллаж байх үед энэ нь илүү хялбар болно. Мөн энэ нь маш их цаг хэмнэдэг.
Энэ аргыг энэ жишээгээр маш сайн тайлбарласан болно.
Нэгэн цагт дарвуулт завийг лонхонд цуглуулах нь их алдартай байсан. Үүний зэрэгцээ дарвуулт завь нь том, хэврэг, лонхны хүзүү нь маш нарийхан тул дотор нь түлхэх боломжгүй юм. Үүнийг хэрхэн угсрах вэ?
Ийм арга байдаг, маш хурдан бөгөөд маш үр дүнтэй байдаг.
Усан онгоц нь саваа, олс, далбаа, цавуу гэх мэт олон жижиг зүйлсээс бүрдэнэ. Бид энэ бүгдийг лонхонд хийнэ.
Бид хоёр гараараа шилийг аваад сэгсэрч эхэлдэг. Бид түүнийг сэгсэрч, сэгсэрнэ. Тэгээд ихэвчлэн энэ нь бүрэн хог болж хувирдаг, мэдээжийн хэрэг. Гэхдээ заримдаа. Заримдаа энэ нь хөлөг онгоц болж хувирдаг! Илүү нарийн, хөлөг онгоцтой төстэй зүйл.
Бид үүнийг хэн нэгэнд үзүүлэв: "Серёга, чи харж байна уу!?" Үнэхээр холоос энэ нь хөлөг онгоц шиг харагдаж байна. Гэхдээ үүнийг үргэлжлүүлэхийг зөвшөөрөх боломжгүй.
Өөр арга бий. Тэдгээрийг хакерууд гэх мэт илүү дэвшилтэт залуус ашигладаг.
Би энэ залууд даалгавар өгчихөөд бүгдийг нь хийгээд яваад өгсөн. Мөн та харлаа - энэ нь дууссан юм шиг байна. Хэсэг хугацааны дараа кодыг эцэслэх шаардлагатай бол энэ нь түүнээс болж эхэлдэг ... Тэр аль хэдийн хол зугтаж чадсан нь сайн хэрэг. Эдгээр нь лонхны жишээг ашиглан үүнийг хийх залуус юм: ёроол нь хаана байгааг харж байна, шил нь нугалж байна. Мөн ил тод эсэх нь бүрэн тодорхойгүй байна. Дараа нь "хакерууд" энэ ёроолыг огтолж, тэнд хөлөг онгоц оруулаад, ёроолыг нь дахин нааж, ийм байх ёстой юм шиг байна.
Асуудлыг тавих талаас нь харахад бүх зүйл зөв юм шиг санагддаг. Гэхдээ усан онгоцнуудыг жишээ болгон ашиглавал: яагаад энэ хөлөг онгоцыг хийдэг вэ, тэр хэнд хэрэгтэй вэ? Энэ нь ямар ч функцээр хангадаггүй. Ихэнхдээ ийм хөлөг онгоцууд нь маш өндөр албан тушаалтнуудад бэлэг бөгөөд тэдгээрийг тавиур дээр байрлуулж, ямар нэгэн бэлэг тэмдэг, тэмдэг болгон тавьдаг. Тэгээд ийм хүн, томоохон аж ахуйн нэгжийн дарга, өндөр албан тушаалтан бол хүзүүг нь тасалсан ийм хакерд туг яаж зогсох вэ. Тэр хэзээ ч энэ тухай мэдээгүй байсан нь дээр байх. Тэгвэл тэд чухал хүнд өгч болох эдгээр хөлөг онгоцуудыг яаж хийх вэ?
Таны юу ч хийж чадахгүй цорын ганц гол газар бол бие юм. Мөн хөлөг онгоцны их бие нь хүзүүнд яг таарч байна. Харин хөлөг онгоцыг лонхны гадна угсардаг. Гэхдээ энэ нь зөвхөн хөлөг онгоц угсрах биш, жинхэнэ үнэт эдлэлийн гар урлал юм. Бүрэлдэхүүн хэсгүүдэд тусгай хөшүүргийг нэмж, дараа нь тэдгээрийг өргөх боломжийг олгодог. Жишээ нь, далбаагаа нугалж, дотогшоо болгоомжтой авчирч, дараа нь хясаа ашиглан маш нарийн, нарийвчлалтайгаар татаж, өргөдөг. Үр дүн нь цэвэр ухамсар, бахархалыг бэлэглэж чадах урлагийн бүтээл юм.
Хэрэв бид төсөл амжилттай хэрэгжихийг хүсч байвал багт дор хаяж нэг үнэт эдлэлчин байх ёстой. Бүтээгдэхүүний чанарт санаа тавьдаг, бүх талыг нь харгалздаг, стресстэй үед ч гэсэн нөхцөл байдал нь чухал зүйлийг зардлаар яаралтай хийх шаардлагатай үед юу ч золиосолдоггүй. Тогтвортой, цаг хугацааны шалгуурыг давсан амжилттай бүх төслүүд энэ зарчим дээр суурилдаг. Тэдэнд маш нарийн бөгөөд өвөрмөц, боломжтой бүх боломжуудыг ашигладаг зүйл байдаг. Усан онгоцыг лонхонд хийсэн жишээн дээр хөлөг онгоцны их бие нь хүзүүгээр дамжин өнгөрч байгааг харуулж байна.
Манай кэш серверийг сонгох даалгавар руу буцахдаа энэ аргыг хэрхэн ашиглаж болох вэ? Би одоо байгаа бүх системээс сонгох ийм сонголтыг санал болгож байна - лонхыг бүү сэгсэр, бүү сонго, гэхдээ систем сонгохдоо юуг анхаарах, зарчмын хувьд юу байгааг хараарай.
Лонхны хүзүүг хаанаас хайх вэ
Лонхыг сэгсрэхгүй байхыг хичээцгээе, тэнд байгаа бүх зүйлийг нэг нэгээр нь үзэхгүй байхыг хичээцгээе, гэхдээ бид гэнэт ийм системийг өөрсдөө зохион бүтээх юм бол ямар даалгавар гарахыг харцгаая. Мэдээжийн хэрэг, бид унадаг дугуйг угсарахгүй, гэхдээ бид энэ диаграммыг ашиглан бүтээгдэхүүний тайлбарт юуг анхаарах ёстойг ойлгоход тусална. Ийм схемийг тоймлон зурцгаая.
Хэрэв систем тархсан бол бид хэд хэдэн сервертэй болно (6). Дөрөв байна гэж бодъё (тэдгээрийг зураг дээр байрлуулахад тохиромжтой, гэхдээ мэдээжийн хэрэг, тэдгээрийн аль нь ч байж болно). Хэрэв серверүүд өөр өөр зангилаанууд дээр байгаа бол эдгээр зангилаанууд нь кластер үүсгэх, тасалдсан тохиолдолд холбогдож, бие биенээ таних үүрэгтэй зарим кодыг ажиллуулдаг гэсэн үг юм.
Бидэнд бас кодын логик (2) хэрэгтэй бөгөөд энэ нь үнэндээ кэш хийх тухай юм. Үйлчлүүлэгчид энэ кодтой зарим API-ээр харилцдаг. Үйлчлүүлэгчийн код (1) нь ижил JVM дотор байх эсвэл сүлжээгээр хандах боломжтой. Дотор хэрэгжсэн логик нь аль объектыг кэшэд үлдээх, алийг нь хаяхыг шийдэх явдал юм. Бид кэшийг хадгалахын тулд санах ойг (3) ашигладаг боловч шаардлагатай бол зарим өгөгдлийг дискэнд (4) хадгалах боломжтой.
Ямар хэсгүүдэд ачаалал үүсэхийг харцгаая. Үнэндээ сум бүр, зангилаа бүр ачаалагдах болно. Нэгдүгээрт, үйлчлүүлэгчийн код болон api хооронд, хэрэв энэ нь сүлжээний харилцаа холбоо юм бол суулт нь мэдэгдэхүйц байж болно. Хоёрдугаарт, api-ийн хүрээнд - хэрэв бид үүнийг нарийн төвөгтэй логикоор хэтрүүлбэл CPU-тэй холбоотой асуудал гарч болзошгүй. Логик санах ойд цаг алдахгүй бол сайхан байх болно. Файлын системтэй харилцах харилцаа хэвээр байна - ердийн хувилбарт энэ нь цуваа / сэргээх, бичих / унших явдал юм.
Дараа нь кластертай харилцах явдал юм. Хамгийн магадлалтай, энэ нь нэг системд байх болно, гэхдээ тусдаа байж болно. Энд та өгөгдөл дамжуулах, өгөгдөл дамжуулах хурд, кластер хоорондын харилцан үйлчлэл зэргийг анхаарч үзэх хэрэгтэй.
Одоо бид нэг талаас манай кодын хүсэлтийг боловсруулахдаа кэшийн системд "ямар араа эргэхийг" төсөөлж, нөгөө талаас манай код энэ системд ямар, хэдэн хүсэлт үүсгэхийг тооцоолж болно. Энэ нь илүү их эсвэл бага ухаалаг сонголт хийхэд хангалттай - бидний хэрэглээний тохиолдолд системийг сонгоход хангалттай.
Хазелкаст
Энэхүү задралыг жагсаалтад хэрхэн ашиглахыг харцгаая. Жишээлбэл, Хазелкаст.
Hazelcast-аас өгөгдөл оруулах/авахын тулд үйлчлүүлэгчийн код нь (1) api-д ханддаг. Hz нь серверийг суулгагдсан байдлаар ажиллуулах боломжийг олгодог бөгөөд энэ тохиолдолд api руу хандах нь JVM доторх аргын дуудлага бөгөөд үүнийг үнэ төлбөргүй гэж үзэж болно.
(2) дахь логикийг ажиллуулахын тулд Гц нь цуваа түлхүүрийн байт массивын хэш дээр тулгуурладаг - өөрөөр хэлбэл түлхүүрийг ямар ч тохиолдолд цуваа болгох болно. Энэ нь Гц-ийн хувьд зайлшгүй ачаалал юм.
Нүүлгэн шилжүүлэх стратеги нь сайн хэрэгждэг боловч онцгой тохиолдолд та өөрөө нэмж болно. Та энэ хэсэгт санаа зовох хэрэггүй.
Хадгалах (4) холбох боломжтой. Агуу их. Embedded-д зориулсан харилцан үйлчлэлийг (5) шуурхай гэж үзэж болно. Кластер дахь зангилааны хооронд өгөгдөл солилцох (6) - тийм ээ, энэ нь байна. Энэ бол хурдыг алдагдуулахын тулд алдааг тэсвэрлэх хөрөнгө оруулалт юм. Гц онцлог Near-cache нь үнийг бууруулах боломжийг олгодог - кластерын бусад зангилаанаас хүлээн авсан өгөгдлийг кэшлэх болно.
Ийм нөхцөлд хурдыг нэмэгдүүлэхийн тулд юу хийж болох вэ?
Жишээлбэл, (2) дахь түлхүүрийг цуваа болгохгүйн тулд - хамгийн халуун мэдээлэл авахын тулд Hazelcast дээр өөр кэш хавсаргана уу. Sportmaster энэ зорилгоор кофейныг сонгосон.
(6) түвшинд мушгихад Hz нь IMap болон ReplicatedMap гэсэн хоёр төрлийн хадгалалтыг санал болгодог.
Хазелкаст Sportmaster технологийн стек рүү хэрхэн орсныг дурдах нь зүйтэй.
2012 онд бид ирээдүйн сайтын хамгийн анхны туршилтын ажил дээр ажиллаж байх үед хайлтын систем буцаж ирсэн анхны холбоос нь Hazelcast байсан юм. Танил "анхны удаа" эхэлсэн - ердөө хоёр цагийн дараа бид Гц-ийг системд оруулахад энэ нь ажиллаж байсан нь бидний сэтгэлийг хөдөлгөв. Тэгээд сайн ажилласан. Өдрийн эцэс гэхэд бид хэд хэдэн туршилтыг дуусгасан бөгөөд баяртай байсан. Энэхүү эрч хүчний нөөц нь Гц-ийн цаг хугацааны явцад бөөлжсөн гайхшралыг даван туулахад хангалттай байв. Одоо Sportmaster багт Хазелкастыг орхих шалтгаан байхгүй.
Гэхдээ "хайлтын систем дэх анхны холбоос", "HelloWorld хурдан угсарсан" гэх мэт аргументууд нь мэдээжийн хэрэг сонголт хийх үеийн онцгой тохиолдол бөгөөд онцлог шинж юм. Сонгосон системийн жинхэнэ туршилтууд нь үйлдвэрлэлд нэвтрүүлэхээс эхэлдэг бөгөөд яг энэ үе шатанд та ямар ч систем, түүний дотор кэшийг сонгохдоо анхаарах хэрэгтэй. Үнэндээ манай тохиолдолд бид Hazelcast-ийг санамсаргүйгээр сонгосон гэж хэлж болно, гэхдээ дараа нь бид зөв сонгосон нь тодорхой болсон.
Үйлдвэрлэлийн хувьд илүү чухал: хяналт тавих, бие даасан зангилаа дээрх алдааг зохицуулах, өгөгдлийг хуулбарлах, масштаблах зардал. Өөрөөр хэлбэл, системд засвар үйлчилгээ хийх явцад гарах даалгавруудад анхаарлаа хандуулах нь зүйтэй юм - ачаалал төлөвлөснөөс хэдэн арван дахин их байх үед, бид санамсаргүйгээр ямар нэг зүйлийг буруу газар байршуулах, шинэ хувилбар гаргах шаардлагатай үед. кодын, өгөгдлийг сольж, үйлчлүүлэгчдэд мэдэгдэхгүйгээр хийх.
Эдгээр бүх шаардлагуудын хувьд Hazelcast энэ хуулийн төсөлд нийцэх нь гарцаагүй.
Үргэлжлэл бий
Гэхдээ Hazelcast бол эм биш юм. 2017 онд бид өнгөрсөн туршлагаас авсан сайхан сэтгэгдэл дээр үндэслэн админ кэшийн хувьд Hazelcast-ийг сонгосон. Энэ нь маш харгис онигоонд гол үүрэг гүйцэтгэсэн бөгөөд үүний улмаас бид хүнд байдалд орж, 60 хоногийн турш "баатарлаг" байдлаар гарч чадсан юм. Гэхдээ энэ талаар дараагийн хэсэгт илүү дэлгэрэнгүй.
Энэ хооронд... Шинэ кодын мэнд хүргэе!
Эх сурвалж: www.habr.com