国产秋霞理论久久久电影-婷婷色九月综合激情丁香-欧美在线观看乱妇视频-精品国avA久久久久久久-国产乱码精品一区二区三区亚洲人-欧美熟妇一区二区三区蜜桃视频

“12306”的架構(gòu)到底有多牛逼?

共 17686字,需瀏覽 36分鐘

 ·

2021-05-05 03:08


????關(guān)注后回復(fù) “進(jìn)群” ,拉你進(jìn)程序員交流群????


作者丨 繪你一世傾城
來(lái)源:
https://juejin.im/post/5d84e21f6fb9a06ac8248149





每到節(jié)假日期間,一二線城市返鄉(xiāng)、外出游玩的人們幾乎都面臨著一個(gè)問(wèn)題:搶火車(chē)票!



12306 搶票,極限并發(fā)帶來(lái)的思考


雖然現(xiàn)在大多數(shù)情況下都能訂到票,但是放票瞬間即無(wú)票的場(chǎng)景,相信大家都深有體會(huì)。


尤其是春節(jié)期間,大家不僅使用 12306,還會(huì)考慮“智行”和其他的搶票軟件,全國(guó)上下幾億人在這段時(shí)間都在搶票。


“12306 服務(wù)”承受著這個(gè)世界上任何秒殺系統(tǒng)都無(wú)法超越的 QPS,上百萬(wàn)的并發(fā)再正常不過(guò)了!


筆者專(zhuān)門(mén)研究了一下“12306”的服務(wù)端架構(gòu),學(xué)習(xí)到了其系統(tǒng)設(shè)計(jì)上很多亮點(diǎn),在這里和大家分享一下并模擬一個(gè)例子:如何在 100 萬(wàn)人同時(shí)搶 1 萬(wàn)張火車(chē)票時(shí),系統(tǒng)提供正常、穩(wěn)定的服務(wù)。


Github代碼地址:
https://github.com/GuoZhaoran/spikeSystem

大型高并發(fā)系統(tǒng)架構(gòu)


高并發(fā)的系統(tǒng)架構(gòu)都會(huì)采用分布式集群部署,服務(wù)上層有著層層負(fù)載均衡,并提供各種容災(zāi)手段(雙火機(jī)房、節(jié)點(diǎn)容錯(cuò)、服務(wù)器災(zāi)備等保證系統(tǒng)的高可用,流量也會(huì)根據(jù)不同的負(fù)載能力和配置策略均衡到不同的服務(wù)器上。


下邊是一個(gè)簡(jiǎn)單的示意圖:

負(fù)載均衡簡(jiǎn)介


上圖中描述了用戶請(qǐng)求到服務(wù)器經(jīng)歷了三層的負(fù)載均衡,下邊分別簡(jiǎn)單介紹一下這三種負(fù)載均衡。


①OSPF(開(kāi)放式最短鏈路優(yōu)先是一個(gè)內(nèi)部網(wǎng)關(guān)協(xié)議(Interior Gateway Protocol,簡(jiǎn)稱(chēng) IGP


OSPF 通過(guò)路由器之間通告網(wǎng)絡(luò)接口的狀態(tài)來(lái)建立鏈路狀態(tài)數(shù)據(jù)庫(kù),生成最短路徑樹(shù),OSPF 會(huì)自動(dòng)計(jì)算路由接口上的 Cost 值,但也可以通過(guò)手工指定該接口的 Cost 值,手工指定的優(yōu)先于自動(dòng)計(jì)算的值。


OSPF 計(jì)算的 Cost,同樣是和接口帶寬成反比,帶寬越高,Cost 值越小。到達(dá)目標(biāo)相同 Cost 值的路徑,可以執(zhí)行負(fù)載均衡,最多 6 條鏈路同時(shí)執(zhí)行負(fù)載均衡。


②LVS (Linux Virtual Server


它是一種集群(Cluster技術(shù),采用 IP 負(fù)載均衡技術(shù)和基于內(nèi)容請(qǐng)求分發(fā)技術(shù)。


調(diào)度器具有很好的吞吐率,將請(qǐng)求均衡地轉(zhuǎn)移到不同的服務(wù)器上執(zhí)行,且調(diào)度器自動(dòng)屏蔽掉服務(wù)器的故障,從而將一組服務(wù)器構(gòu)成一個(gè)高性能的、高可用的虛擬服務(wù)器。


③Nginx


想必大家都很熟悉了,是一款非常高性能的 HTTP 代理/反向代理服務(wù)器,服務(wù)開(kāi)發(fā)中也經(jīng)常使用它來(lái)做負(fù)載均衡。


Nginx 實(shí)現(xiàn)負(fù)載均衡的方式主要有三種:

  • 輪詢

  • 加權(quán)輪詢

  • IP Hash 輪詢


下面我們就針對(duì) Nginx 的加權(quán)輪詢做專(zhuān)門(mén)的配置和測(cè)試。


Nginx 加權(quán)輪詢的演示


Nginx 實(shí)現(xiàn)負(fù)載均衡通過(guò) Upstream 模塊實(shí)現(xiàn),其中加權(quán)輪詢的配置是可以給相關(guān)的服務(wù)加上一個(gè)權(quán)重值,配置的時(shí)候可能根據(jù)服務(wù)器的性能、負(fù)載能力設(shè)置相應(yīng)的負(fù)載。

下面是一個(gè)加權(quán)輪詢負(fù)載的配置,我將在本地的監(jiān)聽(tīng) 3001-3004 端口,分別配置 1,2,3,4 的權(quán)重:

#配置負(fù)載均衡
    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;
    }
}


我在本地 /etc/hosts 目錄下配置了 www.load_balance.com 的虛擬域名地址。


接下來(lái)使用 Go 語(yǔ)言開(kāi)啟四個(gè) HTTP 端口監(jiān)聽(tīng)服務(wù),下面是監(jiān)聽(tīng)在 3001 端口的 Go 程序,其他幾個(gè)只需要修改端口即可:

package main

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

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

//處理請(qǐng)求函數(shù),根據(jù)請(qǐng)求將響應(yīng)結(jié)果信息寫(xiě)入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
    failedMsg :=  "handle in port:"
    writeLog(failedMsg, "./stat.log")
}

//寫(xiě)入日志
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)
}


我將請(qǐng)求的端口日志信息寫(xiě)到了 ./stat.log 文件當(dāng)中,然后使用 AB 壓測(cè)工具做壓測(cè):

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


