1. Database: Race Condition. Prizlar ro'yxati bor. 5 tadan 3 tasi aktiv, 2 tasi tark etgan. Endi navbatdagi ishtirokchiga keyingi prizni qaytarish kerak. Bunday holatlarda bir vaqtda ikkita request birga kelishi oqibatida ikkita ishtirokchiga bitta sovg'a ketib qolishi mumkin. Bu narsani oldini olish uchun esa, "Lock for Update" metodi orqali amalga oshirish, bu muammoga yechim beradi. Bu holatda birinchi request tanlagan priz, o'zgarish uchun bloklanadi. Natijada keyingi request bu prizni tanlamaydi, balki boshqasini tanlaydi.

2. Database: Slow queries. Bazaga ko'p murojat qilish va natijada loyihani sekinlashtirish doimiy muammolardan. Indekslash esa bunga yaxshi yechim bera oladi. Bazadagi ma'lumotlarni indekslash orqali slow query'larni ishlashini tezlashtiramiz.

3. Database: Indexing cons. Indekslashni minus tomonlaridan biri, "insert, update, delete" uchun query'larni sekinlashib qolishi. Bu muammoga bazani ikkitaga bo'lish orqali yechim beriladi, ya'ni "DB Replication". Bitta asosiy baza - "insert, update, delete" uchun, ikkinchi baza asosiy bazani ko'chirmasi sifatida "select" uchun ishlatilinadi. Ikkinchi baza asosiy bazadan ma'lumotlarni o'ziga sync qilib turadi.

4. Database: Caching. Ba'zi natijasi o'zgarmas query'larni keshlash bazaga ortiqcha request'ni oldini oladi. Kesh tizimi bazaga murojaat qilishdan ko'ra tezroq ishlaydi. Bu holatga "Redis" yaxshi yechim beradi.

5. Redis: Too many connections. Ba'zida Redis'ga request'lar ko'payib ketishi natijasida Redis ham javob berolmay qoladi. Bu muammo o'zimda ham uchragandi. Ammo muammoni hal qilolmagandim. Bunga yechimlaridan biri "Pooling" qilish. Default holatda Redis'ga berilgan request bitta connection ochadi. Ishini to'xtatgandan keyin u connection yopiladi. Pooling'da esa bitta connection doimiy ochiq holda bo'ladi.

6. Redis: Slow query. Aslida keshlar bazaga beriladigan query'larni vaqtini kamaytirish uchun qilinadi. Ammo yuqoridagi holatdan keyin Redis'dan javob olish ham sekinlashib qoladi. (qolibdi) Bunga yechim sifatida Redis'ni "cluster"larga bo'lish orqali yechim topsa bo'ladi. Default holatda Redis 0 indeksli bazasini ishlatadi. Qo'shimcha unda yana 16 ta (0 bilan birga) baza bor. Bu holatda qolgan bazalarni ham ishlatish bu muammoga yechim bo'ladi.

7. PHP: Slow Request. Endi PHP scriptni o'zini javob berishiga kelsak. PHP intepreted til bo'lganligi uchun, run qilganimizda kod Parsing qismida undagi error'lar tekshiriladi. Agar xatolar chiqmasa, keyin OpCode'ga ya'ni operatsion kodga o'giriladi. Keyin Zend Engine uni haqiqiy komputer tushunadigan tilda run qiladi. Har safar shu jarayon takrorlanadi. "OpCache" orqali esa, Zend Engine qismigacha bo'lgan qismlarni olib tashlasak bo'ladi. Ya'ni bir marta ishga tushirilgan script endi xotiradan olinadi. Yana bunga yordamchi sifatida "JIT (Just in time)"ni qo'llashimiz mumkin. Bu bizga Zend Engine ishini ham olib tashlashga yordam beradi. Bitta run qilingan script birinchi marta hamma bosqichdan o'tadi va keyingi holatdan faqatgina xotiradan ishga tushadi.

8. Server: Too many connection. Tasavvur qiling xonaga 50 ta odam sig'adi. 51-odam kelib qolsa, bittasi bo'shashini kutadi. Natijada kutish ham bir necha soniya vaqt olib qoladi. Bu muammoga esa, PHP'ni asinxron sifatida ishlatish yordam beradi. "PHP Swoole" yordamida usha kutib turgan 51-odamni ham kirg'izsak bo'ladi. Ya'ni 51-requestga ham javob beradi.

Xullas, yuqoridagi amallarni qilish loyihani highload'da ham ishlab berishini ta'minlab beradi. Tajribadan o'tgan narsalari asosida gapirilgan ma'lumotlarni tushunganim bo'yicha yozdim. Rasmlarni quyida topishingiz mumkin: https://t.me/UzGeeksCommunity/483