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

: 我自己也是作電影院售票系統的，我知道這種東西最難在於選位， : 因為你必須去判斷每個位置有沒有被其他人選走， : 所以每個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分鐘)交割不成功,則將該座位再 掛回交易所裡面 -- 人類最大的問題在於 想要的東西很多 需要的東西卻很少 -- 接收server cluster寫入的receiver我猜想是使用socket select這類的 non-blocking I/O方法寫的,所以可能也是single thread,就不需要lock (server cluster中每台機器開一個socket連到交易搓合的server上) 其實交易搓合server並不需要接受很多socket連接,cluster中每台機器開一個 socket連過來即可;如果用戶數真的很多那cluster可以設計成多層式的架構 親，LMAX交易系統是使用Java開發的唷～ 估計是使用NIO，否則不太可能撐到這樣的處理能力 另外開發團隊為了加速還做了很多變態的tuning，例如幾乎所有object都要reuse， 目的是最大限度減少Java gc的工作量，因為gc在這個場景下顯得相當昂貴
※ 批踢踢實業坊(ptt.cc), 來自: 140.112.25.154
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1420645812.A.40E.html

→ LiloHuang: 多台機器同時寫到該巨大的 buffer 不需要 lock 同步? 01/07 23:56

→ typiacalcat: @lilo 不是已經說用single thread減少lock了嗎 01/08 00:00

→ LiloHuang: 他指的 single thread 是指在從巨大buffer讀取的部分吧 01/08 00:03

→ LiloHuang: 我的問題是一堆 server cluster 同時寫入到 buffer 時 01/08 00:03

→ LiloHuang: 該 Multi-producer/single-consumer 的 buffer queue 01/08 00:04

→ LiloHuang: 是有使用什麼特殊的技巧避開同步的問題嗎 ? 01/08 00:04

→ typiacalcat: 大都是用message queue處理 不是嗎? 01/08 00:10

→ LiloHuang: 單機也許可以用 Compare-and-swap 做 lock-free queue 01/08 00:10

→ LiloHuang: 多台機器寫到 message queue 應該會有 lock 吧 ? 01/08 00:13

→ typiacalcat: 如果你說的是MQ寫入時的lock 那確實省不了 01/08 00:15

→ LiloHuang: 這樣聽起來比較合理，謝謝 :) 01/08 00:16

→ typiacalcat: 不過那個lock的成本少到可以接受 並不需要到lockfree 01/08 00:17

→ LiloHuang: 我想也是相對的少很多，看來這會是個好方法 ^^ 01/08 00:17

→ LiloHuang: select 我想撐不了太多連線，至少我都是用 epoll_wait 01/08 00:27

→ LiloHuang: 儘管 non-blocking I/O 做 reactor pattern 01/08 00:28

→ LiloHuang: TCP 封包在連線時還是 concurrent connection 呀 XD 01/08 00:28

→ LiloHuang: 仔細想想你說的對，如果是用 epoll_wait 只開單核 01/08 00:29

→ LiloHuang: 可以避掉同步的問題，只是沒辦法發揮現代多核心的CPU 01/08 00:29

→ LiloHuang: 謝謝 :) 01/08 00:31

→ saladim: compare and swap是 lock的一種實作機制..用他等於用鎖 01/08 00:34

→ LiloHuang: 我指的是 x86 的 CMPXCHG instruction 01/08 00:36

→ saladim: 只是這種實做比較不費資源 busy-waiting 01/08 00:36

→ LiloHuang: 例如基於這個機制所做出來的 boost/lockfree/queue.hpp 01/08 00:36

→ LiloHuang: 這應該算是 CPU hardware level 的 lock 吧 XD 01/08 00:37

→ saladim: 就是你說的那個阿 CPU不支援硬體指令也做不出真正的鎖阿 01/08 00:38

推 LiloHuang: 哈哈...同意同意! 01/08 00:39

→ saladim: 大部分的鎖底層好像都要用到CPU硬體指令~ 01/08 00:39

→ LiloHuang: 現在都被要求多核心要吃滿，這種單執行緒思維，學習了 01/08 00:39

→ saladim: Java最最最下面也是CPU instruction~應該是吧? 01/08 00:45

→ LiloHuang: 我看過一點 Java 虛擬機原始碼，也是用C語言實作的。 01/08 00:46

→ LiloHuang: 不過我想不同作業系統對於底層實作還是略有差異才是 01/08 00:47

→ LiloHuang: 跑在 Windows 上有 IOCP 可以用，Linux 也有 AIO 可用 01/08 00:47

→ SirChen: 我的意思是說這系統用Java開發,所以不可能使用到這種 01/08 00:48

→ LiloHuang: 至於哪一個平台才能應付如此大量的需求，還請樓主介紹 01/08 00:48

→ SirChen: hardware dependent的解決辦法 01/08 00:48

→ LiloHuang: 嗯嗯...是使用 Java NIO 嗎? 還是有其他實現方式 01/08 00:49

→ typiacalcat: 不過這設計很吃單核能力 拉處理量只能花大錢scale-up 01/08 00:51

→ LiloHuang: 的確，一顆 Intel XEON E5 12核，不吃滿實在挺浪費的 01/08 00:52

→ LiloHuang: 比較大的問題是可能產生 Single point of failure 狀況 01/08 00:57

→ LiloHuang: 謝謝樓主回答，Java NIO 看來真的是個好東西 :) 01/08 01:00

→ LiloHuang: reuse object 還可以減少 memory fragmentation 很棒! 01/08 01:02

→ x000032001: 他們好像連cpu cache都tune了(抖 01/08 09:54