線程性能到達瓶頸，并發(fā)還是并行？

heguangwu

獲獎詳情：http://72891.cn/thread-4241378-1-1.html

首先，跟大家分享個陳年趣事:
幾年前，我去某軟公司應(yīng)聘，電話面試中與面試官有如下一番對話。 面試官：你了解多線程并發(fā)嗎？
我：不了解，我之前做業(yè)務(wù)系統(tǒng)，多線程很大程度上都是委托給容器的……
面試官：我理解了。你不太熟悉并發(fā)是嗎？
我：是的。
面試官：那我們還是來聊一聊并發(fā)吧。
祝大家線程安全。

案列介紹：
      最初是一個單線程程序性能到達瓶頸后，通過將整個作業(yè)切成一個個小任務(wù)，每一個任務(wù)執(zhí)行一個線程，運行結(jié)果發(fā)現(xiàn)居然和之前差不多，通過調(diào)試發(fā)現(xiàn)其中一個任務(wù)執(zhí)行時間過長，再動態(tài)調(diào)節(jié)該任務(wù)的線程數(shù)，當(dāng)發(fā)現(xiàn)隊列過多時啟動新線程來同時進行，結(jié)果性能上升不大，再定位發(fā)現(xiàn)多個線程競爭需要同步訪問同一個資源，修改為靜態(tài)線程池，再由上游哈希將數(shù)據(jù)放置不同的線程隊列中。
      進一步的性能提升發(fā)現(xiàn)怎么增大線程數(shù)性能都是這樣了，再檢查發(fā)現(xiàn)之前下游任務(wù)需要等待上游線程全部完成才能進一步操作，通過查閱資料找到一個算法只要上游有數(shù)據(jù)就可以開始進行計算，這樣到上游全部陸續(xù)完成時該步驟也只需要計算少量的數(shù)據(jù)就可以了。針對此問題您有什么更好的解決方法？


討論話題：（可任選一個或幾個）
1. 闡述一下你設(shè)計過的最滿意的并發(fā)/并行軟件架構(gòu)。
2. 詳細描述一下在多線程/進程/協(xié)程方式下遇到過的最難解決的問題以及如何解決的
3. 詳細講述一下曾經(jīng)使用過的最好的并發(fā)/并行組件
4. 對并行/并發(fā)的某一個理論進行詳細的說明


討論時間：2015年12月15日—2016年1月15日


獎勵設(shè)置：
活動結(jié)束后，我們將選取5位討論精彩的同學(xué)，各送技術(shù)圖書《七周七并發(fā)模型》一本。



作者： (美)Paul Butcher   
譯者： 黃炎
叢書名： 圖靈程序設(shè)計叢書
出版社：人民郵電出版社
ISBN：9787115386069
上架時間：2015-3-13
出版日期：2015 年4月
開本：16開
頁碼：234
版次：1-1

內(nèi)容簡介：并發(fā)編程近年逐漸熱起來，Go等并發(fā)語言也對并發(fā)編程提供了良好的支持，使得并發(fā)這個話題受到越來越多人的關(guān)注。本書延續(xù)了《七周七語言》的寫作風(fēng)格，通過以下七個精選的模型幫助讀者了解并發(fā)領(lǐng)域的輪廓：線程與鎖，函數(shù)式編程，Clojure，actor，通信順序進程，數(shù)據(jù)級并行，Lambda架構(gòu)。書中每一章都設(shè)計成三天的閱讀量。每天閱讀結(jié)束都會有相關(guān)練習(xí)，鞏固并擴展當(dāng)天的知識。每一章均有復(fù)習(xí)，用于概括本章模型的優(yōu)點和缺陷。


樣章試讀： 第1章　概述.pdf (1.11 MB, 下載次數(shù): 50)

2015-12-15 14:09 上傳

點擊文件名下載附件

---------------------------------------------------------分割線---------------------------------------------------------------------
其實案例我想描述的更清楚一些，因為當(dāng)時沒有時間，現(xiàn)在補充如下：
軟件功能描述，通過libpcap抓取Mysql的包，并按照Mysql協(xié)議分解后將數(shù)據(jù)發(fā)送到Kafka供后續(xù)的分析實現(xiàn)，軟件架構(gòu)如下：
pcapThread---->TcpProcThread----->MysqlProcThread----->KafkaSendThread
各線程作用比較清晰，pcap線程調(diào)用libpcap的接口獲取抓包，并根據(jù)配置排除掉不屬于本機或黑名單中的抓包，并將TCP/IP頭域?qū)⒔忾_有用的放到一個數(shù)據(jù)結(jié)構(gòu)中
TcpProc線程負責(zé)TCP的排序，包括亂序重傳等處理，將有效的消息發(fā)送到Mysql線程處理，MySQL線程根據(jù)MySQL協(xié)議提取SQL語句和結(jié)果元數(shù)據(jù)信息組成json格式并調(diào)用rdkafka庫發(fā)送
之前開發(fā)為簡便實現(xiàn)，各線程之間通信采用出入隊列方式，同步采用互斥鎖，在QPS比較小的機器上測試正常，但上線到QPS比較大機器上，pcapThread出現(xiàn)丟包且比較嚴重
同時CPU飚的很高，直接占據(jù)單個核的100%，當(dāng)前通過一些手段，如鎖改為條件變量、使用無鎖隊列等，CPU下降到30%，丟包從30%以上下降到10%以下，但優(yōu)化還未完成，如果大家有興趣也可以直接根據(jù)這個現(xiàn)實的案例來思考發(fā)散。

