作者回复: 👍
作者回复: 是个好问题。因为很多时候消息由tcp层交给应用层之后还可能出现丢失的情况,比如客户端落本地db失败了,类似这种。
作者回复: 一种做法是用户上线时维护一个全局的 uid->网关机 的映射,下发的时候就能做到精确定位;另一种方式是:下发时把所有消息下发给所有机器,每台机器如果发现当前用户连接在本机就下发,其他的就丢掉,这种会有一定的资源浪费。
作者回复: 进程kill是会对socket执行close操作的哈,所以客户端是能感知到的。真要是通过拔网线的方式把服务端网络断开,这种情况客户端在发送数据时就会失败,然后短连后重连其他服务器就可以了。
作者回复: 以前有大厂测试过国内各家运营商的NAT超时情况,有的运营商在2/3G网络下NAT超时是5分钟。
作者回复: 和http没关系哈,实现上比如接收到一个请求后,通过while循环判断,如果请求时间和当前时间的时间差没有到达超时阈值,就继续查询后端是否有新消息,直到超时或者查询到新消息。
作者回复: 连接数一般不是问题哈,服务端单机几百万上千万都可以的,受限于分配给每个连接的buffer占用的内存。业务层持久化会慢会导致客户端掉线这个没看懂呀,能具体一点吗?第三个问题可以做db的读写分离,第四个问题应该是说db的自动切主吧,这个是可以的哈,很成熟的方案。
作者回复: 国内的话最好不要超过5分钟,微信应该是4分半。
作者回复: 据我了解微信是私有二进制协议。
作者回复: 嗯,ack机制是确保消息被正确接收了,下节课会讲到哈
作者回复: 可以考虑推拉结合,离线消息太多如果全部都推的话性能和带宽上都不太友好,可以离线推送一页,后续的再由客户端来拉取。
作者回复: 👍
作者回复: websocket支持双向全双工的传输,所以可以做到服务端推送,让消息接收更加实时。
作者回复: 也是可以的哈,考虑到web端很多浏览器都原生支持websocket协议,实现上更简单,而且web端对于流量相对没有那么敏感,所以web端更多的可以考虑websocket。
作者回复: 嗯,连接服务唯一标识和connid可以整合一下。
作者回复: 可以看一下我课程中有介绍消息表的设计。
作者回复: 不具备读写操作仅仅只是维护静态连接的话基本上就是个拼内存的活,调整tcp单连接的读写缓冲区大小到4k,优化下其他系统参数比如句柄限制啥的,建连速度稍微慢点,有个200g内存是没问题的。这里其实想说的是,不要光看单机能维护多少连接,每秒收发包数这些才是关键。
作者回复: 没问题的~
作者回复: 那还是websocket更好一些,很多浏览器默认就支持了呀。。。
作者回复: 防止客户端的连接伪造是比较困难的哈,比如你的app源代码泄露了,稍微改一改就能仿冒APP连接上来。这种情况可以考虑采用人机验证(比如极验,比如手机验证码)来排除“机器行为”,更极端的可以采取网银的方式,通过客户端插入的U盾来提供真实访问的验证。