Transcript Go 语言高并发实战
Go 语言高并发实战 构建千万级在线的实时消息推送服务 2012.12.23 关于我 • • • • • 张景埕，网名 diogin（/’daɪədrɪn/） programmer@360 Go 语言追随者与实践者 新浪微博：http://weibo.com/diogin [email protected] 摘要 • • • • • 一、为什么选用 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, strconv regexp os, time syscall sync ...... 6. 高移植性 • 多种操作系统：Linux, FreeBSD, Darwin, NetBSD, OpenBSD, Windows • 多种体系结构：386, amd64, arm(v5,v6,v7) • 多种目标文件格式：elf/pe/macho 7. 优秀的背景 • Google, BSD License • Ken Thompson, Rob Pike, Robert Griesemer, Russ Cox, Brad Fitzpatrick... • 拥有强烈的 Plan 9 血统 • C, Python 的风格 Alternatives? • • • • Erlang Node.js D Rust 二、探究 Go 语言的实现细节 WHY? • • • • • • 产品级的应用，不是玩具 在国内（甚至国外），仍处于吃螃蟹阶段 我们需要能 hold 住可能出现的各种问题 提升团队成员技术水平 回击各种针对 Go 的恶意 FUD 和各种 PK 回馈 Go 本身，积极为其做贡献 摘要 • • • • • • 代码结构 逻辑结构 实现结构 程序启动 运行视角 深入 runtime 1. 代码结构 • • • • • • 工具 + 标准库 include/：Go 基本工具依赖的库的头文件 src/：Go 基本工具、标准库的实现 src/cmd/：Go 基本工具及其实现 src/lib*/：Go 基本工具依赖的库的实现 src/pkg/：Go 标准库的实现 2. 逻辑结构 • gc (Go 编译器)、cc (Plan 9 C 编译器)、as (Plan 9 汇编器)、ld (Plan 9 链接器)、pack (Plan 9 目标文件归档工具) 工具链一条龙 • 支持多种操作系统、体系结构和可执行文 件格式 • 程序 = N 个包的合并、组合 • 包 = const、var、type、func • dist：引导程序，负责构建 Go 基本工具 • go：管理 Go 的各项功能 3. 实现结构 • 每个包里可以有 .go、.c、.s 文件，分别由 gc、cc、as 编译，最后统一用 ld/pack 链 接并打包成静态链接库(遵循一致的 ABI) • 每个 Go 程序都包含最底层的 runtime 包， runtime 实现并封装了程序的运行时环境 • syscall 包封装了操作系统调用，同时与 runtime 协作进行 goroutine 调度 • sync 提供了基本的并发同步原语（工具包） • reflect 为应用层代码提供运行时自省能力 4. 程序启动 • • • • 基本概念：M—内核线程，G—goroutine Go 使用符号“·”分隔包与包内的成员名字 第一个 M 叫 m0，每个 M 的调度例程叫 g0 准备 runtime·m0/runtime·g0 -> 准备 argc, argv -> 调度器初始化(内存初始化 -> m 初 始化 -> 注册 args, envs -> 设置并行参数) -> 创建并运行 runtime·main 例程(启动垃圾 收集器 -> main·init() -> main·main()) 5. 运行视角 • 程序由多个包构成，入口为 main 包，每个 包在程序启动时按依赖顺序逐一初始化 • 程序内有多个 goroutine 并发运行， goroutine 通过 channel 进行同步/异步通信 • 自动化内存管理，不区分堆和栈 6. 深入 runtime • mgc0.c：垃圾收集器 • proc.c：goroutine 管 理及调度 • hashmap.c：Go map • chan.c：channel 实现 • malloc.goc：内存分配 器 • asm_GOARCH.s：体 系结构相关功能 • iface.c：Go interface • symtab.c：符号表 • cpuprof.c/mprof.goc： Profiling • sys_GOOS.s：操作系 统相关功能 • thread_GOOS：内核 线程统一抽象 • panic：panic管理 三、实时消息推送服务的特点 摘要 • • • • • • • • 长连接（多种接入协议：HTTP、TCP） 高并发（>= 10,000,000） 多种发送方式（支持单播、多播、广播） 持久/非持久 准实时（200ms ~ 2s） 客户端多样性（手机端、PC 端） 同一账号多客户端同时接入 接入网络频繁变化（电信、联通……） 1. 长连接 • • • • Server PUSH 的基础 HTTP Long Polling（Keep-Alive） 基于 TCP 的自定义通信协议 采用心跳来侦测对方是否还在线 2. 高并发 • C10K? out 了，现在的标准是 C1000K • 用户众多：各接入产品实时在线人数都在 10,000,000 以上 • Linux Kernel >= 2.6.32, x86-64 • sysctl -w fs.file-max=12000000 • sysctl -w fs.nr_open=11000000 • limit.conf: nofile=10000000 • TCP/IP 协议栈参数调优 3. 多种发送方式 • 点对点聊天（单播） • 定点推送（多播） • 全网推送（广播） 4. 持久/非持久 • 持久消息必须保证不丢失 (需要离线存储) • 非持久消息仅发给当前在线用户 5. 准实时 • 发一条消息，另一个人必须能很快收到 • 200ms ~ 2s • GC 卡顿会造成巨大麻烦 6. 客户端多样性 • 手机、PC、平板电脑 • 不同的产品有不同的需求 • 提供机制，而非策略 7. 同一账号多客户端接入 • • • • iMessage：iPhone, iPad, MacOSX QQ：PC、手机、平板、微信 互斥（早期 QQ）& 共存 策略：如何控制？ 8. 接入网络频繁变化 • 白天在电信，晚上在联通 • 一会儿在公司 wifi，一会儿 3G，一会儿 2G • 断线，重连，断线，重连…… 四、系统架构及实现细节 摘要 • • • • • • • 逻辑架构：简单至上 组件：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，否则这就是一次惨痛教训，需 要做架构方面的大调整 (将大进程拆分成小 进程) Thanks Q&A 张景埕 [email protected] http://weibo.com/diogin