chenxing2

這個好像很難，沒人回了......

demilich

才看到，居然沒有人回答 ... 支持一下，期待大�；卮�

sjf0115

主要是沒用到過

heguangwu

其實案例我想描述的更清楚一些，因為當(dāng)時沒有時間，現(xiàn)在補充如下：
軟件功能描述，通過libpcap抓取Mysql的包，并按照Mysql協(xié)議分解后將數(shù)據(jù)發(fā)送到Kafka供后續(xù)的分析實現(xiàn)，軟件架構(gòu)如下：
pcapThread---->TcpProcThread----->MysqlProcThread----->KafkaSendThread
各線程作用比較清晰，pcap線程調(diào)用libpcap的接口獲取抓包，并根據(jù)配置排除掉不屬于本機或黑名單中的抓包，并將TCP/IP頭域?qū)⒔忾_有用的放到一個數(shù)據(jù)結(jié)構(gòu)中
TcpProc線程負責(zé)TCP的排序，包括亂序重傳等處理，將有效的消息發(fā)送到Mysql線程處理，MySQL線程根據(jù)MySQL協(xié)議提取SQL語句和結(jié)果元數(shù)據(jù)信息組成json格式并調(diào)用rdkafka庫發(fā)送
之前開發(fā)為簡便實現(xiàn)，各線程之間通信采用出入隊列方式，同步采用互斥鎖，在QPS比較小的機器上測試正常，但上線到QPS比較大機器上，pcapThread出現(xiàn)丟包且比較嚴重
同時CPU飚的很高，直接占據(jù)單個核的100%，當(dāng)前通過一些手段，如鎖改為條件變量、使用無鎖隊列等，CPU下降到30%，丟包從30%以上下降到10%以下，但優(yōu)化還未完成
后續(xù)做完后有時間總結(jié)一下發(fā)到這里更合適一些

王楠w_n

大牛在下面回復(fù)了，可以給大家普及寫各位不懂的領(lǐng)域，希望大家能得到更多回復(fù) 4# sjf0115


   

sjf0115

回復(fù) 6# 王楠w_n


    恩  就是希望在這個平臺學(xué)到自己感興趣的知識

laputa73

一直覺得線程狠復(fù)雜，性能也狠差。
基于線程模型的java服務(wù)器，跑到500并發(fā)已經(jīng)狠了不起了。
基于事件的就可以輕松上萬并發(fā)。但是回調(diào)寫起來讓頭大。
最早接觸協(xié)程是通過erlang.這個對后續(xù)的影響很大。
但是erlang的學(xué)習(xí)門檻確實比較高。
后來又陸續(xù)看了lua的協(xié)程和perl的coro,python的stackless和gevent.
感覺協(xié)程確實是個好東西，高大上，但是組件級別的支持還是比較別扭。
golang一出，語言級支持協(xié)程并發(fā)，而且還同時支持多核并行。
沒有什么可猶豫的，直接擁抱go吧。
java的同學(xué)，估計轉(zhuǎn)scala比較容易。

chenxing2

回復(fù) 5# heguangwu


看描述，pcapThread用來抓包，然后還處理。當(dāng)QPS高的時候，處理慢了，丟包正常。

建議 抓包和處理數(shù)據(jù)分開。

pcapThread抓包后，直接發(fā)到kafka，然后多個消費者取包，然后處理，再繼續(xù)后面的處理，根據(jù)量還可增加消費者

如：

寶突然增加的時候，kafka也可以積壓存儲，保證丟包率比較低
pcapThread(抓包)  --> kafka   --> 增加一個程序（根據(jù)配置排除掉不屬于本機或黑名單中的抓包，并將TCP/IP頭域?qū)⒔忾_有用的放到一個數(shù)據(jù)結(jié)構(gòu)中） --> kafka --> TcpProcThread --> kafka -->MysqlProcThread -->KafkaSendThread

heguangwu

pcapThread并沒有做業(yè)務(wù)處理，只是做了一些及其簡單的過濾，如去掉了長度為0的包，這個不是丟包的原因，因為哪怕我直接將數(shù)據(jù)放入下一個線程的隊列同樣會丟包
回復(fù) 9# chenxing2