Lebih daripada 6,000 perkataan |. Perkara yang perlu diperhatikan semasa mereka bentuk sistem Flash Kill

Lima prinsip seni bina

Data hendaklah sekecil mungkin

Pertama sekali, ini bermakna data yang diminta oleh pengguna hendaklah sekecil mungkin. Data yang diminta termasuk data yang dimuat naik ke sistem dan data yang dikembalikan oleh sistem kepada pengguna (biasanya halaman web).

Bilangan permintaan hendaklah sekecil mungkin

Selepas halaman yang diminta oleh pengguna dikembalikan, penyemak imbas akan menyertakan permintaan tambahan lain apabila memaparkan halaman, contohnya, CSS/JavaScript, imej dan Ajax permintaan yang bergantung pada halaman ini. Ditakrifkan sebagai "permintaan tambahan", permintaan tambahan ini harus disimpan pada tahap minimum.

Laluan hendaklah sesingkat mungkin

Ia ialah bilangan nod perantaraan yang perlu dilalui oleh pengguna dalam proses daripada membuat permintaan hingga memulangkan data.

Pergantungan hendaklah sesedikit mungkin

merujuk kepada sistem atau perkhidmatan yang mesti dipercayai untuk menyelesaikan permintaan pengguna di sini merujuk kepada kebergantungan yang kuat.

Ketersediaan tinggi

Satu titik dalam sistem boleh dikatakan sebagai pantang larang dalam seni bina sistem, kerana satu titik bermakna tiada sandaran dan risiko yang tidak dapat dikawal Prinsip yang paling penting dalam mereka bentuk sistem teragih ialah "menghapuskan titik tunggal". , nama lain ialah "ketersediaan tinggi".

Seni bina ialah seni keseimbangan, dan sebaik sahaja seni bina terbaik dipisahkan daripada pemandangan yang disesuaikan dengannya, semuanya akan menjadi perbualan kosong. Apa yang perlu kita ingat ialah perkara yang dinyatakan di sini hanyalah arahan.

Bagaimana untuk melakukan pemisahan dinamik dan statik

Apakah itu data dinamik dan statik

Jadi apakah sebenarnya pemisahan dinamik dan statik? Apa yang dipanggil "pemisahan dinamik dan statik" sebenarnya bermaksud membahagikan data yang diminta oleh pengguna (seperti halaman HTML) kepada "data dinamik" dan "data statik". Ringkasnya, perbezaan utama antara "data dinamik" dan "data statik" adalah untuk melihat sama ada output data dalam halaman berkaitan dengan URL, penyemak imbas, masa, wilayah dan sama ada ia mengandungi data peribadi seperti kuki.

1. Bagi kebanyakan laman web media, kandungan artikel tertentu adalah sama sama ada anda melawatinya atau saya melawatinya. Jadi ia adalah data statik biasa, tetapi ia adalah halaman dinamik.
2. Jika kami melawati halaman utama Taobao sekarang, semua orang mungkin melihat halaman utama Taobao mengandungi banyak maklumat yang disyorkan berdasarkan ciri pelawat, dan data diperibadikan ini boleh difahami sebagai Data dinamik.

Bagaimana untuk cache data statik?

Pertama, anda harus cache data statik yang paling hampir dengan pengguna. Data statik ialah data yang secara relatifnya tidak berubah, jadi kita boleh cachenya. Di mana ia dicache? Terdapat tiga yang biasa: dalam penyemak imbas pengguna, pada CDN, atau dalam Cache pelayan. Anda harus cache mereka sedekat mungkin dengan pengguna mengikut situasi.

Kedua, transformasi statik adalah untuk terus cache sambungan HTTP. Berbanding dengan caching data biasa, anda pasti pernah mendengar tentang transformasi statik sistem. Transformasi statik terus cache sambungan HTTP dan bukannya hanya menyimpan data seperti yang ditunjukkan dalam rajah di bawah, pelayan proksi Web secara langsung mengeluarkan pengepala respons HTTP yang sepadan mengikut URL permintaan dan mengembalikannya secara langsung adalah sangat mudah sehingga ia tidak menggunakan protokol HTTP Dipasang semula, malah pengepala permintaan HTTP tidak perlu dihuraikan.

