12306 rampasan tiket, pemikiran yang ditimbulkan oleh konkurensi yang melampau!-tajuk utama-php.cn

12306 rampasan tiket, pemikiran yang ditimbulkan oleh keadaan yang melampau?

Setiap hari cuti, orang yang pulang ke rumah atau melancong di bandar tingkat pertama dan kedua hampir selalu menghadapi masalah: merebut kereta api Tiket! Walaupun tiket boleh ditempah dalam kebanyakan kes sekarang, saya percaya semua orang mempunyai pemahaman yang mendalam tentang situasi di mana tiket tidak lagi tersedia sebaik sahaja tiket dikeluarkan. Terutama semasa Festival Musim Bunga, orang ramai bukan sahaja menggunakan 12306, tetapi juga mempertimbangkan "Zhixing" dan perisian merebut tiket lain Beratus-ratus juta orang di seluruh negara sedang merebut tiket dalam tempoh ini. "Perkhidmatan 12306" mempunyai QPS yang tidak boleh diatasi oleh mana-mana sistem jualan kilat di dunia. Penulis telah mempelajari secara khusus seni bina pelayan "12306" dan mempelajari banyak sorotan reka bentuk sistemnya Di sini saya akan berkongsi dengan anda dan mensimulasikan contoh: bagaimana untuk menyediakan perkhidmatan biasa apabila 1 juta orang merebut 10,000 tiket kereta api pada masa yang sama. . , perkhidmatan yang stabil. alamat kod github

Cadangan berkaitan: " Puluhan juta penyelesaian konkurensi data (amalan teori) "

1. menyediakan pelbagai kaedah pemulihan bencana (bilik enjin Bomba dwi, toleransi kerosakan nod, pemulihan bencana pelayan, dll.) memastikan ketersediaan sistem yang tinggi, dan trafik akan diseimbangkan ke pelayan yang berbeza berdasarkan keupayaan beban dan strategi konfigurasi yang berbeza. Berikut ialah rajah skematik ringkas:

12306 rampasan tiket, pemikiran yang ditimbulkan oleh konkurensi yang melampau! 1.1 Pengenalan kepada pengimbangan beban

Rajah di atas menerangkan tiga langkah yang diminta pengguna kepada pelayan melalui pengimbangan beban lapisan, di bawah ialah pengenalan ringkas kepada tiga jenis pengimbangan beban ini:

OSPF (Buka Pautan Terpendek Pertama) ialah Protokol Gerbang Dalaman (IGP) . OSPF mewujudkan pangkalan data keadaan pautan dengan mengiklankan status antara muka rangkaian antara penghala dan menjana pepohon laluan terpendek secara automatik akan mengira nilai Kos pada antara muka penghalaan, tetapi anda juga boleh menentukan nilai Kos antara muka yang ditentukan secara manual satu diutamakan nilai dikira secara automatik. Kos yang dikira oleh OSPF juga berkadar songsang dengan lebar jalur antara muka Lebih tinggi lebar jalur, lebih kecil nilai Kos. Laluan dengan nilai Kos yang sama kepada sasaran boleh melakukan pengimbangan beban dan sehingga 6 pautan boleh melakukan pengimbangan beban pada masa yang sama.

LVS (Linux VirtualServer), iaitu teknologi kluster yang menggunakan teknologi pengimbangan beban IP dan teknologi pengedaran permintaan berasaskan kandungan. Penjadual mempunyai kadar pemprosesan yang sangat baik dan memindahkan permintaan secara sekata kepada pelayan yang berbeza untuk pelaksanaan, dan penjadual secara automatik melindungi kegagalan pelayan, dengan itu membentuk sekumpulan pelayan menjadi pelayan maya berprestasi tinggi dan tersedia.
Nginx mesti biasa kepada semua orang Ia adalah pelayan proksi/proksi terbalik berprestasi tinggi Ia juga sering digunakan untuk pengimbangan beban dalam pembangunan perkhidmatan. Terdapat tiga cara utama untuk Nginx mencapai pengimbangan beban: tinjauan pendapat, tinjauan berwajaran dan tinjauan cincang ip Di bawah kami akan melakukan konfigurasi dan ujian khas untuk tinjauan berwajaran Nginx

Nginx melaksanakan pengimbangan beban melalui modul huluan Konfigurasi tinjauan berwajaran boleh menambah nilai berat kepada perkhidmatan yang berkaitan pelayan menetapkan beban yang sepadan. Berikut ialah konfigurasi beban undian berwajaran saya akan mendengar port 3001-3004 secara setempat dan mengkonfigurasi pemberat 1, 2, 3 dan 4 masing-masing:

