目前各大网站实现消息推送主流的解决方案也就2种

1、轮询

2、WebSocket(楼主是C#可以考虑SignalR)

WebSocket最大的有点就是它可以使B/S应用做到即时通讯。例如微信网页版。

一般需要消息时效性很强的消息推送才会使用到。

但是像“XX回复我了”这种消息，对即时性要求并不高，并且像博客园这种一定会用到读写分离的大型网站，写服务器到读服务器的同步还有一定时间，所以用轮询足以。

好了，我扯了这么多，来用事实说话。

打开一个博客园的页面，然后F12，清空所有Network日志，然后去干别的...5分钟以后，泡面好了我们要的证据就出来了

看到我红框，圈出来的地方了么，看到2个回重复出现的GetUnRead****Count了么？看到他们的Initiator，Jquery，明显就是Ajax。好了，博客园的博问用的是轮询，这件事已经最后定论了。

现在来解答一下题主关于说的“轮询太消耗内存”的说法。的确轮询这种无脑的做法，回产生大量的冗余操作。那我们可以从几个方面来降低这种废操作带来的开销。

首先最基础的，刚才也说了，降低轮询频度，反正你的推送也不是即时性很强。

然后同浏览器多页面可以采取消息共享机制，如果我要打开博客园4个面，但是只有第一个会进行轮询，然后第一个页面回创建一个域共享的cookie。其他页面如果能发现这个cookie，则不进行像服务器轮询，而是定时检查cookie更新情况。第一个页面则将轮询结果写入这个共享的cookie。

最后，在服务器端，这种很大几率会被用户取走的数据，可以将其写入Redis（或者其他k-v型nosql数据库）来降低服务器对于DB服务器的读取压力。

当然，还有其他更高阶的分压方案，那就基本都是分布式的事了