Ketiga, siapa yang cache data statik juga penting. Perisian cache yang ditulis dalam bahasa yang berbeza mempunyai kecekapan yang berbeza dalam memproses data cache. Ambil Java sebagai contoh, kerana sistem Java itu sendiri juga mempunyai kelemahannya (contohnya, ia tidak pandai mengendalikan sejumlah besar permintaan sambungan, setiap sambungan menggunakan lebih banyak memori, dan bekas Servlet lambat untuk menghuraikan protokol HTTP) , jadi anda tidak boleh melakukan caching pada lapisan Java, tetapi Lakukan secara langsung pada lapisan pelayan Web, supaya anda boleh melindungi beberapa kelemahan pada tahap bahasa Java sebagai perbandingan, pelayan Web (seperti Nginx, Apache, Varnish) adalah juga lebih baik dalam mengendalikan permintaan fail statik serentak yang besar.

Cara membuat transformasi pemisahan dinamik dan statik

1. URL Unik
2. Asingkan faktor berkaitan penyemak imbas
3. Faktor masa serantau
Asingkan
5. Alih keluar kuki C
   .

ditambah Lapisan CDN:

Penyelesaian penggunaan CDN juga mempunyai ciri-ciri berikut:

. "butang.

Bagaimana untuk mengendalikan data hotspot dalam sistem jualan kilat?
Apakah itu "hotspot"
3. Hotspot dibahagikan kepada operasi hotspot dan data hotspot.

Apa yang dipanggil "operasi panas", seperti sejumlah besar penyegaran halaman, sejumlah besar menambah troli beli-belah, sejumlah besar pesanan yang dibuat pada 0:00 pada Double Eleven, dll., semuanya termasuk dalam kategori ini . Untuk sistem, operasi ini boleh disarikan kepada "permintaan baca" dan "permintaan tulis". lapisan penyimpanan. Idea pengoptimuman adalah untuk mengimbangi berdasarkan teori CAP Saya akan memperkenalkan kandungan ini secara terperinci dalam artikel "Mengurangkan Inventori".

"data hotspot" lebih mudah difahami, iaitu data yang sepadan dengan permintaan hotspot pengguna. Data hotspot terbahagi kepada "data hotspot statik" dan "data hotspot dinamik".

Apa yang dipanggil "data hotspot statik" merujuk kepada data hotspot yang boleh diramalkan terlebih dahulu. Sebagai contoh, kami boleh menapis penjual terlebih dahulu melalui pendaftaran dan menandakan produk hangat ini melalui sistem pendaftaran. Selain itu, kami juga boleh menggunakan analisis data besar untuk menemui produk hangat lebih awal Contohnya, kami menganalisis rekod transaksi sejarah dan rekod troli beli-belah pengguna untuk mengetahui produk yang mungkin lebih popular dan lebih laris dianalisis terlebih dahulu.

Apa yang dipanggil "data hotspot dinamik" merujuk kepada hotspot yang tidak boleh diramalkan terlebih dahulu dan dijana buat sementara semasa operasi sistem. Sebagai contoh, penjual mengiklankan di Douyin, dan kemudian produk itu menjadi popular serta-merta, menyebabkan ia dibeli dalam kuantiti yang banyak dalam tempoh yang singkat.

Memandangkan operasi hotspot adalah gelagat pengguna, kami tidak boleh mengubahnya, tetapi kami boleh melakukan beberapa sekatan dan perlindungan Oleh itu, dalam artikel ini, saya akan memperkenalkan cara mengoptimumkan data hotspot. Temui data tempat liputan

Cara paling berkesan untuk mengoptimumkan data hotspot ialah dengan cache data hotspot , jika data hotspot diasingkan daripada data statik, data statik boleh dicache untuk masa yang lama. Walau bagaimanapun, caching data hotspot lebih kepada cache "sementara", iaitu, sama ada data statik atau data dinamik, ia dicache secara ringkas dalam baris gilir untuk beberapa saat Memandangkan panjang baris gilir adalah terhad, ia boleh digantikan dengan algoritma penghapusan LRU.

Sekatan

