Манай хэрэглэгчид ядрахаа мэдэхгүй бие биедээ мессеж бичдэг.
Энэ нь нэлээд их юм. Хэрэв та бүх хэрэглэгчдийн бүх мессежийг уншихаар шийдсэн бол 150 мянга гаруй жил шаардагдах болно. Хэрэв та нэлээд дэвшилтэт уншигч бөгөөд мессеж бүрт нэг секундээс илүүгүй хугацаа зарцуулдаг бол.
Ийм их хэмжээний өгөгдлийн хувьд тэдгээрийг хадгалах, ашиглах логикийг оновчтой болгох нь чухал юм. Тэгэхгүй бол тийм ч гайхалтай биш нэг мөчид бүх зүйл удахгүй буруу болох нь тодорхой болж магадгүй юм.
Бидний хувьд энэ мөч жил хагасын өмнө ирсэн. Бид яаж ийм байдалд хүрсэн, эцэст нь юу болсныг бид танд дарааллаар нь хэлье.
Оршил
Эхний хэрэгжилтэд VKontakte мессежүүд нь PHP backend болон MySQL-ийн хослол дээр ажилласан. Энэ бол жижиг оюутны вэбсайтын хувьд ердийн шийдэл юм. Гэсэн хэдий ч энэ сайт хяналтгүй өсч, өгөгдлийн бүтцийг өөртөө оновчтой болгохыг шаардаж эхлэв.
2009 оны сүүлээр анхны текст хөдөлгүүрийн агуулахыг бичиж, 2010 онд мессежийг түүнд шилжүүлэв.
Текстийн хөдөлгүүрт мессежүүдийг жагсаалтад хадгалдаг байсан - нэг төрлийн "шуудангийн хайрцаг". Ийм жагсаалт бүрийг эдгээр бүх мессежийг эзэмшдэг хэрэглэгч болох uid-ээр тодорхойлдог. Мессеж нь харилцан ярианы танигч, текст, хавсралт гэх мэт олон шинж чанартай байдаг. "Хайрцаг" доторх мессеж танигч нь local_id бөгөөд энэ нь хэзээ ч өөрчлөгддөггүй бөгөөд шинэ мессежүүдэд дарааллаар хуваарилагддаг. "Хайрцаг" нь бие даасан бөгөөд хөдөлгүүр дотор бие биетэйгээ синхрончлогдоогүй бөгөөд тэдгээрийн хоорондын харилцаа PHP түвшинд явагддаг. Та текст хөдөлгүүрийн өгөгдлийн бүтэц, чадавхийг дотроос нь харж болно .
Энэ нь хоёр хэрэглэгчийн захидал харилцаанд хангалттай байсан. Дараа нь юу болсныг таах уу?
2011 оны XNUMX-р сард ВКонтакте хэд хэдэн оролцогчтой харилцан яриаг нэвтрүүлсэн - олон чат. Тэдэнтэй ажиллахын тулд бид гишүүн-чат болон чат-гишүүд гэсэн хоёр шинэ кластер үүсгэсэн. Эхнийх нь хэрэглэгчдийн чатын мэдээллийг хадгалдаг, хоёр дахь нь чатаар хэрэглэгчдийн талаарх мэдээллийг хадгалдаг. Жагсаалтаас гадна, жишээлбэл, урьсан хэрэглэгч болон тэдний чатад нэмэгдсэн цаг зэргийг багтаана.
"PHP, чат руу мессеж илгээцгээе" гэж хэрэглэгч хэлэв.
"Алив, {username}" гэж PHP хэлэв.
Энэ схемд сул талууд бий. Синхрончлол нь PHP-ийн үүрэг хэвээр байна. Том чатууд болон тэдэн рүү нэгэн зэрэг мессеж илгээдэг хэрэглэгчид бол аюултай түүх юм. Текст-хөдөлгүүрийн жишээ нь uid-аас хамаардаг тул чатын оролцогчид өөр өөр цаг үед ижил мессеж хүлээн авах боломжтой. Хэрэв ахиц дэвшил зогссон бол хүн үүнтэй хамт амьдарч чадна. Гэхдээ ийм зүйл болохгүй.
2015 оны сүүлээр бид олон нийтийн мессежийг эхлүүлсэн бөгөөд 2016 оны эхээр бид тэдэнд зориулсан API-г эхлүүлсэн. Нийгэмлэгт томоохон чатботууд гарч ирснээр ачааллын жигд хуваарилалтыг мартах боломжтой болсон.
Сайн бот нь өдөрт хэдэн сая мессеж үүсгэдэг - хамгийн их ярьдаг хэрэглэгчид ч үүнийг сайрхаж чадахгүй. Энэ нь ийм роботууд дээр ажиллаж байсан текст хөдөлгүүрийн зарим тохиолдлууд бүрэн дүүрэн зовж эхэлсэн гэсэн үг юм.
2016 оны мессежийн систем нь чат-гишүүд болон гишүүн-чатуудын 100 тохиолдол, 8000 текст хөдөлгүүр юм. Тэд тус бүр нь 64 ГБ санах ойтой мянга гаруй сервер дээр байрладаг байв. Эхний яаралтай арга хэмжээ болгон бид санах ойг дахин 32 ГБ-аар нэмэгдүүлэв. Бид урьдчилсан таамаглалыг тооцоолсон. Хэрэв эрс өөрчлөлт хийхгүй бол энэ нь нэг жил орчим хангалттай байх болно. Та техник хангамжийг олж авах эсвэл мэдээллийн санг өөрсдөө оновчтой болгох хэрэгтэй.
Архитектурын шинж чанараас шалтгаалан техник хангамжийг хэд хэдэн удаа нэмэгдүүлэх нь зүйтэй юм. Өөрөөр хэлбэл, автомашины тоог дор хаяж хоёр дахин нэмэгдүүлэх нь мэдээжийн хэрэг, энэ нь нэлээд үнэтэй зам юм. Бид оновчтой болгох болно.
Шинэ үзэл баримтлал
Шинэ аргын гол мөн чанар нь чат юм. Чат нь түүнтэй холбоотой мессежүүдийн жагсаалттай байдаг. Хэрэглэгч чатын жагсаалттай байна.
Шаардлагатай доод тал нь хоёр шинэ мэдээллийн сан юм:
- чат хөдөлгүүр. Энэ бол чатын векторуудын агуулах юм. Чат бүр өөртэй нь холбоотой мессежийн вектортой байдаг. Мессеж бүр нь текст болон чат доторх өвөрмөц мессеж танигчтай - chat_local_id.
- хэрэглэгчийн хөдөлгүүр. Энэ бол хэрэглэгчийн векторуудын хадгалалт юм - хэрэглэгчдэд зориулсан холбоос. Хэрэглэгч бүр peer_id вектор (харилцагч - бусад хэрэглэгчид, олон чат эсвэл нийгэмлэг) ба мессежийн вектортой байдаг. Peer_id бүр өөртэй нь холбоотой мессежийн вектортой байдаг. Мессеж бүр нь chat_local_id болон тухайн хэрэглэгчийн өвөрмөц мессеж ID-тай байдаг - user_local_id.
Шинэ кластерууд TCP ашиглан өөр хоорондоо харилцдаг - энэ нь хүсэлтийн дараалал өөрчлөгдөхгүй байхыг баталгаажуулдаг. Хүсэлтүүд болон тэдгээрийн баталгаажуулалт нь хатуу диск дээр бичигдсэн байдаг тул бид эвдэрсэн эсвэл хөдөлгүүр дахин ассаны дараа хүссэн үедээ дарааллын төлөвийг сэргээх боломжтой. Хэрэглэгчийн хөдөлгүүр болон чат хөдөлгүүр нь тус бүрдээ 4 мянган ширхэг байдаг тул кластеруудын хоорондох хүсэлтийн дараалал жигд тархах болно (гэхдээ бодит байдал дээр огт байхгүй - маш хурдан ажилладаг).
Ихэнх тохиолдолд манай мэдээллийн сан дахь дисктэй ажиллах нь өөрчлөлтийн хоёртын бүртгэл (binlog), статик агшин зуурын зураг, санах ой дахь хэсэгчилсэн дүрсний хослол дээр суурилдаг. Өдрийн өөрчлөлтийг бинлогт бичиж, одоогийн төлөвийн агшин зуурын зургийг үе үе үүсгэдэг. Хормын хувилбар нь бидний зорилгод нийцүүлэн оновчтой болгосон өгөгдлийн бүтцийн цуглуулга юм. Энэ нь толгой хэсэг (зургийн метаиндекс) болон метафайлуудын багцаас бүрдэнэ. Толгой хэсэг нь RAM-д байнга хадгалагддаг бөгөөд агшин зуурын агшин зуурын мэдээллийг хаанаас хайхыг заадаг. Метафайл бүрд ойрын үед хэрэг болохуйц өгөгдөл орно, тухайлбал, нэг хэрэглэгчтэй холбоотой. Та хормын зургийн толгойг ашиглан мэдээллийн сангаас асуулга хийх үед шаардлагатай мета файлыг уншиж, дараа нь агшин зуурын зургийг үүсгэсний дараа гарсан бинлог дахь өөрчлөлтүүдийг харгалзан үзнэ. Та энэ аргын ашиг тусын талаар илүү ихийг уншиж болно .
Үүний зэрэгцээ хатуу диск дээрх өгөгдөл өөрөө өдөрт нэг л удаа өөрчлөгддөг - Москвад шөнийн цагаар ачаалал бага байх үед. Үүний ачаар (диск дээрх бүтэц нь өдрийн турш тогтмол байдаг гэдгийг мэддэг) бид векторуудыг тогтмол хэмжээтэй массиваар солих боломжтой бөгөөд үүний ачаар санах ой нэмэгддэг.
Шинэ схемд мессеж илгээх нь дараах байдалтай байна.
- PHP backend нь мессеж илгээх хүсэлтээр хэрэглэгчийн хөдөлгүүртэй холбогддог.
- хэрэглэгчийн хөдөлгүүр нь хүсэлтийг хүссэн чат-хөдөлгүүрийн инстанц руу илгээдэг бөгөөд энэ нь хэрэглэгчийн хөдөлгүүрийн chat_local_id руу буцдаг - энэ чат доторх шинэ мессежийн өвөрмөц танигч. Дараа нь chat_engine нь мессежийг чат дахь бүх хүлээн авагчдад дамжуулдаг.
- user-engine нь chat-engine-ээс chat_local_id хүлээн авч, user_local_id-г PHP руу буцаадаг - энэ хэрэглэгчийн өвөрмөц мессеж танигч. Дараа нь энэ танигчийг жишээ нь API-ээр дамжуулан мессежтэй ажиллахад ашигладаг.
Гэхдээ мессеж илгээхээс гадна хэд хэдэн чухал зүйлийг хэрэгжүүлэх хэрэгтэй:
- Жишээлбэл, дэд жагсаалтууд нь харилцан ярианы жагсаалтыг нээх үед хамгийн сүүлийн үеийн мессежүүд юм. Уншаагүй мессежүүд, шошготой мессежүүд ("Чухал", "Спам" гэх мэт).
- Чат хөдөлгүүрт мессежийг шахаж байна
- Хэрэглэгчийн хөдөлгүүрт мессежүүдийг кэшлэх
- Хайх (бүх харилцах цонхнууд болон тодорхой нэг дотроос).
- Бодит цагийн шинэчлэл (Longpolling).
- Мобайл үйлчлүүлэгчид кэшийг хэрэгжүүлэхийн тулд түүхийг хадгалж байна.
Бүх дэд жагсаалтууд бүтэц нь хурдан өөрчлөгдөж байна. Тэдэнтэй ажиллахын тулд бид ашигладаг . Энэ сонголтыг модны дээд хэсэгт бид заримдаа агшин зуурын агшин зуурын зурвасын бүхэл хэсгийг хадгалдаг - жишээлбэл, шөнийн дахин индексжүүлсний дараа мод нь дэд жагсаалтын бүх мессежийг агуулсан нэг дээд хэсгээс бүрддэгтэй холбон тайлбарладаг. Splay мод нь тэнцвэржүүлэх талаар бодох шаардлагагүйгээр ийм оройн дундуур оруулахад хялбар болгодог. Нэмж дурдахад Splay нь шаардлагагүй өгөгдлийг хадгалахгүй бөгөөд энэ нь бидний санах ойг хэмнэдэг.
Мессежүүд нь их хэмжээний мэдээлэл, гол төлөв текстийг агуулдаг бөгөөд энэ нь шахах чадвартай байдаг. Бид нэг мессежийг ч гэсэн үнэн зөв архиваас гаргаж авах нь чухал. Мессежийг шахахад ашигладаг Өөрсдийн эвристикийн тусламжтайгаар - жишээлбэл, мессеж дэх үгс нь "үггүй" - хоосон зай, цэг таслал гэх мэт солигдож байдгийг бид мэддэг бөгөөд орос хэлний тэмдэглэгээг ашиглах зарим онцлог шинж чанаруудыг бид санаж байна.
Чатаас хамаагүй цөөн хэрэглэгчид байдаг тул санамсаргүй хандалтын дискний хүсэлтийг чат хөдөлгүүрт хадгалахын тулд бид мессежийг хэрэглэгчийн хөдөлгүүрт кэш хийдэг.
Мессеж хайлт нь хэрэглэгчийн хөдөлгүүрээс энэ хэрэглэгчийн чатыг агуулсан бүх чат хөдөлгүүрийн инстанцууд руу диагональ асуулга хэлбэрээр хэрэгждэг. Үр дүнг хэрэглэгчийн хөдөлгүүрт нэгтгэдэг.
За, бүх нарийн ширийн зүйлийг анхаарч үзсэн, зөвхөн шинэ схемд шилжихэд л үлддэг - хэрэглэгчид үүнийг анзаарахгүй байх нь дээр.
Өгөгдлийн шилжилт
Тиймээс бид хэрэглэгчийн мессежийг хадгалдаг текст хөдөлгүүртэй бөгөөд олон чатын өрөөнүүд болон тэдгээрт байгаа хэрэглэгчдийн мэдээллийг хадгалдаг хоёр кластер чат-гишүүд, гишүүн-чатууд. Үүнээс хэрхэн шинэ хэрэглэгчийн хөдөлгүүр болон чат хөдөлгүүр рүү шилжих вэ?
Хуучин схемийн гишүүн чатуудыг голчлон оновчтой болгоход ашигладаг байсан. Бид үүнээс шаардлагатай өгөгдлийг чатын гишүүд рүү хурдан шилжүүлж, дараа нь шилжих үйл явцад оролцохоо больсон.
Чатын гишүүдийн дараалал. Үүнд 100 тохиолдол багтсан бол chat-engine 4 мянга байна. Өгөгдлийг дамжуулахын тулд та үүнийг нийцүүлэх хэрэгтэй - үүний тулд чатын гишүүдийг ижил 4 мянган хувь болгон хувааж, дараа нь чатын хөдөлгүүрт чатын гишүүдийн бинлогийг уншихыг идэвхжүүлсэн.
Одоо chat-engine нь чатын гишүүдийн олон чатын талаар мэддэг боловч хоёр ярилцагчтай харилцах талаар юу ч мэдэхгүй байна. Ийм харилцан яриа нь хэрэглэгчдэд хамаарах текстийн хөдөлгүүрт байрладаг. Энд бид өгөгдлийг "толгойгоор нь" авч үзсэн: чат-хөдөлгүүр бүр нь шаардлагатай харилцан яриа байгаа эсэхийг бүх текст-хөдөлгүүрийн жишээнүүдээс асуусан.
Гайхалтай - чат-хөдөлгүүр нь олон чат гэж юу байдгийг мэддэг бөгөөд ямар харилцан яриа байдгийг мэддэг.
Та олон чат чат дахь мессежүүдийг нэгтгэх хэрэгтэй бөгөөд ингэснээр та чат бүрт мессежийн жагсаалттай болно. Нэгдүгээрт, чат хөдөлгүүр нь энэ чатаас бүх хэрэглэгчийн мессежийг текст хөдөлгүүрээс татаж авдаг. Зарим тохиолдолд тэдгээр нь нэлээд олон байдаг (хэдэн зуун сая хүртэл), гэхдээ маш ховор тохиолдлуудыг эс тооцвол чат нь RAM-д бүрэн нийцдэг. Бидэнд дараалалгүй мессежүүд байгаа бөгөөд тус бүр нь хэд хэдэн хувь байдаг - эцэст нь тэдгээр нь бүгд хэрэглэгчдэд тохирох өөр өөр текст хөдөлгүүрийн тохиолдлуудаас татагддаг. Зорилго нь мессежийг ангилж, шаардлагагүй зай эзэлдэг хуулбараас салах явдал юм.
Мессеж бүр илгээсэн цаг болон текстийг агуулсан цагийн тэмдэгтэй. Бид цагийг эрэмбэлэхдээ ашигладаг - бид олон чат оролцогчдын хамгийн эртний мессежүүд рүү заагч байрлуулж, төлөвлөсөн хуулбаруудын текстээс хэшийг харьцуулж, цаг хугацааг нэмэгдүүлэх чиглэлд шилждэг. Хуулбарууд нь ижил хэш, цагийн тэмдэгтэй байх нь логик боловч бодит байдал дээр энэ нь үргэлж тийм байдаггүй. Таны санаж байгаагаар хуучин схемийн синхрончлолыг PHP гүйцэтгэдэг бөгөөд ховор тохиолдолд ижил мессеж илгээх хугацаа өөр өөр хэрэглэгчдийн дунд өөр өөр байдаг. Эдгээр тохиолдолд бид ихэвчлэн секундын дотор цагийн тэмдгийг засварлахыг зөвшөөрдөг. Хоёр дахь асуудал бол өөр өөр хүлээн авагчдад зориулсан мессежийн дараалал юм. Ийм тохиолдолд бид өөр өөр хэрэглэгчдэд зориулсан захиалгын өөр сонголттой нэмэлт хуулбар үүсгэхийг зөвшөөрсөн.
Үүний дараа олон чат дахь мессежийн мэдээллийг хэрэглэгчийн хөдөлгүүр рүү илгээдэг. Импортын мессежийн тааламжгүй шинж чанар энд ирдэг. Хэвийн үед хөдөлгүүрт ирсэн мессежийг хэрэглэгчийн_local_id-ээр өсөх дарааллаар эрэмбэлдэг. Хуучин хөдөлгүүрээс хэрэглэгчийн хөдөлгүүрт оруулсан мессежүүд нь энэ ашигтай шинж чанараа алдсан. Үүний зэрэгцээ, туршилт хийхэд хялбар байхын тулд та тэдгээрт хурдан нэвтэрч, тэдгээрээс ямар нэг зүйлийг хайж, шинээр нэмэх боломжтой байх хэрэгтэй.
Бид импортын мессежийг хадгалахын тулд тусгай өгөгдлийн бүтцийг ашигладаг.
Энэ нь хэмжээтэй векторыг илэрхийлдэг бүгд хаана байна - элементүүдийн тусгай дарааллаар ялгаатай бөгөөд буурах дарааллаар эрэмблэгдсэн байдаг. Индекс бүхий сегмент бүрт элементүүдийг эрэмбэлсэн. Ийм бүтэц дэх элементийг хайхад цаг хугацаа шаардагдана дамжуулан хоёртын хайлт. Элемент нэмсэн тохиолдолд хорогдуулна .
Тиймээс бид хуучин хөдөлгүүрээс шинэ хөдөлгүүр рүү өгөгдлийг хэрхэн шилжүүлэх талаар олж мэдсэн. Гэхдээ энэ үйл явц хэдэн өдөр үргэлжилдэг бөгөөд эдгээр өдрүүдэд манай хэрэглэгчид бие биендээ захидал бичих зуршлаа орхих магадлал багатай юм. Энэ хугацаанд мессежээ алдахгүйн тулд бид хуучин болон шинэ кластеруудыг ашигладаг ажлын схемд шилждэг.
Өгөгдлийг чатын гишүүд болон хэрэглэгчийн хөдөлгүүрт бичдэг (хуучин схемийн дагуу ердийн үйл ажиллагаатай адил текст хөдөлгүүрт биш). хэрэглэгчийн хөдөлгүүр нь chat-engine-ийн хүсэлтийг прокси болгодог - энд зан төлөв нь энэ чатыг аль хэдийн нэгтгэсэн эсэхээс хамаарна. Хэрэв чат хараахан нэгдэж амжаагүй бол чат-хөдөлгүүр өөрөө мессеж бичихгүй бөгөөд түүний боловсруулалт зөвхөн текст хөдөлгүүрт явагдана. Хэрэв чат аль хэдийн chat-engine-д нэгтгэгдсэн бол энэ нь хэрэглэгчийн хөдөлгүүрт chat_local_id-г буцааж, мессежийг бүх хүлээн авагч руу илгээдэг. хэрэглэгчийн хөдөлгүүр нь бүх өгөгдлийг текст-хөдөлгүүрт прокси болгодог - ингэснээр ямар нэг зүйл тохиолдвол бид хуучин хөдөлгүүрт байгаа бүх өгөгдлийг хадгалах боломжтой. text-engine нь user_local_id-г буцаадаг бөгөөд энэ нь хэрэглэгчийн хөдөлгүүр хадгалагдаж, арын хэсэгт буцаж ирдэг.
Үүний үр дүнд шилжилтийн үйл явц иймэрхүү харагдаж байна: бид хоосон хэрэглэгчийн хөдөлгүүр болон чат хөдөлгүүрийн кластеруудыг холбодог. chat-engine нь чатын гишүүдийн бинлогийг бүхэлд нь уншдаг бөгөөд дараа нь дээр дурдсан схемийн дагуу прокси ажиллуулж эхэлнэ. Бид хуучин өгөгдлийг шилжүүлж, хоёр синхрончлогдсон кластер (хуучин ба шинэ) авдаг. Уншихыг текст хөдөлгүүрээс хэрэглэгчийн хөдөлгүүр рүү шилжүүлж, проксиг идэвхгүй болгох л үлдлээ.
Результаты
Шинэ аргын ачаар хөдөлгүүрийн гүйцэтгэлийн бүх үзүүлэлтүүд сайжирч, өгөгдлийн уялдаа холбоотой асуудлууд шийдэгдсэн. Одоо бид мессежийн шинэ функцуудыг хурдан хэрэгжүүлэх боломжтой болсон (мөн үүнийг аль хэдийн хийж эхэлсэн - бид чатанд оролцогчдын хамгийн их тоог нэмэгдүүлж, дамжуулсан мессежийн хайлтыг хийж, бэхлэгдсэн мессежүүдийг эхлүүлж, нэг хэрэглэгчдэд ногдох нийт мессежийн хязгаарыг нэмэгдүүлсэн) .
Логик дахь өөрчлөлтүүд үнэхээр асар их юм. Энэ нь үргэлж асар том баг, олон тооны мөрийн кодын бүтэн жилийн хөгжил гэсэн үг биш гэдгийг тэмдэглэхийг хүсч байна. chat-engine болон user-engine зэрэг нь мессеж шахах Хаффман, Splay мод, импортын мессежийн бүтэц зэрэг бүх нэмэлт түүхүүд нь 20 мянга хүрэхгүй мөр код юм. Тэдгээрийг ердөө 3 сарын дотор 10 хөгжүүлэгч бичсэн (гэхдээ үүнийг санах нь зүйтэй. - дэлхийн аварга ).
Түүгээр ч барахгүй серверийн тоог хоёр дахин нэмэгдүүлэхийн оронд бид тэдний тоог хоёр дахин бууруулсан - одоо хэрэглэгчийн хөдөлгүүр ба чат хөдөлгүүр нь 500 физик машин дээр ажиллаж байгаа бол шинэ схем нь ачаалал ихтэй байна. Бид тоног төхөөрөмжид маш их мөнгө хэмнэсэн - ойролцоогоор 5 сая доллар + үйл ажиллагааны зардалд жилд 750 мянган доллар.
Бид хамгийн төвөгтэй, том хэмжээний асуудлуудын хамгийн сайн шийдлийг олохыг хичээдэг. Бидэнд маш олон байдаг - тиймээс бид мэдээллийн сангийн хэлтэст авъяаслаг хөгжүүлэгчдийг хайж байна. Хэрэв та ийм асуудлыг хэрхэн шийдвэрлэх дуртай, мэддэг, алгоритм, өгөгдлийн бүтцийн талаар маш сайн мэдлэгтэй бол бид таныг багтаа нэгдэхийг урьж байна. Манайхтай холбогдоно уу дэлгэрэнгүй мэдээллийг авна уу.
Хэдийгээр энэ түүх таны тухай биш ч гэсэн бид зөвлөмжийг эрхэмлэдэг гэдгийг анхаарна уу. Найздаа хэлээрэй , хэрэв тэр туршилтын хугацааг амжилттай дуусгавал 100 мянган рублийн урамшуулал авах болно.
Эх сурвалж: www.habr.com