Salin kod ke /etc tempatan saya. / Alamat nama domain maya www.load_balance.com dikonfigurasikan dalam direktori hos Seterusnya, gunakan bahasa Go untuk membuka empat perkhidmatan mendengar port http Berikut ialah program Go pada port 3001. Beberapa yang lain hanya perlu mengubah suai port:

#配置负载均衡
    upstream load_rule {
       server 127.0.0.1:3001 weight=1;
       server 127.0.0.1:3002 weight=2;
       server 127.0.0.1:3003 weight=3;
       server 127.0.0.1:3004 weight=4;
    }
    ...
    server {
    listen       80;
    server_name  load_balance.com www.load_balance.com;
    location / {
       proxy_pass http://load_rule;
    }
}

Salin selepas log masuk

Saya menulis maklumat log port yang diminta ke dalam fail ./stat.log, dan kemudian menggunakan alat ujian tekanan ab untuk melakukan ujian tekanan:

package main

import (
"net/http"
"os"
"strings"
)

func main() {
http.HandleFunc("/buy/ticket", handleReq)
http.ListenAndServe(":3001", nil)
}

//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
failedMsg :=  "handle in port:"
writeLog(failedMsg, "./stat.log")
}

//写入日志
func writeLog(msg string, logPath string) {
fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
defer fd.Close()
content := strings.Join([]string{msg, "\r\n"}, "3001")
buf := []byte(content)
fd.Write(buf)
}

Salin selepas log masuk

Hasil dalam log statistik, 3001 Port -3004 menerima permintaan masing-masing 100, 200, 300, dan 400, yang konsisten dengan nisbah berat yang saya konfigurasikan dalam nginx, dan trafik selepas beban adalah sangat sekata dan rawak. Untuk pelaksanaan khusus, anda boleh merujuk kepada kod sumber pelaksanaan modul wap nginx Berikut adalah artikel yang disyorkan: Pengimbangan beban mekanisme huluan dalam Nginx

ab -n 1000 -c 100 http://www.load_balance.com/buy/ticket

Salin selepas log masuk

2. Pemilihan sistem jualan kilat

Berbalik kepada soalan asal kami: Bagaimanakah sistem jualan kilat tiket kereta api boleh menyediakan perkhidmatan biasa dan stabil dalam keadaan serentak yang tinggi?

Daripada pengenalan di atas, kami tahu bahawa trafik jualan kilat pengguna diagihkan secara sama rata kepada pelayan yang berbeza melalui lapisan pengimbangan beban. Walaupun begitu, QPS yang ditanggung oleh satu mesin dalam kelompok juga sangat tinggi. Bagaimana untuk mengoptimumkan prestasi bersendirian secara melampau? Untuk menyelesaikan masalah ini, kita perlu memahami satu perkara:

Biasanya sistem tempahan tiket perlu memproses tiga peringkat asas: penjanaan pesanan, pengurangan inventori dan pembayaran pengguna Apa yang perlu dilakukan oleh sistem kami adalah untuk memastikan pesanan tiket kereta api tidak terjual terlebih dahulu atau terkurang jualan, dan setiap tiket terjual Semua. mesti dibayar untuk menjadi berkesan, dan sistem mesti dijamin untuk menahan konkurensi yang sangat tinggi. Bagaimanakah susunan ketiga-tiga peringkat ini boleh diubah dengan cara yang lebih munasabah Mari kita analisanya:

2.1 Buat pesanan untuk mengurangkan inventori

Apabila permintaan pengguna serentak tiba? di pelayan Apabila , mula-mula buat pesanan, kemudian tolak inventori dan tunggu pembayaran pengguna. Pesanan ini merupakan penyelesaian pertama yang kebanyakan kita akan fikirkan Dalam kes ini, ia juga boleh memastikan pesanan tidak akan terlebih jual, kerana inventori akan dikurangkan selepas pesanan dibuat, yang merupakan operasi atom. Walau bagaimanapun, ini juga akan menyebabkan beberapa masalah Yang pertama ialah di bawah keadaan konkurensi yang melampau, butiran sebarang operasi memori akan menjejaskan prestasi dengan ketara, terutamanya logik seperti membuat pesanan, yang secara amnya perlu disimpan dalam pangkalan data cakera, yang memberikan tekanan. pada pangkalan data. Ia boleh difikirkan; yang kedua ialah jika pengguna membuat pesanan secara jahat dan hanya membuat pesanan tanpa membayar, inventori akan berkurangan dan banyak pesanan akan dijual lebih sedikit daripada pesanan pembelian pengguna, Ini juga bukan pendekatan yang baik.