1.Golang在百万亿搜索引擎中的应⽤用 Poseidon 郭军@360 

2. ⾃自我介绍 • 360核⼼心安全事业部 云引擎开发组技术团队 • guojun-s@360.cn • https://github.com/guojun1992 

3. ⽬目录 • 设计⽬目标 • Go应⽤用场景与遭遇的挑战 • 怎样应对？ • 开源的改变 • 总结 

4. 设计⽬目标 • 总数据量量：保留留3年年历史数据，百万亿条、⼤大⼩小100PB • 秒级交互式搜索响应 • 每天⽀支持2000亿增量量数据灌⼊入 • 原始数据仅存⼀一份 • 对现有的MR任务⽆无侵略略 • ⾃自定义分词策略略 • 故障转移，节点负载均衡，⾃自动恢复 • ⽀支持单/多天批量量查询，批量量下载 

5.

6.架构设计 

7.⽤用ProtoBuffer描述核⼼心数据结构 

8. 弥补倒排索引的缺陷—四级索引 • 关键字 -> DocidList Docid -> Doc • “计算机科学领域的任何问题都可以通过增加⼀一个间接的中 间层来解决” 

9. idgenerator • docid：每天27700亿 ，4字节，总计11TB • 采⽤用分段区间获取降低qps，每天的id重新从0开始分配 • key：业务名+时间 

10.Proxy/Searcher详细设计 

11. Searcher并发模型 • 每天25000亿 docid • 采⽤用分段区间获取降低qps，每天的id重新从0开始分配 • key：业务名+时间 

12. 问题与瓶颈 • 基础组件是c++，c++ -> c -> CGO -> Go • gdb调试 进程过多 

13. 解决⽅方案 • ⽤用Go重新实现⼀一遍 • 将组件作为http服务，Go Client调⽤用，做集中式处理理 

14. 问题与瓶颈 • ⼤大量量使⽤用goroutine，⼦子协程panic在主协程不不能被 recover，如何统⼀一处理理 ？ 

15. 解决⽅方案 • 通道类型为struct，封装正常数据和error，在主协程从通 道取出数据，统⼀一做处理理 

16. 经验⼩小结 • 即使精通多种语⾔言，最好不不要混⽤用，谨慎引⼊入其他语⾔言的 解决⽅方案 • 不不要完全相信recover，它不不能恢复runtime的⼀一些panic 

17.Proxy多天并发查询设计 

18. Proxy多天并发Build Cache设计 • 即使精通多种语⾔言，最好不不要混⽤用，谨慎引⼊入其他语⾔言的解 决⽅方案 • 不不要完全相信recover，它不不能恢复runtime的⼀一些panic 

19. 索引数据变“冷” • 同⼀一份数据在缓存时间内不不会⾛走整个readhdfs流程 • build index 程序挂了了会报警感知，但是数据错误却是未知 • 修复数据重建索引需要时间 

20. 解决⽅方案 • 减少缓存时间，在可容忍错误数据的时间内，⽤用户查询及时 发现问题 • 参考NSQ，利利⽤用for+select的不不确定性来分流，随机流量量到 cache和hdfs做热测试，缺点：开发成本较⾼高 

21. 经验⼩小结 • 选择简单、有效、够⽤用的解决⽅方案 • 利利⽤用goroutine设计并发程序很⽅方便便，但是程序的并发运⾏行行 模型要hold住 

22.Proxy多天异步下载 

23. ReadHDFS雪崩效应 • goroutine太多，底层readhdfs挂掉 

24.ReadHDFS雪崩效应 

25. 解决⽅方案 • 连接池 • 熔断机制—超过连接数，直接返回error 

26. 升级⾄至1.7 GC变化 • GC在我们的系统中本不不是瓶颈，仅仅是交流升级测试结果 

27. nginx代理理问题 • 前端要不不要加nginx代理理？ 

28. 访问控制和负载均衡 • 我们⽤用nginx解决了了访问权限问题，⽆无需再在go程序做开发 • 利利⽤用upstream 做简单负载均衡 

29. 开源 • https://github.com/Qihoo360/poseidon • Godep+vendor机制解决第三⽅方依赖