抖音上评论后如果有人点赞我的评论，会马上收到气泡提醒，这是什么原理实现的？

这帖子的评论，让我惊讶 v2 居然有这么多半吊子研发！

@paullee 请说出你的见解

消息推送极光之类的服务
最简单的就是 app 几秒轮询啊
这有啥疑问的????

原来 V2EX 上的平均水平那么低吗。。。
一般采用长连接或者轮询，选择哪种看频率。
值得讨论的，也就是选择自己建立长连接，还是直接使用系统或者 SDK 提供的长连接

这个帖子暴露了很多人的基础短板，还 tm 只知道 cv996 吗

这种程序一定有一个 tcp 或者 udp 的长连接，这个连接里面会做很多不能描述的事情，所以推送就会放到这个里面，所以方案上一定不会用 websocket 这种要做死的方式。但是如果用了，我只能说这个方案的人比较二。

长连接资源开销大？？？？
黑人问号

难道你以为的刷死服务器的轮询就不大？

看了这个贴子我学到了我用 tcp 做实时推送是消耗很大傻逼行为,我绝定改成 udp 疯狂发包

websocket 会消耗连接数的，每台机器的连接数是有上限的

正在用 socketcluster （ typescript ）写一个包含聊天、系统通知功能的应用，客户端有 web、ios、android，前期单台服务器，后期量起来了可以上 k8s 自动扩容，应用内走 websocket 应用外走 ios、第三方推送（ android ）。

websocket 消耗大？
以前对单台服务器有个 c10k 挑战，现在都上升到 c1000k 了，各语言性能测试传送门： https://colobu.com/2015/05/22/implement-C1000K-servers-by-spray-netty-undertow-and-node-js/

可以 http 轮训。也可以 tcp 直接实时通知

插眼等正确答案

看来搞 IM 的不多，这东西就是 tcp 或者 udp，有的 app 狠起来会开好几个长连接，更狠的还会做 android 的提权保活，进程杀掉了后台照样悄悄的跑。
大概的流程就是跟聊天一样，有人点了个赞，系统走推送渠道推给你了，走 app 自己的长连接，还是走华为小米厂商的 push 通道，看厂商高兴。
即时通讯类的社交产品，一般分两块，通讯和视频。即时通讯为了省流量，省资源，大厂都是私有协议。视频直播类的就是 rtmp+hls。其他的任何内容都属于消息协议扩展。起泡怎么冒，礼物怎么显示，商品红包什么的，业务按照 im 的协议扩展

就是推送

[建议] 那些 [反对长连接] 的朋友和 [赞成长连接] 的朋友，互相加入黑名单。

手机会保持向服务器询问是否需要同步数据，但是这个询问代价很小。

@jm00 #96 要不要感受一下 5000 万请求轮询的压力？ 2333