12306 Ticketraub, Gedanken hervorgerufen durch extreme Parallelität!

12306 Fahrkartenraub, Gedanken, die durch extreme Parallelität entstehen?

An jedem Feiertag stehen Menschen, die nach Hause zurückkehren oder zum Spaß in Städten der ersten und zweiten Reihe ausgehen, fast immer vor einem Problem: Zugtickets zu ergattern, allerdings in den meisten Fällen! Nun, ich glaube, jeder kennt die Situation, ein Ticket zu buchen, es aber zu verlieren, sobald das Ticket freigegeben wird. Besonders während des Frühlingsfestes nutzen die Menschen nicht nur 12306, sondern ziehen auch „Zhixing“ und andere Ticket-Grabber-Software in Betracht. Hunderte Millionen Menschen im ganzen Land schnappen sich in dieser Zeit Tickets. Der „12306-Dienst“ verfügt über einen QPS, der von keinem Flash-Sale-System der Welt übertroffen werden kann. Millionen von Parallelität sind nichts anderes als normal! Der Autor hat speziell die Serverarchitektur von „12306“ untersucht und viele Highlights seines Systemdesigns kennengelernt. Hier werde ich ein Beispiel mit Ihnen teilen und simulieren: Wie kann ein normaler Dienst bereitgestellt werden, wenn 1 Million Menschen gleichzeitig 10.000 Bahntickets ergattern . , stabiler Dienst. Github-Codeadresse

Verwandte Empfehlungen: „Millionen von Daten-Parallelitätslösungen (Theorie + Praxis)“

1. Groß angelegte Systemarchitektur mit hoher Parallelität

Systemarchitektur mit hoher Parallelität wird verwendet Bei der Verteilungsclusterbereitstellung verfügt die obere Schicht des Dienstes über einen schichtweisen Lastausgleich und bietet verschiedene Möglichkeiten zur Notfallwiederherstellung (Dual-Fire-Computerraum, Knotenfehlertoleranz, Server-Notfallwiederherstellung usw.), um die hohe Verfügbarkeit des Systems sicherzustellen , und der Datenverkehr wird je nach unterschiedlichen Lastkapazitäten und Konfigurationsstrategien auf einen anderen Server verteilt. Das Folgende ist ein einfaches schematisches Diagramm:

1.1 Einführung in den Lastausgleich

Die obige Abbildung beschreibt, dass Benutzeranfragen an den Server drei Ebenen des Lastausgleichs durchlaufen haben. Im Folgenden finden Sie eine kurze Einführung in diese drei Typen des Lastausgleichs:

• OSPF (Open Shortest Link First) ist ein Interior Gateway Protocol (kurz IGP). OSPF erstellt eine Verbindungsstatusdatenbank, indem es den Status von Netzwerkschnittstellen zwischen Routern bekannt gibt und einen kürzesten Pfadbaum generiert. OSPF berechnet automatisch den Kostenwert auf der Routing-Schnittstelle. Sie können den Kostenwert der Schnittstelle jedoch auch manuell angeben Einer hat Vorrang. Automatisch berechneter Wert. Die von OSPF berechneten Kosten sind auch umgekehrt proportional zur Schnittstellenbandbreite. Je höher die Bandbreite, desto kleiner ist der Kostenwert. Pfade mit demselben Kostenwert zum Ziel können einen Lastausgleich durchführen, und bis zu 6 Links können gleichzeitig einen Lastausgleich durchführen.

• LVS (Linux VirtualServer) ist eine Cluster-Technologie (Cluster), die IP-Lastausgleichstechnologie und inhaltsbasierte Anforderungsverteilungstechnologie verwendet. Der Scheduler verfügt über eine sehr gute Durchsatzrate und überträgt Anforderungen gleichmäßig zur Ausführung an verschiedene Server. Der Scheduler schirmt Serverausfälle automatisch ab und bildet so eine Gruppe von Servern zu einem leistungsstarken, hochverfügbaren virtuellen Server.

