京东的刘奇.pptVIP

GOLANG在京东的应用 刘奇 @goroutine ECUG Con 2013 Copyright of JD.com 概况 Golang开发的项目 实现技术与经验 正在进行的工作 Golang开发的项目 京东云消息推送系统(团队人数:4) 单机并发tcp连接数峰值118w 内存占用23G(Res) Load 0.7左右 心跳包 4k/s gc时间2-3.x s Golang开发的项目 云存储(团队人数12) 小文件存储 块存储 通用存储(大部分兼容s3) 除存储引擎用c/c++，sdk用java，其它均用go实现 兄弟团队开发的项目：自动部署系统 …… 快乐与痛苦同在 happy 简洁，开发速度快 并发实现方便，基础库完善 pains GC 还是GC 消息推送整体架构 关于消息队列 Redis + lua实现(高可用：vip + replication) 那么多现成的，为什么重复造轮子？ 简单，轻量，高性能，持久化，有问题也hold得住 Rabbitmq: 不懂erlang，整个东西搞得太复杂 Kafka activemq：不会java，另外过于复杂 关于消息队列 Crash safe Worker取到消息后crash，消息会超时重发，不会丢失 Worker从队列中pull消息，若队列不空，则持续取消息，否则sleep 1/20秒(可以结合redis的pub/sub机制实现实时消息通知，暂未实现) 多个worker 消息队列的逻辑由lua维护 数据库选型 个人觉得基本什么数据库(拆分)都能搞定，无明显喜好 Mongodb：正在使用，异步写入，sharding + replication 公司有高手，无需自己操心，省心 Mysql：个人偏好 Couchbase：兴趣较大，迁移做得不错，目前国内商用不多，暂不冒险 中途硬盘坏过两次，有raid，直接热插拔更换，对服务没任何影响 Session信息存储 分布式cache, redis 自己在sdk中做sharding? 麻烦 Twemproxy: 一致性hash, redis主从 + vip 部署方式：和应用部署在一起，应用连接localhost的twemproxy 消息路由算法 由于移动网络不稳定，客户端可能短时间出现在多个server上，仅仅通过客户端id无法区分 引入session id，自增，由各个server分配 Session存储格式Clientid:addr:server1:id:100, addr:server2:id:123 同时将消息路由到server1和server2 优化的基本原则 优化方案不会显著提高维护成本 有良好的兼容性，严格遵守golang的规范，以便更好的利用新版本的改进 先优化明显的热点 优化方案在其它语言也有效(内存池，连接池) 一些经验 Object pool (gc performance) Group commit JSON encoding/decoding (gc performance) 标准库优化(network, gc performance) Defer是性能和gc杀手 Dump信息获取 Object pool (gc performance) 一个数组实现的栈 代码示例： 关于json 标准库的实现性能比较挫，由于使用了反射，还有defer，profiling时轻松上榜 代码片段和热点图 Json unmarshal热点图 关于json 解决方案：magajson /benbjohnson/megajson Code generation, No reflection, no defer 标准库优化 网络库中读写数据都需要lock，unlock是在defer中完成的，在长连接的程序中，大部分时间是idle的，造成defer分配的内存长时间驻留内存，使得内存压力较大，也增加了gc的压力 看个热点图(有图有真相) 网络库热点图 标准库优化(network) 解决方案： 去defer unlock，改为手动在合适的地方unlock Group commit IO通常较慢，压力测试下消息队列的速度是瓶颈，通过golang的buffered channel，合并作为一个大消息提交 通过buffered channel合并消息给客户端，减少网卡中断次数 其它 errors.New 优化 time存储 socket close, runtime.SetFinalizer Group commit 代码示例： Dump信息获取 Bug不可避免，Crash不可避免 Golang程序crash时会打出调用栈，硬编码了写入的fd(2)，需要重定向到自定义的文件存储 syscall.Dup2(int(crashFile.