1. Sekatan lebih kepada mekanisme perlindungan, dan terdapat banyak cara untuk menyekatnya Contohnya, lakukan cincangan yang konsisten pada ID produk yang diakses, dan kemudian baldinya berdasarkan cincangan. supaya produk panas boleh Mengehadkannya kepada baris gilir permintaan menghalang produk panas tertentu daripada mengambil terlalu banyak sumber pelayan dan menyebabkan permintaan lain tidak pernah menerima sumber pemprosesan daripada pelayan.

   isolation

   Prinsip pertama Reka Bentuk Sistem Jualan Flash adalah untuk mengasingkan data panas seperti ini. 1% daripada permintaan. Pengasingan boleh dibahagikan kepada: pengasingan perniagaan, pengasingan sistem, dan pengasingan data.

   Bagaimana untuk mengurangkan puncak trafik

   Sama seperti jalan raya di bandar, kerana masalah puncak pagi dan puncak petang, terdapat penyelesaian peralihan puncak dan sekatan lalu lintas.

   Kewujudan keratan puncak boleh, pertama, menjadikan pemprosesan bahagian pelayan lebih stabil, dan kedua, ia dapat menjimatkan kos sumber pelayan.

   Untuk senario jualan kilat, keratan puncak pada asasnya adalah untuk melambatkan pengeluaran permintaan pengguna lebih banyak untuk mengurangkan dan menapis beberapa permintaan yang tidak sah Ia mengikut prinsip "bilangan permintaan hendaklah sekecil mungkin".

   Idea Mencukur Puncak Trafik

   Barisan

   Untuk memuncak trafik, penyelesaian paling mudah untuk difikirkan ialah menggunakan baris gilir mesej untuk menampan trafik serta-merta, menukar panggilan terus segerak kepada pengendalian trafik tidak segera tak segerak memuncak pada satu hujung dan lancar menolak mesej keluar di hujung yang lain.

   Selain baris gilir mesej, terdapat banyak kaedah beratur yang serupa, seperti:

   • Menggunakan kumpulan benang untuk mengunci dan menunggu juga merupakan kaedah baris gilir yang biasa digunakan
   • Kaedah gilir memori yang biasa digunakan seperti pertama- masuk-keluar dahulu dan keluar dahulu-masuk-akhir Pelaksanaan algoritma
   • menyerikan permintaan ke dalam fail, dan kemudian membaca fail secara berurutan (seperti mekanisme penyegerakan berdasarkan binlog MySQL) untuk memulihkan permintaan, dsb.

   Dapat dilihat bahawa kaedah ini mempunyai ciri yang sama, iaitu menukar "operasi satu langkah" kepada "operasi dua langkah", di mana operasi satu langkah tambahan digunakan untuk bertindak sebagai penampan.

   Pengoptimuman prestasi

   Logik teras "Pengurangan inventori"

   Ini sangat penting, semua langkah lain adalah tambahan. Jika ada 100 keping dalam stok, hanya jual 100 keping dan kurangkan kepada 0 dalam pangkalan data. Ya, ini adalah kes dalam teori, tetapi dalam senario perniagaan tertentu, "mengurangkan inventori" bukanlah semudah itu.
   • Apakah cara untuk mengurangkan inventori
   • Klik butang "Beli Sekarang" pada halaman produk, semak maklumat dan klik "Submit Order". Selepas membuat pesanan, anda hanya boleh benar-benar membeli apabila anda menyelesaikan operasi pembayaran, seperti yang dikatakan: "Keselamatan dalam poket".
     Operasi pengurangan inventori secara amnya mempunyai kaedah berikut:

   Pengurangan inventori selepas membuat pesanan

   Iaitu, selepas pembeli membuat pesanan, kuantiti pembelian pembeli akan ditolak daripada jumlah inventori produk. Membuat pesanan untuk mengurangkan inventori adalah cara paling mudah untuk mengurangkan inventori, dan ia juga merupakan kaedah kawalan yang paling tepat Apabila membuat pesanan, inventori barangan dikawal secara langsung melalui mekanisme transaksi pangkalan data, supaya keadaan terlebih jual akan. tidak berlaku. Tetapi anda perlu tahu bahawa sesetengah orang mungkin tidak membayar selepas membuat pesanan. . Walau bagaimanapun, kerana inventori dikurangkan hanya selepas pembayaran dibuat, jika konkurensi agak tinggi, mungkin terdapat situasi di mana pembeli tidak boleh membayar selepas membuat pesanan, kerana barang mungkin telah dibeli oleh orang lain. Kaedah Inventory

   ini agak rumit. pembeli selepas keluaran Anda boleh terus membeli. Sebelum pembeli membayar, sistem akan mengesahkan sama ada inventori pesanan masih dikhaskan: jika tiada tempahan, penahanan akan dicuba semula jika inventori tidak mencukupi (iaitu, penahanan gagal), pembayaran tidak akan dibenarkan untuk meneruskan; jika penahanan berjaya, maka pembayaran selesai dan inventori sebenarnya ditolak.

   Di manakah kita harus bermula dengan pembinaan ketersediaan tinggi

   Bercakap mengenai pembinaan ketersediaan tinggi sistem, ia sebenarnya adalah projek sistem yang perlu mengambil kira semua peringkat pembinaan sistem, yang bermaksud ia benar-benar berjalan melalui keseluruhan kitaran hayat pembinaan sistem , seperti yang ditunjukkan dalam gambar di bawah:

   Fasa Senibina

   Fasa seni bina terutamanya mempertimbangkan kebolehskalaan dan toleransi kesalahan sistem, dan mengelakkan masalah satu titik dalam sistem. Contohnya, dalam penempatan berbilang bilik komputer yang disatukan, walaupun bilik komputer tertentu di bandar tertentu mengalami kegagalan keseluruhan, ia masih tidak akan menjejaskan pengendalian keseluruhan tapak web.

   Fasa pengekodan

   Perkara yang paling penting tentang pengekodan ialah memastikan keteguhan kod Contohnya, apabila ia melibatkan isu panggilan jauh, mekanisme keluar masa yang munasabah mesti disediakan untuk mengelakkan ditimpa oleh sistem lain. , dan set hasil pengembalian panggilan juga mesti dipastikan Untuk mengelakkan hasil yang dikembalikan daripada melebihi julat pemprosesan program, kaedah yang paling biasa adalah untuk menangkap pengecualian ralat dan mempunyai keputusan pemprosesan lalai untuk ralat yang tidak dijangka.

   Fasa ujian

   Pengujian adalah terutamanya untuk memastikan liputan kes ujian dan untuk memastikan bahawa apabila kes terburuk berlaku, kami juga mempunyai prosedur pemprosesan yang sepadan.

   Fasa Pelepasan

   Ada juga beberapa perkara yang perlu diberi perhatian semasa mengeluarkan, kerana ralat berkemungkinan besar berlaku semasa pelepasan, jadi mekanisme rollback kecemasan mesti ada.

   Fasa berjalan

   Masa berjalan adalah keadaan normal sistem pada kebanyakan masa Perkara yang paling penting dalam keadaan berjalan ialah pemantauan sistem mestilah tepat dan Jika masalah ditemui, penggera mestilah tepat dan data penggera mestilah tepat dan terperinci untuk memudahkan penyelesaian masalah.

   Berlaku kerosakan

   Apabila berlaku kerosakan, perkara pertama dan paling penting ialah menghentikan kerugian dalam masa Sebagai contoh, jika harga produk salah kerana masalah program, produk mesti dikeluarkan dari rak atau pautan pembelian mesti ditutup tepat pada masanya untuk mengelakkan kerugian aset yang besar. Maka adalah perlu untuk dapat memulihkan perkhidmatan tepat pada masanya dan mencari punca dan menyelesaikan masalah.

   Bagaimanakah kita harus memaksimumkan operasi biasa sistem kita apabila menghadapi trafik yang sesak?

   Turun taraf

   Apa yang dipanggil "turun taraf" bermakna apabila kapasiti sistem mencapai tahap tertentu, fungsi bukan teras tertentu sistem dihadkan atau ditutup, dengan itu menempah sumber terhad untuk lebih banyak perniagaan teras. Ia adalah proses pelaksanaan yang bertujuan dan terancang, jadi untuk menurunkan taraf kita secara amnya perlu mempunyai satu set rancangan untuk menyelaraskan pelaksanaan. Jika kita mensistemkannya, kita boleh mencapai kemerosotan melalui sistem perancangan dan sistem pensuisan.

   

   Penghadan semasa

   Penghadan semasa bermakna apabila kapasiti sistem mencapai kesesakan, kita perlu melindungi sistem dengan mengehadkan sebahagian daripada trafik, dan bukan sahaja boleh melakukan penukaran manual, tetapi juga menyokong perlindungan automatik langkah-langkah.

   Kelebihan dan keburukan pengehad arus sisi klien dan pengehadan arus sisi pelayan:

   Penghadan arus sisi pelanggan mempunyai kelebihan mengehadkan pengeluaran permintaan dan mengurangkan penggunaan sistem dengan mengurangkan pengeluaran permintaan yang tidak berguna. Kelemahannya ialah apabila pelanggan bertaburan, adalah mustahil untuk menetapkan ambang had arus yang munasabah: jika ambang ditetapkan terlalu kecil, pelanggan akan dihadkan sebelum pelayan mencapai kesesakan jika ia ditetapkan terlalu besar, ia tidak akan berlaku; dapat Peranan sekatan.

   Kelebihan pengehadan semasa sebelah pelayan ialah ambang yang munasabah boleh ditetapkan mengikut prestasi pelayan. Kelemahannya ialah permintaan yang disekat adalah permintaan yang tidak sah, dan memproses permintaan yang tidak sah ini sendiri juga akan menggunakan sumber pelayan.

   

   Algoritma pengehad arus biasa

   Algoritma pembilang (tetingkap tetap)

   Algoritma pembilang menggunakan pembilang untuk mengumpul bilangan lawatan dalam satu kitaran apabila nilai pengehadan semasa yang ditetapkan strategi mengehadkan dicetuskan. Pada permulaan kitaran seterusnya, ia dikosongkan dan dikira semula.

   Algoritma ini sangat mudah untuk dilaksanakan dalam persekitaran yang berdiri sendiri atau diedarkan Ia boleh dilaksanakan dengan mudah menggunakan kenaikan diri atom incr dan keselamatan benang redis.

   Algoritma tetingkap gelongsor

   Algoritma tetingkap gelongsor membahagikan tempoh masa kepada N tempoh kecil, merekodkan bilangan lawatan dalam setiap tempoh kecil dan memadamkan tempoh kecil yang tamat tempoh berdasarkan gelongsor masa. Algoritma ini boleh menyelesaikan masalah kritikal algoritma tetingkap tetap.

   Algoritma Baldi Bocor

   Algoritma Baldi Bocor adalah untuk terus memasukkan permintaan akses ke baldi bocor apabila ia tiba Jika kapasiti semasa telah mencapai had atas (nilai had semasa), ia akan dibuang (mencetuskan arus dasar had). Baldi bocor mengeluarkan permintaan akses (iaitu, permintaan lulus) pada kadar tetap sehingga baldi bocor kosong.

   Algoritma Token Bucket

   Algoritma Token Bucket ialah program menambah token pada baldi token pada kadar r (r=tempoh masa/nilai had semasa) sehingga baldi token penuh, dan menambah token pada token baldi apabila permintaan tiba Token permintaan baldi, jika token diperoleh, permintaan akan diluluskan, jika tidak, dasar had semasa akan dicetuskan

   Penolakan perkhidmatan

   Jika pengehadan semasa tidak dapat menyelesaikan masalah, pilihan terakhir ialah untuk menafikan perkhidmatan secara langsung. Apabila beban sistem mencapai ambang tertentu, contohnya, penggunaan CPU mencapai 90% atau nilai beban sistem mencapai 2*teras CPU, sistem secara langsung menolak semua permintaan Kaedah ini adalah kaedah perlindungan sistem yang paling ganas tetapi juga paling berkesan . Sebagai contoh, untuk sistem jualan kilat, kami mereka bentuk perlindungan lebihan dalam aspek berikut:

   Tetapkan perlindungan lebihan pada Nginx bahagian hadapan Apabila beban mesin mencapai nilai tertentu, permintaan HTTP akan ditolak terus dan ralat 503 kod akan dikembalikan. Perkara yang sama boleh dilakukan pada lapisan Java Designed dengan perlindungan lebihan.

   Penolakan perkhidmatan boleh dikatakan sebagai penyelesaian terakhir untuk mengelakkan senario kes terburuk berlaku dan mengelakkan pelayan tidak dapat memberikan perkhidmatan untuk jangka masa yang lama kerana mengatasi server. Walaupun perlindungan beban lampau sistem seperti ini tidak dapat menyediakan perkhidmatan apabila terlebih beban, sistem masih boleh beroperasi dan boleh pulih dengan mudah apabila beban menurun Oleh itu, setiap sistem dan setiap pautan harus menyediakan pelan sandaran ini untuk menyediakan sistem bagi senario terburuk. di bawah perlindungan.

   Isu cache

   Cache avalanche

   Data tidak dimuatkan ke dalam cache, atau cache gagal di kawasan yang besar pada masa yang sama, menyebabkan semua permintaan untuk mencari pangkalan data, menyebabkan pangkalan data, CPU dan beban memori, atau masa henti.

   Proses longsoran mudah:

   1) Kegagalan berskala besar gugusan Redis

   2) Kegagalan caching, tetapi masih terdapat sejumlah besar permintaan untuk mengakses perkhidmatan cache Redis

   3) Selepas jumlah yang besar daripada kegagalan permintaan Redis, permintaan dialihkan ke pangkalan data

   4) Permintaan pangkalan data meningkat secara mendadak, menyebabkan pangkalan data dimatikan

   5) Memandangkan kebanyakan perkhidmatan aplikasi anda bergantung pada pangkalan data dan perkhidmatan Redis, ia akan segera; menyebabkan runtuhan gugusan pelayan, dan akhirnya keseluruhan sistem akan runtuh sepenuhnya.

   Penyelesaian:

   Sebelum ini : Cache yang sangat tersedia

   Cache yang sangat tersedia adalah untuk mengelakkan keseluruhan cache gagal. Walaupun nod individu, mesin atau bilik komputer ditutup, sistem masih boleh menyediakan perkhidmatan, dan kedua-dua Redis Sentinel dan Redis Cluster boleh mencapai ketersediaan yang tinggi.

   Sedang berlangsung: Turun taraf cache (sokongan sementara)

   Bagaimana kami memastikan perkhidmatan masih tersedia apabila peningkatan mendadak dalam lawatan menyebabkan masalah dengan perkhidmatan. Hystrix, yang digunakan secara meluas di China, menggunakan tiga kaedah: menggabungkan, menurunkan taraf dan mengehadkan semasa untuk mengurangkan kerugian selepas runtuhan salji. Selagi pangkalan data tidak mati, sistem sentiasa boleh bertindak balas terhadap permintaan. Bukankah ini cara kami datang ke sini setiap Festival Musim Bunga 12306? Selagi anda masih boleh membalas, anda sekurang-kurangnya berpeluang untuk merebut tiket. . berbilang benang meminta data tempat liputan pada masa yang sama. Kerana cache baru sahaja tamat tempoh, semua permintaan serentak akan pergi ke pangkalan data untuk menanyakan data.

   Penyelesaian:

   Sebenarnya, dalam kebanyakan senario perniagaan sebenar, pecahan cache berlaku dalam masa nyata, tetapi ia tidak akan menyebabkan terlalu banyak tekanan pada pangkalan data, kerana dalam perniagaan korporat am, jumlah keselarasan tidak akan begitu. tinggi . Sudah tentu, jika anda bernasib malang untuk mengalami perkara ini, anda boleh menetapkan kekunci tempat liputan ini supaya ia tidak akan tamat tempoh. Kaedah lain ialah menggunakan kunci mutex untuk mengawal capaian benang kepada pangkalan data pertanyaan, tetapi ini akan menyebabkan daya pengeluaran sistem berkurangan dan perlu digunakan dalam situasi sebenar.

   Penembusan cache

   Penembusan cache merujuk kepada pertanyaan data yang pasti tidak wujud Kerana tiada maklumat tentang data dalam cache, ia akan pergi terus ke lapisan pangkalan data untuk pertanyaan Dari peringkat sistem seperti penembusan. Lapisan cache terus mencapai db, yang dipanggil penembusan cache Tanpa perlindungan lapisan cache, pertanyaan jenis ini untuk data yang tidak mesti wujud mungkin berbahaya kepada sistem jika seseorang menggunakan data ini secara jahat mesti tidak wujud untuk Permintaan yang kerap kepada sistem, tidak, lebih tepatnya, serangan ke atas sistem, permintaan akan mencapai lapisan pangkalan data, menyebabkan lumpuh db dan kegagalan sistem. . bitmap ini akan digunakan untuk menapis sebelum pertanyaan pangkalan data Jika ia tidak disertakan dalam pertanyaan, ia akan ditapis secara langsung, dengan itu mengurangkan tekanan pada tahap pangkalan data.

   Cache nilai nol: Penyelesaian yang agak mudah ialah meletakkan kunci dan nilai nol yang sepadan (kunci nol atau satu-satunya dalam objek) ke dalam cache selepas menanyakan data yang tidak wujud untuk kali pertama masa tamat tempoh yang lebih pendek, seperti beberapa minit, supaya anda boleh menangani sejumlah besar serangan pada kunci ini dalam tempoh masa yang singkat Sebab untuk menetapkan masa tamat tempoh yang lebih pendek adalah kerana nilai itu mungkin tiada kaitan perniagaan, dan kewujudannya tidak begitu penting. Pertanyaan mungkin tidak dimulakan oleh penyerang, dan tidak perlu menyimpannya untuk masa yang lama, jadi ia boleh dibatalkan lebih awal. . masalah yang mungkin berlaku dalam setiap sistem adalah berbeza.

Atas ialah kandungan terperinci Lebih daripada 6,000 perkataan |. Perkara yang perlu diperhatikan semasa mereka bentuk sistem Flash Kill. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!