Golang在百万亿搜索引擎中的应用

设计⽬标 • Go应⽤场景与遭遇的挑战 • 怎样应对? • 开源的改变 • 总结
展开查看详情

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机制解决第三⽅方依赖