• Jeder muss mit Nginx vertraut sein. Es handelt sich um einen sehr leistungsstarken HTTP-Proxy/Reverse-Proxy-Server. Er wird auch häufig für den Lastausgleich in der Dienstentwicklung verwendet. Es gibt drei Hauptmethoden für Nginx, um den Lastausgleich zu implementieren: Abfrage, gewichtete Abfrage und IP-Hash-Abfrage. Im Folgenden werden wir die gewichtete Abfrage von Nginx speziell konfigurieren und testen. 1.2 Demonstration der gewichteten Abfrage von Nginx Lastausgleich über das Upstream-Modul. Die gewichtete Polling-Konfiguration kann den relevanten Diensten einen Gewichtungswert hinzufügen. Bei der Konfiguration kann die entsprechende Last entsprechend der Leistung und Lastkapazität des Servers festgelegt werden. Das Folgende ist eine gewichtete Polling-Lastkonfiguration. Ich werde die Ports 3001–3004 lokal abhören und die Gewichtungen 1, 2, 3 bzw. 4 konfigurieren:

  #配置负载均衡
      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;
      }
  }

Kopieren Sie den Code, den ich im lokalen Verzeichnis /etc/hosts konfiguriert habe .load_balance.com virtuelle Domänennamenadresse, dann verwenden Sie die Go-Sprache, um vier HTTP-Port-Abhördienste zu öffnen. Das Folgende ist das Go-Programm, das Port 3001 abhört. Die anderen Ports müssen nur geändert werden:

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)
}

Der Port, den ich anfordern werde Protokollinformationen werden in die Datei ./stat.log geschrieben, und dann wird das Stresstest-Tool ab für den Stresstest verwendet:

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

Die Ergebnisse im statistischen Protokoll zeigen, dass die Ports 3001–3004 100, 200, 300 und 400 empfangen haben Anfragen bzw. Das stimmt gut mit dem Gewichtsverhältnis überein, das ich in Nginx konfiguriert habe, und der Datenverkehr nach dem Laden ist sehr gleichmäßig und zufällig. Informationen zur spezifischen Implementierung finden Sie im Quellcode der Upstream-Modulimplementierung von Nginx. Hier ist ein empfohlener Artikel: Load Balancing des Upstream-Mechanismus in Nginx

2Zurück zu den Fragen, die wir ursprünglich erwähnt haben : Wie bietet das Flash-Sale-System für Bahntickets normale und stabile Dienste unter Bedingungen hoher Parallelität?

Aus der obigen Einführung wissen wir, dass der Benutzer-Flash-Sale-Verkehr durch Lastausgleichsebenen gleichmäßig auf verschiedene Server verteilt wird. Dennoch ist die von einer einzelnen Maschine im Cluster ausgehaltene QPS ebenfalls sehr hoch. Wie kann die Standalone-Leistung aufs Äußerste optimiert werden? Um dieses Problem zu lösen, müssen wir eines verstehen:

Normalerweise muss das Ticketbuchungssystem drei grundlegende Phasen verarbeiten: Auftragsgenerierung, Bestandsreduzierung und Benutzerzahlung. Unser System muss sicherstellen, dass Bestellungen von Bahntickets nicht über- oder unterverkauft werden Um effektiv zu sein, muss das System einer extrem hohen Parallelität standhalten. Wie kann die Reihenfolge dieser drei Phasen sinnvoller geändert werden? Lassen Sie es uns analysieren:

2.1 Geben Sie eine Bestellung auf, um den Lagerbestand zu reduzieren.

Wenn die gleichzeitige Anfrage des Benutzers den Server erreicht, wird zuerst die Bestellung erstellt und dann der Lagerbestand wird abgezogen und wartet auf die Bezahlung durch den Benutzer. Diese Bestellung ist die erste Lösung, an die die meisten von uns denken werden. In diesem Fall kann sie auch sicherstellen, dass die Bestellung nicht überverkauft wird, da der Lagerbestand nach der Erstellung der Bestellung reduziert wird, was ein atomarer Vorgang ist. Dies führt jedoch auch zu einigen Problemen. Das erste besteht darin, dass unter extremen Parallelitätsbedingungen die Details jeder Speicheroperation die Leistung erheblich beeinträchtigen, insbesondere die Logik wie das Erstellen von Bestellungen, die im Allgemeinen in einer Festplattendatenbank gespeichert werden muss, was Druck ausübt In der Datenbank ist es denkbar, dass sich der Lagerbestand verringert und viele Bestellungen weniger verkauft werden, wenn der Benutzer böswillig eine Bestellung aufgibt Benutzerbestellungen. Auch dies ist kein guter Ansatz.

