實現一個行情伺服器，支持10萬級別的行情客戶端連接，實時推送行情，用什麼開源框架來搭建比較好？

01-21

目前想到用zeromq來實現，不知道是否合適，或者有更好的選擇？

10 萬個客戶端是app、web還是別的？它們通過什麼方式上網？你準備用多少台伺服器？實時性要求具體指標是什麼？

這問題是釣魚還是完全沒概念？拋個zeromq，好比提問我想開個飯館，打算用景德鎮瓷器好不好，點沒錯，面完全不對。

提供個最標準的技術方案吧。

首先我假定你的需求是全端的，app web 甚至加上桌面客戶端，那麼需要：

1. app

分為android和ios兩大平台，可以考慮使用react native，代碼基本可以復用。

2. web前端

html css加上js，如上可以考慮用react完整技術棧，也可以用vue等其它類庫。還需要一個或多個charts開源圖表類庫繪製前端圖表。

3. 桌面客戶端

使用electron。一次開發支持linux win macos三大平台，大部分代碼可以和web前端復用，本地存儲使用sqlite。

4. web後端

可選擇的很多，python php java go ruby nodejs都可選，c c++就不要考慮了，不是不行，做web項目太累。後端提供rest風格的api就可以，所有的客戶端調用同一套api。一般特定的開源框架說法，也是指向這一層，推薦一些個人最偏愛的，php - lumen，python - flask，java - spring，node - koa，go - denco，ruby當然是rails。。。

5. 資料庫

10萬客戶端加實時行情量級並不是很大，就不建議馬上上分庫分表，高可用大集群之類的方案了。優先選擇雲端實例模式，比如阿里雲的RDS。自己搭建的話，一主二從做好同步和讀寫分離，再加個延時冷備的庫，基本夠用。可選mysql或postgresql，mysql技術層面接受度會高很多。

6. 緩存

推薦使用redis，完全當緩存用，不要考慮持久化存儲。初期隨意混用會加大架構複雜度。redis也有雲端實例直接購買使用，自己搭建可以搞個2 3個點的小集群，也夠用了。

7. 隊列

這裡才是題設中的zeromq用武之地，但是我們有更好的選擇。考慮穩定性，持久化，更多特性的，可以選用rabbitmq，完勝zeromq。考慮極致性能的，選用kafka。

8. 代理層

lvs集群接下所有網路請求再分發，選用雲端產品的話不用考慮。

9. web伺服器

nginx最佳選擇，考慮openresty改版，很多全局邏輯，如限流等，可以在這層寫lua腳本實現，簡單強大。nginx配置反向代理，直接指向web後端提供的服務埠，web後端伺服器上可以跑多進程，佔用多個埠實現。

10. 跨服session

復用上面的redis緩存，session存儲在緩存中。

11. 連接層

dns和域名，找個靠譜的域名商購買加備案，dns可以購買dnspod服務。鏈路最好全部https，需要花錢買證書，或者使用let"s encrypt的免費證書。

12. 連接方式

實時行情實時性要求高，就推薦長連接的方式了，最佳選擇websocket。輪詢的方式也可以。

13. 伺服器

直接購買選用雲環境的全套吧，加上帶寬。這個規模下，自建的成本優勢還體現不出來，直接使用全套雲基礎設施，時間和資金成本都節約很多。阿里雲，騰訊雲，或者其它雲商都可以考慮，實際測試比對之後選擇。

14. cdn

既然是實時行情，cdn作用不大，但是為了分擔靜態資源請求壓力和加快訪問，可以考慮買個七牛的cdn服務。

==== 可選 ====

15. 存儲

開始估計還用不上，如果有大量歷史數據需要存儲，可以考慮搭建一套。可選方案也很多，ceph，weedfs，hdfs，首選hdfs。

16. 監控等周邊配套

很多團隊初期會不考慮，可以視情況購買些服務。

17. 安全

扯開又是大話題了，初期基本也不會多加考慮，數據保證接近實時備份吧

18. 搜索

開始也用不上吧？如果需要，要搭建一套搜索索引集群，可選solr和es，推薦es。

19. 其它

如果開始web後端選型選的是java，可能還要一些中間件，資料庫訪問，rpc服務治理用的dubbo等，視情況使用。

如果要保證各個集群高可用性，還需要選擇zookeeper或者keepalive之類的方案。

