Go语言高并发实战：构建千万级在线的实时消息推送服务讲述.ppt

四、系统架构及实现细节 摘要 逻辑架构：简单至上 组件：room 组件：register 组件：saver 组件：idgenerator 组件：center 存储：redis 1. 逻辑架构：简单至上 2. 组件：room 客户端所连接的进程，类似于一个聊天室 每个客户端一个 server goroutine 进行下推 每个 server 有一个 channel 存消息队列 room 内有 book 记录 user 与 server 映射 一个 http server 负责收消息并将消息路由到接收人所在的 room 和 server manager 负责掌控 room 的服务：内部单播、多播、广播 admin 负责 room 进程的管理 3. 组件：register 由于 room 的分布式与全对称设计，需要有一个地方记录用户当前连到了哪个 room，register 实现该角色 同时需要记录在线时长等信息 (业务需求) 本质上就是一个 key - value 的 map value 是个 struct hash 算法定位 register 进程 可以直接用 redis，但自己实现可以方便地添加业务逻辑 4. 组件：saver 分布式全对称设计 提供存储接口，封装后端的分布式存储 接口采用 encoding/gob 编码格式的 rpc 5. 组件：idgenerator 全局消息 id 生成器，int64 分布式，每个进程负责一块 id 区域 保证不重叠 后台 goroutine 每隔一秒写一次磁盘，记录当前 id 启动时跳过一段 id，防止一秒内未写入磁盘的 id 重复生成 6. 组件：center 提供消息操纵接口给应用服务器调用 运营人员后台发消息 - 应用服务器 - center - room - 客户端 RESTful API 有些任务（比如广播）需要一段时间，运营人员需要追踪发送进度，可能要临时停止，因此需要有“任务”概念，并可管理 提供统计接口 7. 存储：redis 核心数据 db_users：ZSET，存各产品的用户集合 db_slots：LIST，存用户离线消息队列 db_buckets：DICT，存消息 id - 消息体 五、数据、经验和教训 数据 16台机器，标配24个硬件线程，64GB内存 Linux Kernel 2.6.32 x86_64 单机80万并发连接，load 0.2~0.4，CPU 总使用率 7%~10%，内存占用20GB (res) 目前接入的产品约1280万在线用户 2分钟一次GC，停顿2秒 (1.0.3 的 GC 不给力，直接升级到 tip，再次吃螃蟹) 15亿个心跳包/天，占大多数 持续运行一个月无异常，稳定 经验 敢于尝试新东西，勇于面对新挑战 拿代码说话，拿数据说话 不要凭感觉，要实际去测 对一项新技术要切实了解其优势和劣势 对于感觉模糊的地方，追查其实现，做到有备无患 教训 实时系统对 GC 非常敏感，幸好 tip 上提供了并行 GC，否则这就是一次惨痛教训，需要做架构方面的大调整 (将大进程拆分成小进程) Q A Thanks! 张景埕 diogin@ /diogin Go 语言高并发实战 构建千万级在线的实时消息推送服务 2012.12.12 关于我 张景埕，网名 diogin（/’da??dr?n/） programmer@360 Go 语言追随者与实践者 新浪微博：/diogin diogin@ 摘要 一、为什么选用 Go 二、探究 Go 语言的实现细节 三、实时消息推送服务的特点 四、系统架构及组件细节 五、数据、经验和教训 一、为什么选用 Go 1. 高并发 一个 Go 进程可以轻易支撑几十万上百万并发运行的 Go 例程（只要你内存足够大） O(1) 的调度 5KiB/goroutine 的内存开销 net 包：pollServer (epoll/kqueue/iocp) 支持大量并发连接 fd 的事件通知，同时还支持多核并行 (目前为 8 核) select/channel 提供卓越的例程间通信能力 2. 高性能 编译为本地机器码 静态链接 (CGO_ENABLED=0) 轻量级的 runtime 实现 热点代码可以直接编写 C 或 ASM，同样静态链接进目标文件 3. 垃圾收集 不想为内存泄露问题焦头烂额 朴素的实现：停顿式、标记 清除 还有很大的提升空间 资源泄露还得自己解决 4. 低成本 学习成本低：源自 C 系，大量的 C 系程序员可以很快上手（这很重要） 运维成本低：不需要安装各种让人头疼的依赖，不需要搭建各种运行环境，部署非常方便 5. 够用的标准库 net encoding/gob strings, bytes, errors, strco