這樣做基本上客戶端和服務(wù)端都會出問題。

從體驗上來講：
10000個離線消息全部同時發(fā)給用戶，這個用戶基本不會把10000個消息全部看完，假設(shè)每個消息1秒掃過也需要2-3個小時看完所有。一般只會看最新的幾個或幾十個。發(fā)送太多數(shù)據(jù)是一種浪費。

從性能上來講：
第一，客戶端瞬間接收10000個消息，客戶端可能會直接崩潰，即使不崩潰客戶端也會出現(xiàn)一定時間卡頓，非常影響用戶體驗。

第二，服務(wù)端性能損耗巨大，從存儲中讀取10000個消息是一個比較耗時耗內(nèi)存的過程，一個用戶還好，假如有成百上千個用戶同時讀取這么大的量，存儲基本上直接死掉，整個業(yè)務(wù)直接掛掉。

cpu消耗巨大，按照你的說法for循環(huán)不間斷的給一個客戶發(fā)送10000條消息。每次調(diào)用接口都要消耗cpu的，如果是調(diào)用10000次接口完成這樣的發(fā)送，cpu肯定會上漲，如果同時給成百上千的用戶這樣發(fā)送的話cpu消耗應(yīng)該會非常可觀。如果是調(diào)用1次接口，將10000條消息打包一次性發(fā)送cpu會節(jié)省很多。

帶寬消耗巨大，10000條消息，假設(shè)每個消息大小200字節(jié)，給一個用戶發(fā)送消息需要大概10000*200*8=15Mb/s的帶寬才能實現(xiàn)秒發(fā)。如果需要同一時間給100個用戶發(fā)送，需要1.5G的帶寬才能實現(xiàn)秒發(fā)。一個idc機房出口帶寬也就幾十G，你算下你要花多少錢買帶寬。

最終建議：
如果是要實現(xiàn)用戶上線拉取離線消息，直接一個ajax請求到數(shù)據(jù)庫里拉最后10條消息即可，如果用戶想看更多，下拉消息框ajax繼續(xù)加載上一個10條消息。這樣基本上所有代價最小，性能最好，穩(wěn)定性更好，用戶體驗更高。