問(wèn)題描述

對(duì)于高并發(fā)不太了解，這種應(yīng)該怎么處理？高并發(fā)有什么入門(mén)書(shū)籍嗎

問(wèn)題解答

直接用TCP 長(zhǎng)連接～ 智能家居一般 MQTT 協(xié)議比較多～～長(zhǎng)連接比輪詢省太多資源了～單機(jī)情況下還是可以實(shí)現(xiàn)的，當(dāng)然，算上數(shù)據(jù)庫(kù)就另說(shuō)了。

這里想考察你對(duì)分布式架構(gòu)的認(rèn)識(shí)，就這個(gè)問(wèn)題應(yīng)該是想考察你對(duì)于服務(wù)發(fā)現(xiàn)(service discovery)的認(rèn)識(shí)。分布式就是把一個(gè)大型項(xiàng)目進(jìn)行模塊化拆分，然后各模塊在做集群部署，前端有一個(gè)路由服務(wù)器來(lái)對(duì)到達(dá)的請(qǐng)求進(jìn)行分發(fā)，把到達(dá)的請(qǐng)求路由到能夠提供服務(wù)的服務(wù)端，而哪臺(tái)服務(wù)器能夠提供服務(wù)這就是服務(wù)發(fā)現(xiàn)所要做的事情，而在集群環(huán)境下能夠提供相等服務(wù)的服務(wù)器肯定不止一臺(tái)，那到底該由那臺(tái)服務(wù)器對(duì)用戶的請(qǐng)求進(jìn)行處理并響應(yīng)呢？這就又引出了負(fù)載均衡，由負(fù)載均衡層通過(guò)特定的算法來(lái)判斷應(yīng)該由那臺(tái)服務(wù)器提供服務(wù)，目的就是均勻的把請(qǐng)求分發(fā)給各個(gè)服務(wù)端。服務(wù)發(fā)現(xiàn)可以了解下Apache的zookeeper或者Netflix的Eureka。微服務(wù)這塊spring cloud提供了全套的解決方案，還有阿里的dubbo

分布式session管理

我出個(gè)簡(jiǎn)單一點(diǎn)方案給設(shè)備安裝一個(gè)代理進(jìn)程，設(shè)備啟動(dòng)時(shí)啟動(dòng)該進(jìn)程，然后由進(jìn)程主動(dòng)定時(shí)向服務(wù)器上報(bào)設(shè)備狀態(tài)，如果超過(guò)一定周期沒(méi)上報(bào)就認(rèn)為該設(shè)備已經(jīng)離線

高并發(fā)，異步通信。java 的話。。。 經(jīng)典的 netty ？個(gè)人意見(jiàn)，按目前的單機(jī)性能，100k并發(fā)單機(jī)能撐住，分布式處理不是必選項(xiàng)，當(dāng)然要是算上數(shù)據(jù)庫(kù)存儲(chǔ)什么的就另說(shuō)了。

假如不考慮長(zhǎng)連接的話，有個(gè)思路 利用redis設(shè)置一個(gè)每個(gè)設(shè)備上線flag并設(shè)置其一個(gè)有效時(shí)間 客戶端每次做上行請(qǐng)求的時(shí)候刷新該有效時(shí)間 每次統(tǒng)計(jì)redis在線狀態(tài)設(shè)備數(shù)量就好了 這里關(guān)鍵是這個(gè)時(shí)間的長(zhǎng)度怎么來(lái)定 因?yàn)橐恢笔亲龊蠖说? 不清楚這里客戶端不活躍的情況下能保持在線多久 是否有類(lèi)似守護(hù)進(jìn)程之類(lèi)的

把數(shù)據(jù)存儲(chǔ)在redis里面，存取相對(duì)于db快

是我的話,我會(huì)這樣做:新建一個(gè)MySQL內(nèi)存表(ENGINE=MEMORY):online(user_id, update_time)用update_time記錄用戶最近訪問(wèn)時(shí)間.比如可以假設(shè)在5分鐘以內(nèi)的用戶都認(rèn)為在線.

可以分層實(shí)現(xiàn)，舉個(gè)例子，比如10w臺(tái)機(jī)器，分別向10臺(tái)機(jī)器上報(bào)本機(jī)狀況，10w臺(tái)怎么對(duì)應(yīng)10臺(tái)，可以通過(guò)hash映射的方式，然后這10臺(tái)機(jī)器再把出現(xiàn)故障的機(jī)器向一個(gè)固定的主機(jī)上報(bào)情況，大概意思就是10w-->10-->1，上述例子可能存在單點(diǎn)故障，可以通過(guò)改變上層機(jī)器數(shù)解決單點(diǎn)故障