2.2 Reduzieren Sie den Lagerbestand durch Bezahlen

Wenn Sie darauf warten, dass der Benutzer die Bestellung bezahlt und den Lagerbestand reduziert, ist das erste Gefühl, dass es keinen geringeren Umsatz geben wird. Dies ist jedoch ein Tabu der gleichzeitigen Architektur, da Benutzer unter extremen Parallelitätsbedingungen möglicherweise viele Bestellungen erstellen. Wenn der Lagerbestand auf Null reduziert wird, stellen viele Benutzer fest, dass sie die erfassten Bestellungen nicht bezahlen können „überverkauft“. Der gleichzeitige Betrieb von Datenbank-Festplatten-E/A kann nicht vermieden werden. Gibt es also eine Lösung, die keinen direkten Betrieb der Datenbank-E/A erfordert? Dies ist die Zurückhaltung des Inventars. Zuerst wird der Lagerbestand abgezogen, um sicherzustellen, dass er nicht überverkauft wird, und dann werden Benutzerbestellungen asynchron generiert, sodass die Reaktion der Benutzer viel schneller erfolgt. Wie kann also sichergestellt werden, dass es viele Verkäufe gibt? Was sollte der Benutzer tun, wenn er nach Erhalt der Bestellung nicht bezahlt? Wir alle wissen, dass Bestellungen jetzt eine Gültigkeitsdauer haben, wenn der Benutzer beispielsweise nicht innerhalb von fünf Minuten bezahlt. Sobald die Bestellung abläuft, wird auch von vielen Online-Einzelhändlern eine neue Lösung übernommen Unternehmen stellen sicher, dass sie viele Waren verkaufen. Bestellungen werden asynchron generiert und im Allgemeinen in Instant-Consuming-Warteschlangen wie MQ und Kafka verarbeitet. Wenn das Bestellvolumen relativ klein ist, werden Bestellungen sehr schnell generiert und Benutzer müssen kaum anstehen.

3. Die Kunst, Lagerbestände einzubehalten

Aus der obigen Analyse geht hervor, dass die Lösung, Lagerbestände einzubehalten, die vernünftigste ist. Lassen Sie uns die Details des Bestandsabzugs weiter analysieren. Es gibt noch viel Raum für Optimierung. Wie kann bei hoher Parallelität ein korrekter Bestandsabzug und eine schnelle Reaktion auf Benutzeranfragen sichergestellt werden?

Bei geringer Parallelität auf einer einzelnen Maschine implementieren wir den Bestandsabzug normalerweise wie folgt:

Um die Atomizität des Bestandsabzugs und der Generierung von Bestellungen sicherzustellen, muss dann die Transaktionsverarbeitung verwendet werden Der Bestand wird beurteilt, der Bestand wird reduziert und schließlich wird die Transaktion übermittelt. Der gesamte Prozess weist viele E/A auf und der Betrieb der Datenbank wird blockiert. Diese Methode ist überhaupt nicht für Flash-Sales-Systeme mit hoher Parallelität geeignet.

Als nächstes optimieren wir den Bestandsabzugsplan für einzelne Maschinen:

Lokaler Bestandsabzug

. Wir weisen der lokalen Maschine eine bestimmte Menge an Lagerbeständen zu, reduzieren die Lagerbestände direkt im Speicher und erstellen dann asynchron eine Bestellung gemäß der vorherigen Logik. Das verbesserte Standalone-System sieht so aus:

这样就避免了对数据库频繁的IO操作，只在内存中做运算，极大的提高了单机抗并发的能力。但是百万的用户请求量单机是无论如何也抗不住的，虽然nginx处理网络请求使用epoll模型，c10k的问题在业界早已得到了解决。但是linux系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。上面我们提到了nginx的加权均衡策略，我们不妨假设将100W的用户请求量平均均衡到100台服务器上，这样单机所承受的并发量就小了很多。然后我们每台机器本地库存100张火车票，100台服务器上的总库存还是1万，这样保证了库存订单不超卖,下面是我们描述的集群架构:

问题接踵而至，在高并发情况下，现在我们还无法保证系统的高可用，假如这100台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存。有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的“buffer库存”用来防止机器中有机器宕机的情况。我们结合下面架构图具体分析一下:

