boost asio coroutine連接池

lims_xlh

在采用asio coroutine多線程網(wǎng)絡(luò)的時(shí)候，每個(gè)線程綁定到一個(gè)io_service,這樣的話怎么在不加鎖的情況下使用socket連接池來(lái)處理連接復(fù)用

yulihua49

lims_xlh 發(fā)表于 2015-04-09 17:49
在采用asio coroutine多線程網(wǎng)絡(luò)的時(shí)候，每個(gè)線程綁定到一個(gè)io_service,這樣的話怎么在不加鎖的情況下使用s ...

我這兩天正做這個(gè)，快成了，還在調(diào)試。
三維的連接池管理。

一個(gè)服務(wù)器多個(gè)連接。
多個(gè)服務(wù)器組成cluster。有負(fù)載均衡和容錯(cuò)功能。
多個(gè)cluster構(gòu)成一個(gè)路由系統(tǒng)，根據(jù)需求選擇路由（應(yīng)用路由，或稱交易路由）。

AIO coroutine 線程池  epoll  都用上了，看來(lái)還工作的不錯(cuò)，就是容錯(cuò)還有些問(wèn)題，過(guò)幾天就可能調(diào)好了。
不過(guò)，任何一個(gè)server并不綁定線程�？蛻舳�、線程、協(xié)程、服務(wù)器的連接，誰(shuí)也沒(méi)綁定誰(shuí)，亂跳。線程鎖是少不了的，不過(guò)設(shè)計(jì)好了，它并不影響性能。
壓力測(cè)試，看日志，各種資源的隨機(jī)組合，眼花繚亂的。

其實(shí)線程鎖并不是那么可怕。影響性能的首要因素是寫(xiě)日志。其次是epoll的激活過(guò)程（單個(gè)epfd每秒最多激活15萬(wàn)次，與核和線程數(shù)無(wú)關(guān)）。這倆其實(shí)也是鎖，內(nèi)部的，你管不了。其它鎖對(duì)性能對(duì)影響可忽略不計(jì)。

沒(méi)用boost，擔(dān)心其性能。
用的ucontext，擔(dān)心將來(lái)系統(tǒng)不支持。

將來(lái)有空研究下 setjmp/longjmp 的實(shí)現(xiàn)方法。

lims_xlh

回復(fù) 2# yulihua49
但是對(duì)于異步 coroutine來(lái)說(shuō)鎖的開(kāi)銷是比較大的，因?yàn)楫惒绞怯帽M可能少的線程去做盡可能多的事情，有鎖等待就意味著它處理的其他的事情
精力變少了，會(huì)很影響性能吧，我現(xiàn)在的做法是每個(gè)線程內(nèi)維護(hù)一個(gè)連接隊(duì)列，每次來(lái)了client從連接里面拿一個(gè)，不知道有沒(méi)有別的成熟的方案


   

yulihua49

lims_xlh 發(fā)表于 2015-04-10 10:13
回復(fù) 2# yulihua49
但是對(duì)于異步 coroutine來(lái)說(shuō)鎖的開(kāi)銷是比較大的，因?yàn)楫惒绞怯帽M可能少的線程去做盡可 ...

總共就是一個(gè)context池，accept，來(lái)了個(gè)連接，就分配給它一個(gè)。然后丟到epoll隊(duì)列里。此后這個(gè)context就是獨(dú)享的了，操作這個(gè)context不需要鎖。前提是epoll沒(méi)有驚群，就是沒(méi)有把一個(gè)context分配給多個(gè)線程。
其他線程都在epoll_wait。抓到event，取出context，這時(shí)，線程才臨時(shí)有了context。它沒(méi)有固定的context。
鎖的問(wèn)題比較復(fù)雜，一句兩句說(shuō)不清，總之要避免“無(wú)謂”的等待。
我一直主張采用一種成熟的中間件，自己寫(xiě)這些程序要面臨很多的問(wèn)題。

yulihua49

