Re: [請益] 請問寬宏售票為何常當機?

看板Soft_Job作者 (vanilla tobacco)時間11年前 (2015/01/07 23:50), 11年前編輯推噓1(1推 0噓 41→)
留言42則, 5人參與, 最新討論串16/21 (看更多)
※ 引述《y2468101216 (芸)》之銘言： : 我自己也是作電影院售票系統的，我知道這種東西最難在於選位， : 因為你必須去判斷每個位置有沒有被其他人選走， : 所以每個request都必須等待前一個作完。 這個場景我仔細想了一下,使用類似LMAX交易系統的架構應該挺合適 前端和用戶交互的部分使用server cluster,但交易搓合全部集中到一台server 這篇文章解釋得比較詳細 http://martinfowler.com/articles/lmax.html 簡單來說就是業務邏輯中會出現競爭的部分全部交給一台server,一顆cpu, 而且是single thread,不斷的從一個巨大的buffer(LMAX Disruptor)中讀取從 server cluster送來的掛單然後進行處理;因為是single thread所以沒有同步的問題 這樣的設計可以最大限度地減少使用lock 據LMAX宣稱他們的系統每秒最多可處理6百萬個交易,而且latency極低 : 我認為比較好的作法應該是作切割，把每個區都分給不同的server作管理，然後讓 : server去作判斷現在連線數有沒有大於該區的座位數， : 有就問使用者要不要繼續等待前面的人連完。 : 跟pchome那種限時搶購最大的不同在於每個座位都是獨一無二的。 : 比喻而言就是1280000項商品同時開賣只賣一件， : 所以你至少要能夠應付這麼多的連線數，我不認為寬宏有準備好。 使用股票交易系統的模型: 每場演唱會彼此都是獨立的,可以看做不同的交易所,彼此無關 每場演唱會的座位一萬五千多個,每個都是唯一的,可以看做交易所有 一萬五千多支股票掛牌,每檔股票都有一張單掛賣出,賣方都是同一個人(主辦單位) 而每個用戶訂位就好比股票掛買單要買一張,交易所收單搓合 若是搖滾區不區分座位只限人數的話就好比一檔股票賣方掛賣n張 交易所的搓合並不處理交割,因為: 1.交割牽扯到呼叫銀行金流API,latency很高 2.每個用戶的交割和其他的用戶是無關的,可以平行處理 3.交割處理的時效性要求不高 搶票系統也可以比照辦理,搶到票只是出個通知,你可以去辦交割了,交割在另外的 module做,可以平行處理,若在一個時限內(例如30分鐘)交割不成功,則將該座位再 掛回交易所裡面 -- 人類最大的問題在於 想要的東西很多 需要的東西卻很少 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.25.154 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1420645812.A.40E.html
→
01/07 23:56, , 1F
多台機器同時寫到該巨大的 buffer 不需要 lock 同步?
01/07 23:56, 1F
→
01/08 00:00, , 2F
@lilo 不是已經說用single thread減少lock了嗎
01/08 00:00, 2F
→
01/08 00:03, , 3F
他指的 single thread 是指在從巨大buffer讀取的部分吧
01/08 00:03, 3F
→
01/08 00:03, , 4F
我的問題是一堆 server cluster 同時寫入到 buffer 時
01/08 00:03, 4F
→
01/08 00:04, , 5F
該 Multi-producer/single-consumer 的 buffer queue
01/08 00:04, 5F
→
01/08 00:04, , 6F
是有使用什麼特殊的技巧避開同步的問題嗎 ?
01/08 00:04, 6F
→
01/08 00:10, , 7F
大都是用message queue處理 不是嗎?
01/08 00:10, 7F
→
01/08 00:10, , 8F
單機也許可以用 Compare-and-swap 做 lock-free queue
01/08 00:10, 8F
→
01/08 00:13, , 9F
多台機器寫到 message queue 應該會有 lock 吧 ?
01/08 00:13, 9F
→
01/08 00:15, , 10F
如果你說的是MQ寫入時的lock 那確實省不了
01/08 00:15, 10F
→
01/08 00:16, , 11F
這樣聽起來比較合理，謝謝 :)
01/08 00:16, 11F
→
01/08 00:17, , 12F
不過那個lock的成本少到可以接受 並不需要到lockfree
01/08 00:17, 12F
→
01/08 00:17, , 13F
我想也是相對的少很多，看來這會是個好方法 ^^
01/08 00:17, 13F
接收server cluster寫入的receiver我猜想是使用socket select這類的 non-blocking I/O方法寫的,所以可能也是single thread,就不需要lock (server cluster中每台機器開一個socket連到交易搓合的server上) ※ 編輯: SirChen (140.112.25.154), 01/08/2015 00:25:33 ※ 編輯: SirChen (140.112.25.154), 01/08/2015 00:29:05
→
01/08 00:27, , 14F
select 我想撐不了太多連線，至少我都是用 epoll_wait
01/08 00:27, 14F
→
01/08 00:28, , 15F
儘管 non-blocking I/O 做 reactor pattern
01/08 00:28, 15F
→
01/08 00:28, , 16F
TCP 封包在連線時還是 concurrent connection 呀 XD
01/08 00:28, 16F
→
01/08 00:29, , 17F
仔細想想你說的對，如果是用 epoll_wait 只開單核
01/08 00:29, 17F
→
01/08 00:29, , 18F
可以避掉同步的問題，只是沒辦法發揮現代多核心的CPU
01/08 00:29, 18F
其實交易搓合server並不需要接受很多socket連接,cluster中每台機器開一個 socket連過來即可;如果用戶數真的很多那cluster可以設計成多層式的架構 ※ 編輯: SirChen (140.112.25.154), 01/08/2015 00:35:03
→
01/08 00:31, , 19F
謝謝 :)
01/08 00:31, 19F
→
01/08 00:34, , 20F
compare and swap是 lock的一種實作機制..用他等於用鎖
01/08 00:34, 20F
→
01/08 00:36, , 21F
我指的是 x86 的 CMPXCHG instruction
01/08 00:36, 21F
→
01/08 00:36, , 22F
只是這種實做比較不費資源 busy-waiting
01/08 00:36, 22F
→
01/08 00:36, , 23F
例如基於這個機制所做出來的 boost/lockfree/queue.hpp
01/08 00:36, 23F
→
01/08 00:37, , 24F
這應該算是 CPU hardware level 的 lock 吧 XD
01/08 00:37, 24F
→
01/08 00:38, , 25F
就是你說的那個阿 CPU不支援硬體指令也做不出真正的鎖阿
01/08 00:38, 25F
推
01/08 00:39, , 26F
哈哈...同意同意!
01/08 00:39, 26F
→
01/08 00:39, , 27F
大部分的鎖底層好像都要用到CPU硬體指令~
01/08 00:39, 27F
親，LMAX交易系統是使用Java開發的唷～
→
01/08 00:39, , 28F
現在都被要求多核心要吃滿，這種單執行緒思維，學習了
01/08 00:39, 28F
※ 編輯: SirChen (140.112.25.154), 01/08/2015 00:41:56
→
01/08 00:45, , 29F
Java最最最下面也是CPU instruction~應該是吧?
01/08 00:45, 29F
→
01/08 00:46, , 30F
我看過一點 Java 虛擬機原始碼，也是用C語言實作的。
01/08 00:46, 30F
→
01/08 00:47, , 31F
不過我想不同作業系統對於底層實作還是略有差異才是
01/08 00:47, 31F
→
01/08 00:47, , 32F
跑在 Windows 上有 IOCP 可以用，Linux 也有 AIO 可用
01/08 00:47, 32F
→
01/08 00:48, , 33F
我的意思是說這系統用Java開發,所以不可能使用到這種
01/08 00:48, 33F
→
01/08 00:48, , 34F
至於哪一個平台才能應付如此大量的需求，還請樓主介紹
01/08 00:48, 34F
→
01/08 00:48, , 35F
hardware dependent的解決辦法
01/08 00:48, 35F
→
01/08 00:49, , 36F
嗯嗯...是使用 Java NIO 嗎? 還是有其他實現方式
01/08 00:49, 36F
估計是使用NIO，否則不太可能撐到這樣的處理能力 另外開發團隊為了加速還做了很多變態的tuning，例如幾乎所有object都要reuse， 目的是最大限度減少Java gc的工作量，因為gc在這個場景下顯得相當昂貴
→
01/08 00:51, , 37F
不過這設計很吃單核能力 拉處理量只能花大錢scale-up
01/08 00:51, 37F
→
01/08 00:52, , 38F
的確，一顆 Intel XEON E5 12核，不吃滿實在挺浪費的
01/08 00:52, 38F
※ 編輯: SirChen (140.112.25.154), 01/08/2015 00:59:26
→
01/08 00:57, , 39F
比較大的問題是可能產生 Single point of failure 狀況
01/08 00:57, 39F
→
01/08 01:00, , 40F
謝謝樓主回答，Java NIO 看來真的是個好東西 :)
01/08 01:00, 40F
→
01/08 01:02, , 41F
reuse object 還可以減少 memory fragmentation 很棒!
01/08 01:02, 41F
→
01/08 09:54, , 42F
他們好像連cpu cache都tune了(抖
01/08 09:54, 42F
‣ 更多 SirChen 的文章
文章代碼(AID): #1KhLMqGE (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 16 之 21 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共21篇)
‣ 更多 SirChen 的文章
文章代碼(AID): #1KhLMqGE (Soft_Job)