我们采用Redis存储统一库存，因为Redis的性能非常高，号称单机QPS能抗10W的并发。在本地减库存以后，如果本地有订单，我们再去请求redis远程减库存，本地减库存和远程减库存都成功了，才返回给用户抢票成功的提示,这样也能有效的保证订单不会超卖。当机器中有机器宕机时，因为每个机器上有预留的buffer余票，所以宕机机器上的余票依然能够在其他机器上得到弥补，保证了不少卖。buffer余票设置多少合适呢，理论上buffer设置的越多，系统容忍宕机的机器数量就越多，但是buffer设置的太大也会对redis造成一定的影响。虽然redis内存数据库抗并发能力非常高，请求依然会走一次网络IO,其实抢票过程中对redis的请求次数是本地库存和buffer库存的总量，因为当本地库存不足时，系统直接返回用户“已售罄”的信息提示，就不会再走统一扣库存的逻辑，这在一定程度上也避免了巨大的网络请求量把redis压跨，所以buffer值设置多少，需要架构师对系统的负载能力做认真的考量。

4. 代码演示

Go语言原生为并发设计，我采用go语言给大家演示一下单机抢票的具体流程。

4.1 初始化工作

go包中的init函数先于main函数执行，在这个阶段主要做一些准备性工作。我们系统需要做的准备工作有：初始化本地库存、初始化远程redis存储统一库存的hash键值、初始化redis连接池；另外还需要初始化一个大小为1的int类型chan,目的是实现分布式锁的功能，也可以直接使用读写锁或者使用redis等其他的方式避免资源竞争,但使用channel更加高效，这就是go语言的哲学：不要通过共享内存来通信，而要通过通信来共享内存。redis库使用的是redigo，下面是代码实现:

...
//localSpike包结构体定义
package localSpike

type LocalSpike struct {
LocalInStock     int64
LocalSalesVolume int64
}
...
//remoteSpike对hash结构的定义和redis连接池
package remoteSpike
//远程订单存储健值
type RemoteSpikeKeys struct {
SpikeOrderHashKey string //redis中秒杀订单hash结构key
TotalInventoryKey string //hash结构中总订单库存key
QuantityOfOrderKey string //hash结构中已有订单数量key
}

//初始化redis连接池
func NewPool() *redis.Pool {
return &redis.Pool{
MaxIdle:   10000,
MaxActive: 12000, // max number of connections
Dial: func() (redis.Conn, error) {
c, err := redis.Dial("tcp", ":6379")
if err != nil {
panic(err.Error())
}
return c, err
},
}
}
...
func init() {
localSpike = localSpike2.LocalSpike{
LocalInStock:     150,
LocalSalesVolume: 0,
}
remoteSpike = remoteSpike2.RemoteSpikeKeys{
SpikeOrderHashKey:  "ticket_hash_key",
TotalInventoryKey:  "ticket_total_nums",
QuantityOfOrderKey: "ticket_sold_nums",
}
redisPool = remoteSpike2.NewPool()
done = make(chan int, 1)
done <- 1
}

4.2 本地扣库存和统一扣库存

本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回bool值:

package localSpike
//本地扣库存,返回bool值
func (spike *LocalSpike) LocalDeductionStock() bool{
spike.LocalSalesVolume = spike.LocalSalesVolume + 1
return spike.LocalSalesVolume < spike.LocalInStock
}

注意这里对共享数据LocalSalesVolume的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用channel来实现，这块后边会讲。统一扣库存操作redis，因为redis是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合lua脚本打包命令，保证操作的原子性:

package remoteSpike
......
const LuaScript = `
        local ticket_key = KEYS[1]
        local ticket_total_key = ARGV[1]
        local ticket_sold_key = ARGV[2]
        local ticket_total_nums = tonumber(redis.call('HGET', ticket_key, ticket_total_key))
        local ticket_sold_nums = tonumber(redis.call('HGET', ticket_key, ticket_sold_key))
-- 查看是否还有余票,增加订单数量,返回结果值
       if(ticket_total_nums >= ticket_sold_nums) then
            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)
        end
        return 0
`
//远端统一扣库存
func (RemoteSpikeKeys *RemoteSpikeKeys) RemoteDeductionStock(conn redis.Conn) bool {
lua := redis.NewScript(1, LuaScript)
result, err := redis.Int(lua.Do(conn, RemoteSpikeKeys.SpikeOrderHashKey, RemoteSpikeKeys.TotalInventoryKey, RemoteSpikeKeys.QuantityOfOrderKey))
if err != nil {
return false
}
return result != 0
}