統(tǒng)計(jì)日志中的結(jié)果,3001-3004 端口分別得到了 100、200、300、400 的請(qǐng)求量。

這和我在 Nginx 中配置的權(quán)重占比很好的吻合在了一起,并且負(fù)載后的流量非常的均勻、隨機(jī)。

具體的實(shí)現(xiàn)大家可以參考 Nginx 的 Upsteam 模塊實(shí)現(xiàn)源碼,這里推薦一篇文章《Nginx 中 Upstream 機(jī)制的負(fù)載均衡》:

https://www.kancloud.cn/digest/understandingnginx/202607

秒殺搶購(gòu)系統(tǒng)選型


回到我們最初提到的問(wèn)題中來(lái):火車(chē)票秒殺系統(tǒng)如何在高并發(fā)情況下提供正常、穩(wěn)定的服務(wù)呢?

從上面的介紹我們知道用戶秒殺流量通過(guò)層層的負(fù)載均衡,均勻到了不同的服務(wù)器上,即使如此,集群中的單機(jī)所承受的 QPS 也是非常高的。如何將單機(jī)性能優(yōu)化到極致呢?

要解決這個(gè)問(wèn)題,我們就要想明白一件事:通常訂票系統(tǒng)要處理生成訂單、減扣庫(kù)存、用戶支付這三個(gè)基本的階段。


我們系統(tǒng)要做的事情是要保證火車(chē)票訂單不超賣(mài)、不少賣(mài),每張售賣(mài)的車(chē)票都必須支付才有效,還要保證系統(tǒng)承受極高的并發(fā)。


這三個(gè)階段的先后順序該怎么分配才更加合理呢?我們來(lái)分析一下:

下單減庫(kù)存


當(dāng)用戶并發(fā)請(qǐng)求到達(dá)服務(wù)端時(shí),首先創(chuàng)建訂單,然后扣除庫(kù)存,等待用戶支付。

這種順序是我們一般人首先會(huì)想到的解決方案,這種情況下也能保證訂單不會(huì)超賣(mài),因?yàn)閯?chuàng)建訂單之后就會(huì)減庫(kù)存,這是一個(gè)原子操作。

但是這樣也會(huì)產(chǎn)生一些問(wèn)題:
  • 在極限并發(fā)情況下,任何一個(gè)內(nèi)存操作的細(xì)節(jié)都至關(guān)影響性能,尤其像創(chuàng)建訂單這種邏輯,一般都需要存儲(chǔ)到磁盤(pán)數(shù)據(jù)庫(kù)的,對(duì)數(shù)據(jù)庫(kù)的壓力是可想而知的。


  • 如果用戶存在惡意下單的情況,只下單不支付這樣庫(kù)存就會(huì)變少,會(huì)少賣(mài)很多訂單,雖然服務(wù)端可以限制 IP 和用戶的購(gòu)買(mǎi)訂單數(shù)量,這也不算是一個(gè)好方法。




支付減庫(kù)存


如果等待用戶支付了訂單在減庫(kù)存,第一感覺(jué)就是不會(huì)少賣(mài)。但是這是并發(fā)架構(gòu)的大忌,因?yàn)樵跇O限并發(fā)情況下,用戶可能會(huì)創(chuàng)建很多訂單。


當(dāng)庫(kù)存減為零的時(shí)候很多用戶發(fā)現(xiàn)搶到的訂單支付不了了,這也就是所謂的“超賣(mài)”。也不能避免并發(fā)操作數(shù)據(jù)庫(kù)磁盤(pán) IO。

預(yù)扣庫(kù)存


從上邊兩種方案的考慮,我們可以得出結(jié)論:只要?jiǎng)?chuàng)建訂單,就要頻繁操作數(shù)據(jù)庫(kù) IO。

那么有沒(méi)有一種不需要直接操作數(shù)據(jù)庫(kù) IO 的方案呢,這就是預(yù)扣庫(kù)存。先扣除了庫(kù)存,保證不超賣(mài),然后異步生成用戶訂單,這樣響應(yīng)給用戶的速度就會(huì)快很多;那么怎么保證不少賣(mài)呢?用戶拿到了訂單,不支付怎么辦?

我們都知道現(xiàn)在訂單都有有效期,比如說(shuō)用戶五分鐘內(nèi)不支付,訂單就失效了,訂單一旦失效,就會(huì)加入新的庫(kù)存,這也是現(xiàn)在很多網(wǎng)上零售企業(yè)保證商品不少賣(mài)采用的方案。

訂單的生成是異步的,一般都會(huì)放到 MQ、Kafka 這樣的即時(shí)消費(fèi)隊(duì)列中處理,訂單量比較少的情況下,生成訂單非常快,用戶幾乎不用排隊(duì)。

扣庫(kù)存的藝術(shù)


從上面的分析可知,顯然預(yù)扣庫(kù)存的方案最合理。我們進(jìn)一步分析扣庫(kù)存的細(xì)節(jié),這里還有很大的優(yōu)化空間,庫(kù)存存在哪里?怎樣保證高并發(fā)下,正確的扣庫(kù)存,還能快速的響應(yīng)用戶請(qǐng)求?

在單機(jī)低并發(fā)情況下,我們實(shí)現(xiàn)扣庫(kù)存通常是這樣的:

為了保證扣庫(kù)存和生成訂單的原子性,需要采用事務(wù)處理,然后取庫(kù)存判斷、減庫(kù)存,最后提交事務(wù),整個(gè)流程有很多 IO,對(duì)數(shù)據(jù)庫(kù)的操作又是阻塞的。


這種方式根本不適合高并發(fā)的秒殺系統(tǒng)。接下來(lái)我們對(duì)單機(jī)扣庫(kù)存的方案做優(yōu)化:本地扣庫(kù)存。


我們把一定的庫(kù)存量分配到本地機(jī)器,直接在內(nèi)存中減庫(kù)存,然后按照之前的邏輯異步創(chuàng)建訂單。


改進(jìn)過(guò)之后的單機(jī)系統(tǒng)是這樣的:

這樣就避免了對(duì)數(shù)據(jù)庫(kù)頻繁的 IO 操作,只在內(nèi)存中做運(yùn)算,極大的提高了單機(jī)抗并發(fā)的能力。

但是百萬(wàn)的用戶請(qǐng)求量單機(jī)是無(wú)論如何也抗不住的,雖然 Nginx 處理網(wǎng)絡(luò)請(qǐng)求使用 Epoll 模型,c10k 的問(wèn)題在業(yè)界早已得到了解決。

