Golang在百万亿搜索引擎中的应用
展开查看详情
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机制解决第三⽅方依赖