春运夺票，12306的架构到底有多牛？
固然如今大大都情状下都能订到票，但是放票霎时即无票的场景，相信各人都深有体味。
出格是春节期间，各人不只利用 12306，还会考虑“智行”和其他的夺票软件，全国上下几亿人在那段时间都在夺票。
“12306 办事”承担着那个世界上任何秒杀系统都无法超越的 QPS，上百万的并发再一般不外了！
笔者专门研究了一下“12306”的办事端架构，进修到了其系统设想上良多亮点，在那里和各人分享一下并模仿一个例子：若何在 100 万人同时夺 1 万张火车票时，系统供给一般、不变的办事。
Github代码地址：
大型高并发系统架构
高并发的系统架构城市摘用散布式集群摆设，办事上层有着层层负载平衡，并供给各类容灾手段（双火机房、节点容错、办事器灾备等）包管系统的高可用，流量也会根据差别的负载才能和设置装备摆设战略平衡到差别的办事器上。
下边是一个简单的示企图：
负载平衡简介
上图中描述了用户恳求到办事器履历了三层的负载平衡，下边别离简单介绍一下那三种负载平衡。
①OSPF（开放式最短链路优先）是一个内部网关协议（Interior Gateway Protocol，简称 IGP）
OSPF 通过路由器之间布告收集接口的形态来成立链路形态数据库，生成最短途径树，OSPF 会主动计算路由接口上的 Cost 值，但也能够通过手工指定该接口的 Cost 值，手工指定的优先于主动计算的值。
展开全文
OSPF 计算的 Cost，同样是和接口带宽成反比，带宽越高，Cost 值越小。抵达目标不异 Cost 值的途径，能够施行负载平衡，最多 6 条链路同时施行负载平衡。
②LVS （Linux Virtual Server）
它是一种集群（Cluster）手艺，摘用 IP 负载平衡手艺和基于内容恳求分发手艺。
调度器具有很好的吞吐率，将恳求平衡地转移到差别的办事器上施行，且调度器主动屏障掉办事器的毛病，从而将一组办事器构成一个高性能的、高可用的虚拟办事器。
③Nginx
想必各人都很熟悉了，是一款十分高性能的 HTTP 代办署理/反向代办署理办事器，办事开发中也经常利用它来做负载平衡。
Nginx 实现负载平衡的体例次要有三种：
轮询
加权轮询
IP Hash 轮询
下面我们就针对 Nginx 的加权轮询做专门的设置装备摆设和测试。
Nginx 加权轮询的演示
Nginx 实现负载平衡通过 Upstream 模块实现，此中加权轮询的设置装备摆设是能够给相关的办事加上一个权重值，设置装备摆设的时候可能根据办事器的性能、负载才能设置响应的负载。
下面是一个加权轮询负载的设置装备摆设，我将在当地的监听 3001-3004 端口，别离设置装备摆设 1，2，3，4 的权重：
#设置装备摆设负载平衡
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 ;
location / {
proxy_pass ;
我在当地 /etc/hosts 目次下设置装备摆设了 的虚拟域名地址。
接下来利用 Go 语言开启四个 法式，其他几个只需要修改端口即可：
package main
import (
"net/http"
"os"
"strings"
func main() {
)
)
//处置恳求函数,根据恳求将响应成果信息写进日记
func handleReq(w ) {
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)
我将恳求的端口日记信息写到了 ./stat.log 文件傍边，然后利用 AB 压测东西做压测：
ab -n 1000 -c 100
统计日记中的成果，3001-3004 端口别离得到了 100、200、300、400 的恳求量。
那和我在 Nginx 中设置装备摆设的权重占比很好的吻合在了一路，而且负载后的流量十分的平均、随机。
详细的实现各人能够参考 Nginx 的 Upsteam 模块实现源码，那里选举一篇文章《Nginx 中 Upstream 机造的负载平衡》：
秒杀夺购系统选型
回到我们最后提到的问题中来：火车票秒杀系统若何在高并发情状下供给一般、不变的办事呢？
从上面的介绍我们晓得用户秒杀流量通过层层的负载平衡，平均到了差别的办事器上，即便如斯，集群中的单机所承担的 QPS 也长短常高的。若何将单机性能优化到极致呢？
要处理那个问题，我们就要想大白一件事：凡是订票系统要处置生成订单、减扣库存、用户付出那三个根本的阶段。
我们系统要做的工作是要包管火车票订单不超卖、很多卖，每张售卖的车票都必需付出才有效，还要包管系统承担极高的并发。
那三个阶段的先后挨次该怎么分配才愈加合理呢？我们来阐发一下：
下单减库存
当用户并发恳求抵达办事端时，起首创建订单，然后扣除库存，期待用户付出。
那种挨次是我们一般人起首会想到的处理计划，那种情状下也能包管订单不会超卖，因为创建订单之后就会减库存，那是一个原子操做。
但是如许也会产生一些问题：
在极限并发情状下，任何一个内存操做的细节都至关影响性能，出格像创建订单那种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的。
假设用户存在歹意下单的情状，只下单不付出如许库存就会变少，会少卖良多订单，固然办事端能够限造 IP 和用户的购置订单数量，那也不算是一个好办法。
付出减库存
假设期待用户付出了订单在减库存，第一觉得就是不会少卖。但是那是并发架构的大忌，因为在极限并发情状下，用户可能会创建良多订单。
当库存减为零的时候良多用户发现夺到的订单付出不了了，那也就是所谓的“超卖”。也不克不及制止并发操做数据库磁盘 IO。
预扣库存
从上边两种计划的考虑，我们能够得出结论：只要创建订单，就要频繁操做数据库 IO。
那么有没有一种不需要间接操做数据库 IO 的计划呢，那就是预扣库存。先扣除了库存，包管不超卖，然后异步生成用户订单，如许响应给用户的速度就会快良多；那么怎么包管很多卖呢？用户拿到了订单，不付出怎么办？
我们都晓得如今订单都有有效期，好比说用户五分钟内不付出，订单就失效了，订单一旦失效，就会加进新的库存，那也是如今良多网上零售企业包管商品很多卖摘用的计划。
订单的生成是异步的，一般城市放到 MQ、Kafka 如许的立即消费队列中处置，订单量比力少的情状下，生成订单十分快，用户几乎不消列队。
扣库存的艺术
从上面的阐发可知，显然预扣库存的计划最合理。我们进一步阐发扣库存的细节，那里还有很大的优化空间，库存存在哪里？如何包管高并发下，准确的扣库存，还能快速的响利用户恳求？
在单机低并发情状下，我们实现扣库存凡是是如许的：
为了包管扣库存和生成订单的原子性，需要摘用事务处置，然后取库存揣度、减库存，最初提交事务，整个流程有良多 IO，对数据库的操做又是阻塞的。
那种体例底子不合适高并发的秒杀系统。接下来我们对单机扣库存的计划做优化：当地扣库存。
我们把必然的库存量分配到当地机器，间接在内存中减库存，然后根据之前的逻辑异步创建订单。
改进过之后的单机系统是如许的：
如许就制止了对数据库频繁的 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 值设置几，需要架构师对系统的负载才能做认实的考量。
代码演示
Go 语言原生为并发设想，我摘用 Go 语言给各人演示一下单机夺票的详细流程。
初始化工做
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
当地扣库存和同一扣库存
当地扣库存逻辑十分简单，用户恳求过来，添加销量，然后比照销量能否大于当地库存，返回 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
响利用户信息
我们开启一个 HTTP 办事，监听在一个端口上：
package main
func main() {
)
)
上面我们做完了所有的初始化工做，接下来 handleReq 的逻辑十分清晰，揣度能否夺票胜利，返回给用户信息就能够了。
package main
//处置恳求函数,根据恳求将响应成果信息写进日记
func handleReq(w ) {
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 文件便利做压测统计。
单机办事压测
开启办事，我们利用 AB 压测东西停止测试：
ab -n 10000 -c 100
下面是我当地低配 Mac 的压测信息：
This is ApacheBench, Version 2.3 $revision: 1826891=""
Copyright 1996 Adam Twiss, Zeus Technology Ltd, /
Licensed to The Apache Software Foundation, /
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
总结回忆
总体来说，秒杀系统长短常复杂的。我们那里只是简单介绍模仿了一下单机若何优化到高性能，集群若何制止单点毛病，包管订单不超卖、很多卖的一些战略
完全的订单系统还有订单进度的查看，每台办事器上都有一个使命，按时的从总库存同步余票和库存信息展现给用户，还有用户在订单有效期内不付出，释放订单，填补到库存等等。
我们实现了高并发夺票的核心逻辑，能够说系统设想的十分的巧妙，巧妙的避开了对 DB 数据库 IO 的操做。
对 Redis 收集 IO 的高并发恳求，几乎所有的计算都是在内存中完成的，并且有效的包管了不超卖、很多卖，还可以容忍部门机器的宕机。
我觉得此中有两点特殊值得进修总结：
①负载平衡，分而治之
通过负载平衡，将差别的流量划分到差别的机器上，每台机器处置好本身的恳求，将本身的性能发扬到极致。
如许系统的整体也就能承担极高的并发了，就像工做的一个团队，每小我都将本身的价值发扬到了极致，团队生长天然是很大的。
②合理的利用并发和异步
自 Epoll 收集架构模子处理了 c10k 问题以来，异步越来越被办事端开发人员所承受，可以用异步来做的工做，就用异步来做，在功用拆解上能到达意想不到的效果。
那点在 Nginx、Node.JS、Redis 上都能表现，他们处置收集恳求利用的 Epoll 模子，用理论告诉了我们单线程仍然能够发扬强大的能力。
办事器已经进进了多核时代，Go 语言那种生成为并发而生的语言，完美的发扬了办事器多核优势，良多能够并发处置的使命都能够利用并发来处理，好比 Go 处置 中施行。
总之，如何合理的压榨 CPU，让其发扬出应有的价值，是我们不断需要摸索进修的标的目的。
来源：