如果業務上有使用需求，可以購買郵件群發，簡訊群發，app推送，支付接入等服務，都有專業的公司提供。

做完這些，產品才算可用了！

你要的是框架，光提個zeromq是幾個意思？

zeromq是框架？話說你到底知不知道zeromq是什麼東西？能幹什麼不能幹什麼？

算了，就以你目前表現出來的技能儲備，這錢你省不了，乖乖的掏錢吧。

沒必要自己做啊。

直接調用mipush、個推之類的就行了啊。

郭忠明

我覺得核心還是要有一個內存資料庫，memcached之類的都可以，然後主要數據都是有一個主更新線程將最新的數據更新到內存資料庫（可以是多台），做
一個或者多個Web伺服器提供只讀查詢業務，用PHP處理客戶端發來的請求，PHP連接到內存資料庫進行查詢,
這樣基本沒有多少代碼就可以實現，主要的架構也都是開源的。

任職某券商行情系統架構師，今年最主要的績效就是上線我們新一代的行情系統。

這裡面涉及的問題很多，首先回答你的問題，zmq 是可以的，但僅限於簡單、低負載系統，這也是我們推翻老行情系統的主要原因之一（我們也用zmq）；其他人有提到內存DB、匯流排這些，也是不適合高性能行情系統的。

其他的內容如果有興趣的話，可以留言告訴我，有時間再寫。

幾十到200萬TCP長連接並發，github上搜gMaxLinked，我用epoll和c++寫的，附帶C和JAVA的客戶端示例，這幾年我的幾個項目上都用了，抱歉文檔不完善，需要支持的話聯繫我吧。

更新：

有些知友說在github上沒搜到，我直接給地址：https://github.com/shoutrain/gMaxLinked

加個watch，打個星哦：）

新浪早就有這玩意。不過只有push沒有差分，這和新浪本業務的歷史有關係。

Httpd問題不大的，關鍵是pubsub。現在的伺服器，一台機器就夠，甚至還有足夠的資源跑wss。

當然為了可用性不可能只用1台的。所以那些選項都能做，關鍵還是pubsub。

mqtt,mosquito 是最好的

關於大量數據推送也是需要研究的。

多少行代碼根本沒意義，那個程序能比過500行DDoS腳本？

需求太籠統！

我以前就是做行情服務後端的，用Java自己寫NIO實現，當時水平菜，只能達到2-3萬在線（並無完全推送）。

你這裡面缺少了很多指標，比如你到底提供的是5檔行情，還是10檔行情？你計划行情數據多長時間刷新一次？經驗來看，10萬級別的用戶，瓶頸不僅在CPU和內存了，更多在於網路帶寬，你有沒有算過，你的10萬用戶里，都是傳一些什麼樣的數據？用肯定是二進位格式吧？如果用快速低端的純文件，要不要壓縮？每個用戶平均每次推送傳輸多大的數據量？然後把這個數據量乘以10萬，你的帶寬是否能承受？初始用戶的數據有多大？如果像我們以前開發的Web端行情，數據是不能保存的，每次用戶初始，都有好幾百KB的數據要傳到客戶端瀏覽器，比如A股、B股、H股的所有股票。你的10萬用戶要不要考慮這些？用戶在看行情的時候，信息地雷要不要推薦？用戶會不會看F10信息？會不會看各種K線？你計劃用TCP還是UDP？可能有人會懷疑，還會有UDP嗎？我有見過！大連期貨交易的數據（具體哪家提供的不清楚）就是在公網上用UDP的

可能我的回答不是你想要的，但要做這個，真是要想清楚需求。

單伺服器節點，採用TCP長連接，什麼Q都不需要，如果採用多進程或多伺服器節點，用什麼Q都可以，也可以用TCP長連接來做Q，總之，這個問題的關鍵是大量TCP長連接，而不是Q.

行情伺服器為啥要推送，而不是客戶端主動查詢？

老闆，拉個微信群，發個紅包唄。

In ZeroMQ, simple tries are used to store and match PUB/SUB subscriptions. The subscription mechanism was intended for up to 10,000 subscriptions where simple trie works well. However, there are users who use as much as 150,000,000 subscriptions. In such cases there"s a need for a more efficient data structure. Thus, nanomsg uses memory-efficient version of Patricia trie instead of simple trie.

zmq是可以的，但要注意用什麼樣的協議，很多人說tcp長連接，根據我的經驗，卻應該是組播。