- 一：即使通讯系统架构设计详解
- 1.1 即使通讯系统功能需求分析
- 1.2 三层架构设计
- 1.3 网关层设计
- 1.4 业务逻辑层设计
- 1.4 数据访问层设计
- 二：纯异步高性能开发框架深度剖析
- 2.1 线程模型
- 2.2 请求处理流程
- 2.3超时处理
- 三：电商即使通讯系统设计实践
- 3.1: im系统问题
- 3.2 存储优化
- 业务流程化
- 上线方案
- 业务优化
1）用户点到点的消息通讯
2）用户在线状态区分
3）联系人/好友列表
4）离线消息存储
1）接入网关
2）业务逻辑
3）数据访问层
4）自研异步通讯框架
5）数据传输协议Protobuffer
1）提供tcp长连接接入方式
2）维护uid与连接句柄映射关系
3）超时管理
4）数据加密传输
5）对外端口80&443
问题思考？？？
enty数据不同步，用户分别在两个entry上登录如何处理？
enty发现连接，除了断开连接还需要做什么？
这两个问题都是在业务逻辑层解决的
1）登录，退出
身份检验
记录登录状态
2）消息发送
路由信息
保证消息触达机制
- ack确认机制（客户端重发）
- 不可达协议
3）拉取离线消息
登录自动分页循环拉取
缺点：启动慢、费流量、人工清理
4）系统消息
4.1）发送效率
push：服务器压力大、不在线用户处理困难
pull：逻辑简单，登录触发、流量摊平
4.2）存储效率
消息内容：浪费存储资源
消息id
4.3）拉取系统消息流程
router设计风格
1）双向同步互为主备
2）启动时从对方拉取数据
3）超时扫描
4）提供接口
4.1）用户登录
4.2）用户登出
4.3）设置用户信息
4.4）查询用户信息
DAS风格
1）数据库表设计
离线消息表
在线消息表
联系人表
2）抽象访问接口设计
请求组包/解包
配置文件设计
请求与规则配对
生成sql执行
1）上游请求onrequest
2）下游回包onpacketreceived
1）编写handler
2）定义上下文
3）设计状态机
4）注册habder
1）onrequest：创建上下文
2）向下游发起调用
组装查询请求
设置上下文状态
3）收到下游回包
找到上下文
回调onpacketreceived
4）endprocess：请求处理完成
1）扫描线程
2）超时sid放队列
3）工作线程消费
1）设计面向pc时代
离线消息
不支持历史消息拉取
2）route 设计过重
运维复杂
3）没有开放api
im新架构设计
1）取消router模块
2）logic只处理核心业务逻辑
3）extlogic出来非核心业务逻辑
4）提供spi入口服务imui
- 取消离线消息表
- 用户状态redis存储
1）登录
2）发消息
3）ack
1）存储复用
2）搭建新业务集群
3）tgw改变指向
4）mq双写
1）离线消息拉取
在线消息表拉取
性能问题
2）未读消息控制
3）未读消息计数
3.1) 前端记录
3.2) 后端统计: 拉取/清零