lims_xlh 發(fā)表于 2015-04-10 10:13
回復(fù) 2# yulihua49
但是對(duì)于異步 coroutine來(lái)說(shuō)鎖的開(kāi)銷是比較大的，因?yàn)楫惒绞怯帽M可能少的線程去做盡可 ...

每個(gè)線程內(nèi)維護(hù)一個(gè)連接隊(duì)列，每次來(lái)了client從連接里面拿一個(gè)-------這個(gè)client綁在這個(gè)線程了？不利于負(fù)載均衡。
還是不要綁定的好，那個(gè)線程有空就哪個(gè)線程干。這樣平均響應(yīng)時(shí)間才快。
給你一種評(píng)估方法：最長(zhǎng)響應(yīng)時(shí)間/平均響應(yīng)時(shí)間，越小越好，你可以把幾個(gè)方案評(píng)測(cè)一下。

lims_xlh

回復(fù) 4# yulihua49
我上面可能沒(méi)說(shuō)清楚：
我現(xiàn)在的情況是這樣的，我使用的boost asio 加coroutine，
boost asio 用IOCP封裝了epoll ，我現(xiàn)在有一個(gè)線程，accept一個(gè)客戶端，然后給客戶端分配一個(gè)socket（連接后端服務(wù)的socket）去連接后端服務(wù)做業(yè)務(wù)，
在這個(gè)socket上面可能會(huì)讀寫(xiě)數(shù)據(jù)，但是iocp是等到讀寫(xiě)事件完成了之后就回調(diào)完成函數(shù)，在等待讀寫(xiě)時(shí)間的過(guò)程中courotine是可以讓這個(gè)線程去accept
新的客戶端的，這樣這個(gè)新的客戶端可能也需要一個(gè)socket去處理后端業(yè)務(wù)。

根據(jù)上面情況每個(gè)線程就會(huì)操作多個(gè)client和 socket，我怎么更好的復(fù)用這個(gè)線程使用的所有的socket呢？

   

yulihua49

回復(fù) 6# lims_xlh

一個(gè)主線程accept，得到客戶socket后分配它c(diǎn)ontext。然后拋給epoll。繼續(xù)accept。
一群工作線程epoll_wait,誰(shuí)撿到event算誰(shuí)的。這樣，所有的工作線程搶所有的context。


   

yulihua49

yulihua49 發(fā)表于 2015-04-09 20:30
我這兩天正做這個(gè)，快成了，還在調(diào)試。
三維的連接池管理。

容錯(cuò)測(cè)試今天基本通過(guò)。

yulihua49

[quote]BetonArmEE 發(fā)表于 2015-04-13 18:23
牛逼。我現(xiàn)在整天都在寫(xiě)業(yè)務(wù)，沒(méi)時(shí)間搞技術(shù)了，唉[/quote
嗯。
平臺(tái)需要專人搞。做業(yè)務(wù)哪有功夫弄平臺(tái)？一個(gè)東西要弄好幾個(gè)月，只用于一個(gè)項(xiàng)目未免成本過(guò)高，再說(shuō)一般情況也不允許花這么大代價(jià)搞基礎(chǔ)設(shè)施。
另一方面，如果你的平臺(tái)沒(méi)有集成盡可能多的精英技術(shù)，也就失去了存在價(jià)值。
都是常規(guī)技術(shù)，人家用不著你，自己都解決了。

不過(guò)我的體會(huì)，倒不是這些技術(shù)有多精英，而是在把它們組合在一起時(shí)，太多的不確定性。組合成穩(wěn)定的大雜燴，太困難了。

G5是你的？我原想結(jié)合G5來(lái)做負(fù)載均衡�，F(xiàn)在看來(lái)不用了。樓上那個(gè)架構(gòu)，包含了負(fù)載均衡／容錯(cuò)層，夠用了。
對(duì)G5依然很讚賞。

容錯(cuò)還有不滿意，keepalive有時(shí)還是需要較長(zhǎng)的時(shí)間才能確認(rèn)一個(gè)資源失效。