問題描述

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

問題解答

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

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

分布式session管理

我出個(gè)簡單一點(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)，如果超過一定周期沒上報(bào)就認(rèn)為該設(shè)備已經(jīng)離線

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

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

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

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

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