一种互动的体验.PDFVIP

一种互动的体验 ♦️ 高稳定性 －长链接一定要稳定，不能聊着聊着断开了 ♦️ 高可用 －一台机器挂了，我还可以连另一台 ♦️ 低延迟 －一个人发的一句话，另一个人立马收到 ♦️ Comet －维持客户端长链接、心跳. ♦️ Logic －逻辑处理，如账号验证、业务判断 ♦️ Router －在线信息(session)存储 ♦️ Job －消息分发 ♦️ Kafka – 第三方服务 －队列服务 ♦️ 一个消息一定只有一块内存 －Job聚合消息，Comet指针引用 ♦️ 一个用户的内存尽量放到栈上 －内存创建是放在对应的用户Goroutine里的 ♦️ 内存是自己控制的 －查看模块各个分配内存的地方，使用内存池 ♦️ 消息分发一定是并行的互不干扰的 －Job与每个Comet链接都是独立的Goroutine ♦️ 并发数一定是可控的 －每个需要异步处理开启的Goroutine都是预先创建好固定个数 ♦️ 全局锁一定是被打散的 －Socket链接池管理、用户在线数据管理都是多把锁 CPU 内存 数量 E5-2630 DDR3 32GB 2 * 不同UID同房间在线人数：500,000(每台250,000) * 持续推送数量：50条/秒 * 推送到达: 2,440万/秒 * 推送内容: {“test”:1} * 推送类型: 单房间推送 * 资源使用: 1400%~2340% （刚满） * 内存使用: 4.22 GB * 流量: 3.19 Gbit/s CPU 内存 数量 E5-2630 DDR3 32GB 1 * 不同UID同房间在线人数：1,000,000 * 持续推送数量：40条/秒 * 推送到达: 3,590万/秒 * 推送内容: {“test”:1} * 推送类型: 单房间推送 * 资源使用: 2000%~2300% （刚满） * 内存使用: 14 GB * 流量: 4.39 Gbit/s ♦️ 早期部署结构 －单线IDC流量不足 －单点问题 －接入率低 ♦️ 现在部署结构 ♦️ 即将部署结构，如下图: ♦️ 模拟Client监控每秒消息到达 ♦️ 线上开启Pprof,随时可以抓图分析进程状况 ♦️ 白名单功能: 指定人打印服务端日志 ♦️ 服务器负载监控，短信报警 ♦️ 不断的优化、调节用户最优接入节点 ♦️ IDC的服务质量监控：掉线率 ♦️ 自动切走”失联”服务器 ♦️ 消息的100%到达：丢包率 ♦️ 流量控制