我们使用hash结构存储总库存和总销量的信息,用户请求过来时，判断总销量是否大于库存，然后返回相关的bool值。在启动服务之前，我们需要初始化redis的初始库存信息:

 hmset ticket_hash_key "ticket_total_nums" 10000 "ticket_sold_nums" 0

4.3 响应用户信息

我们开启一个http服务，监听在一个端口上:

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

上面我们做完了所有的初始化工作，接下来handleReq的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。

package main
//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
redisConn := redisPool.Get()
LogMsg := ""
<-done
//全局读写锁
if localSpike.LocalDeductionStock() && remoteSpike.RemoteDeductionStock(redisConn) {
util.RespJson(w, 1,  "抢票成功", nil)
LogMsg = LogMsg + "result:1,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)
} else {
util.RespJson(w, -1, "已售罄", nil)
LogMsg = LogMsg + "result:0,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)
}
done <- 1

//将抢票状态写入到log中
writeLog(LogMsg, "./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"}, "")
buf := []byte(content)
fd.Write(buf)
}

前边提到我们扣库存时要考虑竞态条件，我们这里是使用channel避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了./stat.log文件方便做压测统计。

4.4 单机服务压测

开启服务，我们使用ab压测工具进行测试：

ab -n 10000 -c 100 http://127.0.0.1:3005/buy/ticket

下面是我本地低配mac的压测信息

This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:
Server Hostname:        127.0.0.1
Server Port:            3005

Document Path:          /buy/ticket
Document Length:        29 bytes

Concurrency Level:      100
Time taken for tests:   2.339 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      1370000 bytes
HTML transferred:       290000 bytes
Requests per second:    4275.96 [#/sec] (mean)
Time per request:       23.387 [ms] (mean)
Time per request:       0.234 [ms] (mean, across all concurrent requests)
Transfer rate:          572.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8  14.7      6     223
Processing:     2   15  17.6     11     232
Waiting:        1   11  13.5      8     225
Total:          7   23  22.8     18     239

Percentage of the requests served within a certain time (ms)
  50%     18
  66%     24
  75%     26
  80%     28
  90%     33
  95%     39
  98%     45
  99%     54
 100%    239 (longest request)

根据指标显示，我单机每秒就能处理4000+的请求，正常服务器都是多核配置，处理1W+的请求根本没有问题。而且查看日志发现整个服务过程中，请求都很正常，流量均匀，redis也很正常：

//stat.log
...
result:1,localSales:145
result:1,localSales:146
result:1,localSales:147
result:1,localSales:148
result:1,localSales:149
result:1,localSales:150
result:0,localSales:151
result:0,localSales:152
result:0,localSales:153
result:0,localSales:154
result:0,localSales:156
...

5.总结回顾

总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略，完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户,还有用户在订单有效期内不支付，释放订单，补充到库存等等。

我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对DB数据库IO的操作，对Redis网络IO的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。我觉得其中有两点特别值得学习总结：

• 负载均衡，分而治之。通过负载均衡，将不同的流量划分到不同的机器上，每台机器处理好自己的请求，将自己的性能发挥到极致，这样系统的整体也就能承受极高的并发了，就像工作的的一个团队，每个人都将自己的价值发挥到了极致，团队成长自然是很大的。

• 合理的使用并发和异步。自epoll网络架构模型解决了c10k问题以来，异步越来被服务端开发人员所接受，能够用异步来做的工作，就用异步来做，在功能拆解上能达到意想不到的效果，这点在nginx、node.js、redis上都能体现，他们处理网络请求使用的epoll模型，用实践告诉了我们单线程依然可以发挥强大的威力。服务器已经进入了多核时代，go语言这种天生为并发而生的语言，完美的发挥了服务器多核优势，很多可以并发处理的任务都可以使用并发来解决，比如go处理http请求时每个请求都会在一个goroutine中执行，总之:怎样合理的压榨CPU,让其发挥出应有的价值，是我们一直需要探索学习的方向。

原文链接：https://juejin.cn/post/6844903949632274445