但是 Linux 系統(tǒng)下,一切資源皆文件,網(wǎng)絡(luò)請(qǐng)求也是這樣,大量的文件描述符會(huì)使操作系統(tǒng)瞬間失去響應(yīng)。

上面我們提到了 Nginx 的加權(quán)均衡策略,我們不妨假設(shè)將 100W 的用戶請(qǐng)求量平均均衡到 100 臺(tái)服務(wù)器上,這樣單機(jī)所承受的并發(fā)量就小了很多。

然后我們每臺(tái)機(jī)器本地庫(kù)存 100 張火車(chē)票,100 臺(tái)服務(wù)器上的總庫(kù)存還是 1 萬(wàn),這樣保證了庫(kù)存訂單不超賣(mài),下面是我們描述的集群架構(gòu):

問(wèn)題接踵而至,在高并發(fā)情況下,現(xiàn)在我們還無(wú)法保證系統(tǒng)的高可用,假如這 100 臺(tái)服務(wù)器上有兩三臺(tái)機(jī)器因?yàn)榭覆蛔〔l(fā)的流量或者其他的原因宕機(jī)了。那么這些服務(wù)器上的訂單就賣(mài)不出去了,這就造成了訂單的少賣(mài)。

要解決這個(gè)問(wèn)題,我們需要對(duì)總訂單量做統(tǒng)一的管理,這就是接下來(lái)的容錯(cuò)方案。服務(wù)器不僅要在本地減庫(kù)存,另外要遠(yuǎn)程統(tǒng)一減庫(kù)存。

有了遠(yuǎn)程統(tǒng)一減庫(kù)存的操作,我們就可以根據(jù)機(jī)器負(fù)載情況,為每臺(tái)機(jī)器分配一些多余的“Buffer 庫(kù)存”用來(lái)防止機(jī)器中有機(jī)器宕機(jī)的情況。

我們結(jié)合下面架構(gòu)圖具體分析一下:

我們采用 Redis 存儲(chǔ)統(tǒng)一庫(kù)存,因?yàn)?Redis 的性能非常高,號(hào)稱(chēng)單機(jī) QPS 能抗 10W 的并發(fā)。

在本地減庫(kù)存以后,如果本地有訂單,我們?cè)偃フ?qǐng)求 Redis 遠(yuǎn)程減庫(kù)存,本地減庫(kù)存和遠(yuǎn)程減庫(kù)存都成功了,才返回給用戶搶票成功的提示,這樣也能有效的保證訂單不會(huì)超賣(mài)。

當(dāng)機(jī)器中有機(jī)器宕機(jī)時(shí),因?yàn)槊總€(gè)機(jī)器上有預(yù)留的 Buffer 余票,所以宕機(jī)機(jī)器上的余票依然能夠在其他機(jī)器上得到彌補(bǔ),保證了不少賣(mài)。

Buffer 余票設(shè)置多少合適呢,理論上 Buffer 設(shè)置的越多,系統(tǒng)容忍宕機(jī)的機(jī)器數(shù)量就越多,但是 Buffer 設(shè)置的太大也會(huì)對(duì) Redis 造成一定的影響。

雖然 Redis 內(nèi)存數(shù)據(jù)庫(kù)抗并發(fā)能力非常高,請(qǐng)求依然會(huì)走一次網(wǎng)絡(luò) IO,其實(shí)搶票過(guò)程中對(duì) Redis 的請(qǐng)求次數(shù)是本地庫(kù)存和 Buffer 庫(kù)存的總量。


因?yàn)楫?dāng)本地庫(kù)存不足時(shí),系統(tǒng)直接返回用戶“已售罄”的信息提示,就不會(huì)再走統(tǒng)一扣庫(kù)存的邏輯。


這在一定程度上也避免了巨大的網(wǎng)絡(luò)請(qǐng)求量把 Redis 壓跨,所以 Buffer 值設(shè)置多少,需要架構(gòu)師對(duì)系統(tǒng)的負(fù)載能力做認(rèn)真的考量。


代碼演示


Go 語(yǔ)言原生為并發(fā)設(shè)計(jì),我采用 Go 語(yǔ)言給大家演示一下單機(jī)搶票的具體流程。

初始化工作


Go 包中的 Init 函數(shù)先于 Main 函數(shù)執(zhí)行,在這個(gè)階段主要做一些準(zhǔn)備性工作。

我們系統(tǒng)需要做的準(zhǔn)備工作有:初始化本地庫(kù)存、初始化遠(yuǎn)程 Redis 存儲(chǔ)統(tǒng)一庫(kù)存的 Hash 鍵值、初始化 Redis 連接池。


另外還需要初始化一個(gè)大小為 1 的 Int 類(lèi)型 Chan,目的是實(shí)現(xiàn)分布式鎖的功能。


也可以直接使用讀寫(xiě)鎖或者使用 Redis 等其他的方式避免資源競(jìng)爭(zhēng),但使用 Channel 更加高效,這就是 Go 語(yǔ)言的哲學(xué):不要通過(guò)共享內(nèi)存來(lái)通信,而要通過(guò)通信來(lái)共享內(nèi)存。

Redis 庫(kù)使用的是 Redigo,下面是代碼實(shí)現(xiàn):

...
//localSpike包結(jié)構(gòu)體定義
package localSpike

type LocalSpike struct {
    LocalInStock     int64
    LocalSalesVolume int64
}
...
//remoteSpike對(duì)hash結(jié)構(gòu)的定義和redis連接池
package remoteSpike
//遠(yuǎn)程訂單存儲(chǔ)健值
type RemoteSpikeKeys struct {
    SpikeOrderHashKey string    //redis中秒殺訂單hash結(jié)構(gòu)key
    TotalInventoryKey string    //hash結(jié)構(gòu)中總訂單庫(kù)存key
    QuantityOfOrderKey string   //hash結(jié)構(gòu)中已有訂單數(shù)量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 int1)
    done <- 1
}


本地扣庫(kù)存和統(tǒng)一扣庫(kù)存


本地扣庫(kù)存邏輯非常簡(jiǎn)單,用戶請(qǐng)求過(guò)來(lái),添加銷(xiāo)量,然后對(duì)比銷(xiāo)量是否大于本地庫(kù)存,返回 Bool 值:

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


注意這里對(duì)共享數(shù)據(jù) LocalSalesVolume 的操作是要使用鎖來(lái)實(shí)現(xiàn)的,但是因?yàn)楸镜乜蹘?kù)存和統(tǒng)一扣庫(kù)存是一個(gè)原子性操作,所以在最上層使用 Channel 來(lái)實(shí)現(xiàn),這塊后邊會(huì)講。

