作者回复: 👍
作者回复: 1. 接入层和业务层可以通过rpc或者mq来进行对接。
2. 推送时,可以在用户上线时维护一个全局的uid到接入网关的映射来做到定向推送,对于超大群或者直播互动场景可以不区分某一个用户落在哪个接入网关,而是让所有网关获取后来下推连到本机的用户。你想想这种方式的优势是什么呢?
作者回复: 问题1接入层避免业务也可以考虑使用统一协议的header,body部分直接透传二进制,或者把body的编码分委托给其他的编解码api。另外对于pb还不够紧凑的问题可以再gzip一下后再下推客户端。
问题2一般先落db,然后写离线buffer。db全量,buffer定长或者按时间过期。redis和pika一般比较适合做离线buffer,mysql和hbase一般由于消息的db存储。
作者回复: 嗯,也要考虑监管方面的需求,多端同步方案合理的话不会导致冲突。
作者回复: 是的,服务端可以只是维护一个用于暂存消息和信令的离线buffer,至于存多久和产品需求以及监管需求相关。
作者回复: 是个好问题,如果消息只存储在客户端,实现多终端消息同步基本上就会非常困难。
作者回复: 对,是指网关层服务。
作者回复: 如果m n x都需要接收同样的消息,可以让接入服务器通过消息队列来订阅业务层产生的所有消息就可以啦,就不需要业务层找机器了。
作者回复: 对,你说的这种方式其实是通过队列来异步化解耦消息存储逻辑。
作者回复: 期中左右会有一个简单版的IM的代码实现,架构图的我尽量去细化的讲,大家有问题的也可以随时给我留言提问。
作者回复: 服务端存储需要更多考虑成本和数据安全,也和产品定位有关,比如不需要支持消息多终端同步的应用,可以不在服务端进行存储。当然,还需要考虑国内监管机制是否允许的问题。
作者回复: 服务端存储需要更多考虑成本和数据安全,也和产品定位有关,比如不需要支持消息多终端同步的应用,可以不在服务端进行存储。当然,还需要考虑国内监管机制是否允许的问题。
作者回复: 这里接入服务逻辑和业务逻辑分开只是让接入服务不涉及业务细节,但业务本身的执行还是需要依赖接入服务来完成和客户端的交互。
作者回复: 感谢支持