統(tǒng)一扣庫(kù)存操作 Redis,因?yàn)?Redis 是單線程的,而我們要實(shí)現(xiàn)從中取數(shù)據(jù),寫(xiě)數(shù)據(jù)并計(jì)算一些列步驟,我們要配合 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))
        -- 查看是否還有余票,增加訂單數(shù)量,返回結(jié)果值
       if(ticket_total_nums >= ticket_sold_nums) then
            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)
        end
        return 0
`
//遠(yuǎn)端統(tǒng)一扣庫(kù)存
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 結(jié)構(gòu)存儲(chǔ)總庫(kù)存和總銷(xiāo)量的信息,用戶請(qǐng)求過(guò)來(lái)時(shí),判斷總銷(xiāo)量是否大于庫(kù)存,然后返回相關(guān)的 Bool 值。


在啟動(dòng)服務(wù)之前,我們需要初始化 Redis 的初始庫(kù)存信息:
hmset ticket_hash_key "ticket_total_nums" 10000 "ticket_sold_nums" 0


響應(yīng)用戶信息


我們開(kāi)啟一個(gè) HTTP 服務(wù),監(jiān)聽(tīng)在一個(gè)端口上:

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


上面我們做完了所有的初始化工作,接下來(lái) handleReq 的邏輯非常清晰,判斷是否搶票成功,返回給用戶信息就可以了。

package main
//處理請(qǐng)求函數(shù),根據(jù)請(qǐng)求將響應(yīng)結(jié)果信息寫(xiě)入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
    redisConn := redisPool.Get()
    LogMsg := ""
    <-done
    //全局讀寫(xiě)鎖
    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

    //將搶票狀態(tài)寫(xiě)入到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)
}


前邊提到我們扣庫(kù)存時(shí)要考慮競(jìng)態(tài)條件,我們這里是使用 Channel 避免并發(fā)的讀寫(xiě),保證了請(qǐng)求的高效順序執(zhí)行。我們將接口的返回信息寫(xiě)入到了 ./stat.log 文件方便做壓測(cè)統(tǒng)計(jì)。

單機(jī)服務(wù)壓測(cè)


開(kāi)啟服務(wù),我們使用 AB 壓測(cè)工具進(jìn)行測(cè)試:

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


下面是我本地低配 Mac 的壓測(cè)信息:

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)


根據(jù)指標(biāo)顯示,我單機(jī)每秒就能處理 4000+ 的請(qǐng)求,正常服務(wù)器都是多核配置,處理 1W+ 的請(qǐng)求根本沒(méi)有問(wèn)題。

而且查看日志發(fā)現(xiàn)整個(gè)服務(wù)過(guò)程中,請(qǐng)求都很正常,流量均勻,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
...


總結(jié)回顧


總體來(lái)說(shuō),秒殺系統(tǒng)是非常復(fù)雜的。我們這里只是簡(jiǎn)單介紹模擬了一下單機(jī)如何優(yōu)化到高性能,集群如何避免單點(diǎn)故障,保證訂單不超賣(mài)、不少賣(mài)的一些策略


完整的訂單系統(tǒng)還有訂單進(jìn)度的查看,每臺(tái)服務(wù)器上都有一個(gè)任務(wù),定時(shí)的從總庫(kù)存同步余票和庫(kù)存信息展示給用戶,還有用戶在訂單有效期內(nèi)不支付,釋放訂單,補(bǔ)充到庫(kù)存等等。


我們實(shí)現(xiàn)了高并發(fā)搶票的核心邏輯,可以說(shuō)系統(tǒng)設(shè)計(jì)的非常的巧妙,巧妙的避開(kāi)了對(duì) DB 數(shù)據(jù)庫(kù) IO 的操作。

對(duì) Redis 網(wǎng)絡(luò) IO 的高并發(fā)請(qǐng)求,幾乎所有的計(jì)算都是在內(nèi)存中完成的,而且有效的保證了不超賣(mài)、不少賣(mài),還能夠容忍部分機(jī)器的宕機(jī)。

我覺(jué)得其中有兩點(diǎn)特別值得學(xué)習(xí)總結(jié):

①負(fù)載均衡,分而治之


通過(guò)負(fù)載均衡,將不同的流量劃分到不同的機(jī)器上,每臺(tái)機(jī)器處理好自己的請(qǐng)求,將自己的性能發(fā)揮到極致。


這樣系統(tǒng)的整體也就能承受極高的并發(fā)了,就像工作的一個(gè)團(tuán)隊(duì),每個(gè)人都將自己的價(jià)值發(fā)揮到了極致,團(tuán)隊(duì)成長(zhǎng)自然是很大的。


②合理的使用并發(fā)和異步

自 Epoll 網(wǎng)絡(luò)架構(gòu)模型解決了 c10k 問(wèn)題以來(lái),異步越來(lái)越被服務(wù)端開(kāi)發(fā)人員所接受,能夠用異步來(lái)做的工作,就用異步來(lái)做,在功能拆解上能達(dá)到意想不到的效果。


這點(diǎn)在 Nginx、Node.JS、Redis 上都能體現(xiàn),他們處理網(wǎng)絡(luò)請(qǐng)求使用的 Epoll 模型,用實(shí)踐告訴了我們單線程依然可以發(fā)揮強(qiáng)大的威力。

服務(wù)器已經(jīng)進(jìn)入了多核時(shí)代,Go 語(yǔ)言這種天生為并發(fā)而生的語(yǔ)言,完美的發(fā)揮了服務(wù)器多核優(yōu)勢(shì),很多可以并發(fā)處理的任務(wù)都可以使用并發(fā)來(lái)解決,比如 Go 處理 HTTP 請(qǐng)求時(shí)每個(gè)請(qǐng)求都會(huì)在一個(gè) Goroutine 中執(zhí)行。


總之,怎樣合理的壓榨 CPU,讓其發(fā)揮出應(yīng)有的價(jià)值,是我們一直需要探索學(xué)習(xí)的方向。

-End-

最近有一些小伙伴,讓我?guī)兔φ乙恍?nbsp;面試題 資料,于是我翻遍了收藏的 5T 資料后,匯總整理出來(lái),可以說(shuō)是程序員面試必備!所有資料都整理到網(wǎng)盤(pán)了,歡迎下載!

點(diǎn)擊??卡片,關(guān)注后回復(fù)【面試題】即可獲取

在看點(diǎn)這里好文分享給更多人↓↓

瀏覽 18
點(diǎn)贊
評(píng)論
收藏
分享

手機(jī)掃一掃分享

分享
舉報(bào)
評(píng)論
圖片
表情
推薦
點(diǎn)贊
評(píng)論
收藏
分享

手機(jī)掃一掃分享

分享
舉報(bào)

感谢您访问我们的网站,您可能还对以下资源感兴趣:

国产秋霞理论久久久电影-婷婷色九月综合激情丁香-欧美在线观看乱妇视频-精品国avA久久久久久久-国产乱码精品一区二区三区亚洲人-欧美熟妇一区二区三区蜜桃视频 国产精品福利导航| 日韩欧美v| 久9久9久9久9久9久9| 亚洲欧洲有码在线| 久久伊人网站| 中文字幕乱码中文字幕电视剧| 欧美日在线观看| 91在线看18| 国产乱子伦日B视频| 人妻无码专区| 先锋影音一区二区| 波多野结衣在线精品| 俺也去com| 先锋影音资源站| 在线免费观看黄色电影| 欧美日韩一二| 欧美区亚洲区| 简单av网| 在线操B视频| 日韩一级片在线观看| 91绿帽人妻-ThePorn| 日本无码在线视频| 高清中文字幕在线A片| 亚洲AV永久无码国产精品久久 | 欧美在线无码| 日本熟妇无码一区二区| 四川少妇搡BBw搡BBBB搡| 免费看性蜜桃| 成人网视频| 蜜桃BBwBBWBBwBBw| 亚洲视频a| 国产热99| 亚洲美女网站免费观看网址| 超碰最新在线观看| www.怡春院| 亚洲有码中文字幕| 午夜福利大片| 久久免费视频精品| 国产日韩欧美一区| 亚洲大片免费看| 亚洲.www| 无码国产精品一区二区性色AV| 午夜成人爽| 久久三级| 亚洲影音先锋| 偷拍视频网站| 成人无码一区二区三区| 最新国产精品| 秘亚洲国产精品成人网站| 蜜臀精品色无码蜜臀AV| 久久香视频| 亚洲国产黄片| 韩国GOGOGO高清| 丁香五月在线视频| 成人片网址| AV片在线观看| 久久久久久高清毛片一级| 99久久久精品| 国产成人精品免费看视频| 在线观看中文字幕无码| 成人黄片网| 日本午夜三级视频| 天堂A片电影网站在线观看| 亚洲最大成人网站| 在线一区二区三区四区| 狠狠干免费视频| 蜜桃视频成人app| 丁香五月五月婷婷| 成人无码日韩精品| 成人小视频在线| av六月天| 亚洲AV无码乱码国产精品黑人| 一级草逼| 成人免费无码激情AV片| 成人久久AV| 午夜成人亚洲| 久久人妻免费视频| 青草网| 操逼免费| 久久久久久亚洲| 影音av| 日韩免费高清无码| 日韩av一区二区三区| 美女网站在线观看| A级毛片在线观看| 日本内射在线观看| 一道本高清无码视频| 91吴梦梦一区二区传媒| 免费无码婬片AAAA片老婦| 大香蕉在线网站| 免费看黄色视频的网站| 91成人久久| 欧美性猛交ⅩXXX无码视频 | 爽妇综合网| 十八禁视频在线观看网站.www | 日韩免费精品视频| 夜夜骑夜夜撸| 国产aaaaaaaaaa| 日本黄A三级三级三级| 台湾中文字幕网| 波多野结衣AV网站| 午夜国产在线视频| 一级片国产| 中文字幕亚洲人妻| 亚洲无码十八禁| 精品吃奶一区二区三区视频| 一本色道久久88亚洲精品综合| 婷婷在线观看免费| 色99在线| 不卡日本| 曰曰干| 日韩做爱网站| 黄色一级小说| 青草青在线| 抽插影院| 老太色HD色老太HD-百度| 91人妻无码精品一区二区三区| 婷婷五月天丁香网| 97人妻人人澡人人爽人人| 国产又粗又猛又爽又黄91精品| 日本一区二区视频在线| 丁香五月亚洲| 五月丁香婷婷色色| 精品人妻一区二区三区在线视频不卡 | 成人激情视频网| 欧美精品日韩在线观看| 一级特黄大片色| h网站在线| 大香蕉伊人av| 成人AV免费在线观看| 午夜黄色电影| 亚洲日韩AV在线| 久久在线视频| 99热最新| 大香蕉在线免| 色99在线视频| 亚洲免费观看A∨中文| 特黄特色一级特黄大片| 免费国产精品视频| www.xxx国产| 免费黄片在线| av中文字幕无码| 国产欧美日韩一区二区三区| 国产日本在线| 综合夜夜| 69视频网| 中文字幕av久久波多野结| 人人操人人| 97在线鲁碰免费视频| 激情aaa| 欧美日韩一区二区三区视频| 久草大香蕉在线| 国产精品久久久久无码AV| 午夜黄色视频在线观看| 性爱麻豆| 91女人18片女毛片60分钟| 婷婷激情久久| 91久久久久| 在线无码| 伊人日韩| 一本久久综合亚洲鲁鲁五月天| 91精品国产一区三一| 国产热99| 成年人在线观看视频网站| 无码囯无精品毛片大码| 中文字幕在线观看免费高清电影 | 欧美日韩在线一区| 日逼视频免费观看| 蜜挑视频一区二区三区| 水多多成人网站A片| 欧美日韩成人网| 黑人毛片91久久久久久| 亚洲精品国产精品国自产网站| 欧美老女人性爱视频| 婷婷色导航| 一区二区三区四区在线| 欧美老妇日韩| 无码人妻一区二区三区三| 亚洲精品无码免费| 国产成人AV免费无码| 操天天| 黄色一级a片| 米奇色色| 亚洲品久久久蜜| av大片在线观看| 黄色一级电影网| 欧美性爱在线播放| 94久久| 亚洲成人网在线观看| 成人一区二区三区四区| 亚洲三级在线观看| 麻妃无码| 亚洲成年人在线| 日韩三级久久| 国产亚洲Av| 欧美一级操逼| 久久亚洲日韩天天做日日做综合亚洲 | 欧美日韩中文字幕无码| 天天亚洲| 国产综合久久久777777色胡同 | 中文字幕av久久爽爽| 人人干人人干人人干| 久操免费在线视频| 男女av| 激情日逼| 五月天婷婷在线视频| 草逼逼| 玖玖成人电影| 欧美日韩黄色| 88海外华人免费一区| 亚洲一级一级黄色| 国产精品不卡在线| 91成人精品一区二区| 国产在线第一页| 无码中文字幕高清| 2024男人天堂| 国产又猛又黄又爽| 丰满人妻一区二区三区蜜桃视频| 日韩无码中字| 水多多成人网站A片| 精品一区二区免费| 好男人WWW一区二区三区| 成人AV毛片| 日韩中文字幕无码| 亚洲视频在线免费| 六月激情网| 高H视频在线观看| 黄网站免费观看| 中文无码字幕视频| 91ccc| 成人黄色av| 欧美操逼图片| 欧美色乱| 靠逼网站免费观看| 男人在线天堂| 99热网站| 性爱无码AV| 成人精品一区二区三区无码视频| 狠狠干中文字幕| 欧美视频在线播放| 内射学生妹视频| 性无码区| 日本免费在线观看| 亚洲av影院| 激情无码av| 无码人妻少妇| 国产在线观看AV| 亚洲777| 国产高清无码网站| 蜜桃操逼| 欧美三级在线视频| 色综合五月| 免费看毛片的网站| Av一区二区三区| 99这里只有精品| 天堂视频中文在线| 黄色视频毛片| 香蕉伊人在线| 毛片在线看片| 五月激情丁香婷婷| 久久亚洲av| 亚洲综合伊人| 丁香婷婷在线| 久久久WWW成人免费精品| 麻豆乱码国产一区二区三区| 亚洲一区免费| 99色99| 成人做爰黄A片免费看直播室动漫| 成人毛片在线播放免费| 国产日韩二区| 久久精品一区二区三区蜜芽的特点 | 熟女一区二区三区| 日韩一级片网站| 国产熟妇婬乱A片免费看牛牛| 无码精品一区二区三区在线| 国产AV黄| 色综合一区二区| 久久久性爱| 一级黄在线观看| 亚洲综合影院| 欧美成人免费| 在线观看免费视频a| 婷婷五月丁香激情| 91日韩在线| 激情五月天开心网| 日本成人久久| 久久久久久久久久国产精品免费观看-百度 | 天干天干天夜夜| 在线观看你懂得| 大香蕉精品欧美色综合2025| 69国产成人综合久久精品欧美 | 日韩做爱网站| 91亚洲国产AⅤ精品一区二区| 球AV在线| 婷婷精品免费| 伊人久久艹| 一级片黄色免费| 囯产精品久久久| 久久精品国产视频| 边摸边插| 成人大香蕉网站精品免费| 亚洲三级片在线观看| 无码人妻AV一区| 爱操逼综合网| 亚洲欧洲无码在线| 亚洲免费一级片| 色搞搞| 特级西西444www高清大胆免费看| 欧美第二页| 伊人乱伦| 国产香蕉视频在线播放| www.亚洲成人| 久久国产精品在线| 色老板在线免费观看| 黄色片在线| 日韩亚洲在线视频| 国产黄片网站| 操操操操一本到| 日韩成人黄片| 婷婷色导航| 国产乱子伦一区二区三| 一区二区三区成人电影| 欧美干干| 国产一级片在线| 欧美日逼视频| 99草在线视频| 乱婬妺妺躁爽A片| 91白丝喷水自慰网站| 2025国产成人精品一区| 中字一区人妻水多多| 久久这里只有精品9| 18禁在线播放| 久久婷婷五月丁香| 午夜精品18视频国产17c| 五月天在线电影| 超碰在线网站| www.zaixianshipin| 综合亚洲视频| 四虎精品一区二区三区| 日韩精品极品视频在线观看免费| 亚洲国产精品久久| 黄色一级片免费在线观看| 国产精品久久久精品cos| 亚洲中文字幕在线观看视频网站| 国产成人精品无码| 日韩婷婷| 婷婷五月天激情电影| 99久久精品国产一区色| 人妻体内射精| 国产精品自拍小视频| 亚洲日韩精品在线视频| 麻豆av在线观看| 国产在线成人视频| 国产视频一区二区在线观看| 日本高清色清di免费观看| 成人网站www污污污网站公司| AV在线天堂| 伊人黄色视频| av天天干| 搡bbbb| 女人天堂av| 国产成人精品a视频一区| 老熟女露脸25分钟91秒| 久久成人久久爱| 国产高清一区二区| 精品人人人人| 色xxxx| 五月天婷婷小说| 日韩va中文字幕无码免费| 超碰自拍97| 日韩爱爱网| 人妻体体内射精一区二区| 无码在线免费视频| 日本中文字幕乱伦| 一本一道无码免费看视频| 亚洲成人情趣大香蕉| 人人爽人人爱| 欧美大鸡巴视频| 91天堂网| 国产精品伦子伦免费视频| 无码乱伦视频| 成年片免费观看网站免费观看,亚洲+欧...| 无码福利电影| 亚洲日韩精品成人无码专区AV| 操一操影院| 免费爱爱视频网站| 天天干天天操天天干| 日屄电影| 日韩黄色电影在线观看| 成熟的国模冰莲[2]| 黄片视频大全| 无码人妻在线播放| 国产亚洲久一区二区写真| 中文字幕乱伦日本| 国产丝袜在线视频| 国产高清毛片| 亚洲欧美日本在线观看| 亚洲一区色| 亚洲无码小电影| jzzijzzij亚洲成熟少妇在线观看 九色蝌蚪9l视频蝌蚪9l视频成人熟妇 | 综合色国产精品欧美在线观看| 欧美成人怡红院| 国产又大又粗又爽| 精品一区二区久久久久久久网站| 日本欧美一级片| 四川女人毛多水多A片| 91国在线视频| 自拍偷拍视频网址| 成人在线中文| 欧美成人精品| 国产成人无码AⅤ片免费播放 | 国产曰韩欧美综合另类在线| 精品色| 狠狠操狠狠色| 男女视频网站| 亚洲成人AV| 操逼操逼操逼| 99re6热在线精品视频| 国产成人宗合| 欧美成人午夜福利| 免费观看黄色一级片| 免费看黃色AAAAAA片| 色777色| 中文字幕免费在线观看| 狠狠色婷婷777| 久久午夜无码鲁丝午夜精品| 中文日韩欧美| 97人人操人人| 亚洲无码二区| 日本老熟妇| www人人操| 亚洲日韩中文无码| 色逼逼网| 永井玛丽亚av无码中出流出| aaa无码| 国精品无码一区二区三区在线| 免费操逼视频网站| 午夜福利AV在线| 久久无码黄片| 水蜜桃视频免费观看| 在线免费观看成人网站| 日韩天堂| 久久精品成人导航| 国产搡BBB爽爽爽视频| 污污污www精品国产网站| 欧美h在线观看| 成人午夜黄色| 婷婷亚洲色| 操逼激情视频| 国产aa| 亚洲va欧洲va国产va不卡| 免费观看黄色一级片| 免费无码国产在线观看| 不卡日韩| 影音先锋乱伦电影| 六月婷婷综合| 一区二区三区观看| 98无码人妻精品一区二区三区| 91狠狠综合久久久久久| 日韩在线一区二区三区四区| 成人视频欧美| 国产精品黄色电影| 蜜桃亚洲AV无码一区二区三区| 亚洲草比视频网| 你懂的在线观看视频| 青青草原免费在线视频| 日韩群交| 色综合一区二区三区| 91社区成人影院| 水蜜桃网站| 亚洲无码AV在线播放| 无码人妻AⅤ一区二区三区| 久草福利| 美女91视频网站| 午夜欧美性爱视频| 韩国午夜电影| 亚洲欧美视频在线| 四虎影院色| 亚洲AV无码一区毛片AV| a天堂视频| 91丨九色丨国产在线| 国产寡妇亲子伦一区二区三区四区| 精品国产三级| 国产亚洲欧洲| 在线黄网站| 亚洲中文字幕第一页| 97免费| 大香蕉偷拍视频| 91大神免费观看| 国产熟妇婬乱A片免费看牛牛| 亚洲男同Gay一区二区| 高清无码免费在线视频| 日韩综合色| 中文不卡在线| 日韩无码第四页| 日韩国产在线观看| 久久韩国| 黄片视频观看| 少妇人妻一区| 97久久精品国产熟妇高清网 | 少妇毛片| 国内久久婷婷| 亚洲精品无| 福利一区二区视频网| 蜜桃精品在线观看| 老太色HD色老太HD-百度| 少妇三级| 久久久三级片| 日韩一级电影在线观看| AV色图| 强开小嫩苞毛片一二三区| 国产精品一二| 无码av免费精品一区二区三区| 丁香六月婷婷综合缴| 日韩在线视频不卡| 欧美性爱小说| 亚洲欧美国产毛片在线| 美女网站黄色| 日韩三级一区二区| 亚洲AAA| 中文字幕精品在线观看| 欧美黄色性爱| 天天操人人爽| 亚洲成人精品少妇| 操逼大香蕉| 日韩精品在线观看免费| 亚洲午夜激情电影| 黄色亚洲无码| a视频在线| 久久艹国产| 伊人黄色电影| 大香蕉伊人手机在线| 精品乱子伦一区二区三区,亚洲国产成| 亚洲高清av| 欧美大骚逼| 天天射天天日天天干| 久草视频在线资源| 最好看的MV中文字幕国语电影 | 久久国产免费| 99在线精品视频免费观看20| 亚洲天堂在线看| 91香蕉网站| 老妇性BBWBBWBBWBBW| 亚洲色久| 欧美疯狂做受XXXXX高潮| 91人妻人人澡人人爽人人玩| 福利视频中文字幕| 天天影视综合网免费观看电视剧国产 | 99热在线播放| 四虎AV| AV在线影院| 国产乱子伦无码视频免费| 91麻豆国产在线| 日本高清色清di免费观看| 水蜜桃网址| 午夜激情四射| 麻豆AV在线播放| 中文字幕一二三四| 成人在线伊人| 三级视频网站| 精品91海角乱| 日韩小视频在线| 9久9久9久9久女女女女| 免费观看黄片网站| 久久九九免费视频| 无码高清| 中文字幕第五页| 亚洲精品在线看| 婷婷狠狠操| 婷婷六月色| 五月婷网| 欧美屄视频| 亚洲一级黄色电影| 人人澡人人澡人人澡| 97黄片| 大香蕉在线看| 超碰九一| 麻豆传媒一区| 无码av观看| 日韩人妻丰满无码区A片| 黄色录像一级片| 国产av一级片| 欧美日韩成人一区二区三区 | 国产欧美综合三级伦| 天天天天色| 青草av在| 在线观看中文字幕av| 婷婷五月天在线播放| 国产视频一区二区三区四区五区| 亚欧洲精品在线视频| 国产黄片在线视频| 黄色三极片| 欧美老妇日韩| 日本欧美在线观看高清| 免费无码国产在线53| 一本一道无码| 欧美成人三级在线| 中文字幕高清无码在线观看| 粉嫩小泬BBBBBB免费看| 超碰在线人人爱| 久久免费9| 日韩一级中文字幕| 欧美色大香蕉| av在线资源| 欧美视频一区二区三区四区| 黄片网站视频| 色色丁香| 亚洲成人网在线| 中国一级黄色毛片| www俺来也com| 精品亚洲成人| 久久久女人| 亚洲在线观看网站| 日本乱码视频| 黄色视频一区二区| 天天干天天日天天操| 亚洲成人一区二区三区| 黄色午夜福利| 亚洲精品中文字幕无码| 91视频18| 99国产精品免费视频观看8| 午夜福利aaa| 日韩视频区| 亚洲第一无码| 99久久99久久兔费精桃| 激情三区| 91啦丨熟女露脸| 91麻豆电影| 日本久久不卡| 精品视频久久久久久| 亚洲精品成人片在线观看精品字幕| 久久国产大奶| 91视频导航| 91在线亚洲| 欧美精产国品一二三| 日日干夜夜操| 亚洲精品蜜桃| 亚洲专区视频| 国产成人精品一区二区三区| 欧美一道本| 免费无人区一码二码乱码怎么办| 婷婷丁香五月社区亚洲| 久久久精品免费视频| 免费无码又爽又黄又刺激网站| 成年人免费视频在线观看| 骚逼逼影院| 日韩欧美一级二级| A片在线观看网站| 亚洲国产成人无码a在线播放| 无码精品在线观看| 91亚洲影院| 狠狠91| 大地资源第5页在线| 欧美+日产+中文| 国产在线接入| 一区二区三区四区在线视频| 人人色网站| 黄色一级片在线看| 日韩精品黄片| 丁香激情综合| 91一区在线观看| 影音先锋亚洲无码| 久草视频资源| 亚洲图片在线| 欧美XX888做受| 69国产成人精品二区| 97在线资源| 中文一区在线观看| 婷婷综合欧美| 日屄电影| 国产一级自拍| 五月天激情四射| 欧美成人AA| 久久午夜无码鲁丝片主演是谁| 中文字幕人妻在线中文乱码怎么解决| 色综合大香蕉| 久久久五月| 五月天婷婷丁香网| 蜜桃Av噜噜一区| 亚洲视频网站在线观看| 日韩av在线电影| 国产V视频| 国产欧美一区二区三区视频在线观看 | 欧美性爱导航| 欧美午夜无码| 大茄子熟女AV导航| 欧美丰满人妻| 黄片在线免费观看视频| 91福利导航| 精精品人妻一区二区三区| 蜜臀91| 在线观看亚洲视频| 亚洲五月婷婷| 美妇肥臀一区二区三区-久久99精品国| 人妻japanesewoman| 中韩一区二区| 三级黄片免费看| 欧美大鸡巴视频| 熟女视频网| 91色在线视频| 黄总AV| 青在线视频| 国产黄色片视频| 熊猫成人网| 水蜜桃视频免费观看| 国产h在线观看| 99色视频| 亚洲成人黄色| 初学影院WWWBD英语完整版在线观看 | 91视频在线看| 无码人妻日韩精品一区二区三| 91精品国产成人www| 婷婷五月天丁香成人社区| 性欧美日韩| 影音先锋黄色资源| 香蕉午夜视频| 青青操成人在线视频| 黄视频在线观看免费| 免费看黄A级毛片成人片| 国产综合精品久久久久成人AV| 插插菊花综合网| 91乱子伦国产乱子伦!| 天天色视频| 美女黄色视频永费在线观看网站 | 免费操B视频| 婷婷综合色| 影音先锋亚洲无码| 丁香婷婷色五月激情综合三级三级片欧美日韩国 | 无码精品ThePorn| 国产成人av| 大香蕉伊人丁香五月| 亚洲无码A区| 五月天综合久久| 影音先锋av在线资源| 91在线一区二区三区| 一级内射视频| 午夜AV影院| 天天综合色| 不雅一级| 亚洲理论在线| 天天看高清无码| 伊人婷婷大香蕉| 极品一线天小嫩嫩真紧| 午夜久久久| 学生妹做爱视频| 欧美成人精品一区二区| 米奇7777狠狠狠狠| 人妻体体内射精一区二区| 无套内射在线| 成人毛片在线视频| 91免费高清视频| 影音AV| 天天操夜夜爽| 伊人综合电影| 影音先锋婷婷| 91极品视觉盛宴| 综合久久亚洲| 91精品久久久久久粉嫩| 五月丁香欧美| h片在线观看| 欧美日韩一级在线观看| 91视频福利| 日韩人妻精品中文字幕专区不卡 | 99热在线观看免费精品| AV网站在线播放| 越南小嫩嫩BBWBBw| 天天天日天天天操| 亚洲在线无码播放| www.五月天.con| 天堂网中文| 国产主播福利| 中文字幕综合网| 在线操B视频| www.午夜福利| 台湾精品无码| 69国产精品| 国产性爱在线| 天天操人人妻| 毛片A片免费看| 精品白浆| 91露脸熟女四川熟女在线观看| 69视频网站| 狼友视频第二页| 亚洲播播在线视频| 中文字幕av免费在线观看| 俺去草| 日本天堂网| 国产精品18在线| 超碰在线播| 三级网址在线| 免费欧美性爱视频| 欧美黄色电影网站| www超碰在线| 狠狠狠狠狠狠狠狠狠狠| 日本高清视频免费观看| 欧美理论片在线观看| 久久99九九| 激情啪啪网站| 免费三级片网址| 久久久夜夜夜| 国产白丝在线| 人妻中文字幕网| 老女人AV| 亚洲电影AV| 人人妻人人爽人人精品| 亚洲欧美综合| 久草视频资源| 中文字幕在线观看二区| 色九| 好吊一区二区三区| 边摸边插| 97AV在线| 在线免费观看一区| 日韩毛片在线| av色图| 91色区| 亚洲av电影网| 波多野结衣久久| 四虎影院最新地址| 亚洲无码图片| 五月在线| 水蜜桃网站| 超碰在线观看免费版| 刘玥一区二区三区| 安徽妇搡BBB搡BBBB户外老太太| 巨い巨乳の少妇あジed2k| 2022天天干| 东京热视频免费观看| 伊人天天干| 国产日韩欧美综合精品在线观看| 99久久久精品久久久久久| 俺来也俺去也www色官网| 日韩A片无码ⅩXXXX| 久久久XXX| 亚洲日韩欧美色图| 国产啊啊啊啊| 亚洲视屏| 国产精品一区二区AV日韩在线| 日韩精品成人片| 影音AV| 黑人无码一二三四五区| 大地影视官网第三页入口| 丁香五月婷婷在线| 欧美a在线| 91在线无码精品秘软件| 久久婷婷国产麻豆91天堂| 91探花国产综合在线精品| 中文字幕免费久久| 一级a一级a免费观看免免黄‘/| 国产成人a亚洲精品| 3级毛片| 九九综合精品| 91男女| 九九大香蕉| 色哟哟视频在线观看| 精品无码一区二区Av蜜桃| 91在线导航| 久久午夜福利视频| 欧美日韩在线视频一区| 成人激情综合网| 亚洲免费精品视频| 日韩一区二区三区无码电影| 美女天堂网| 黄片视频免费| 国产av网| 婷婷五月AV| 日韩www| 精品国精品自拍自在线| 青青青草视频在线| 黄色国产视频| 屁屁影院CCYYCOM发布地| 欧美疯狂做受XXXXX高潮| 国产无套进入免费| 黄片网站在线免费观看| 麻豆AV在线观看| 麻豆免费福利视频| 99久久精品国产成人一区二区 | 亚洲国产熟妇无码日韩| 午夜A片| 国产精久久| 国产精品无码在线| 亚洲中文字幕在线播放| 国产黄片在线视频| 午夜福利资源| 亚州精品国产精品乱码不99勇敢 | 国产av网| www.蜜桃视频| 91麻豆国产在线观看| 国产乱子伦无码视频免费| 国产精品精品| 夜夜网站| 激情婷婷综合| 亚洲人人操| 一级a一级a爰片免费免免中国A片| 精品黑人| 自拍偷拍网| 国产精品理论片| 91人妻无码精品一区二区| 99久久黄色| 老司机视频在线视频18|