@xuanwu

只说技术上， 真的太乐观了：
1. 要不要搞容错（多副本）。 不搞容错，机器不坏的? 搞的话，是不是要搞分布式？
2. 一次大规模顺序 scan(用来建 cache ）一个机器能抗住么？ 多少个机器能抗住？
如果不做 cache，这种海量搜索，多少 s 可以回返？

这还只是存储要解决的非常非常非常非常小的零星问题。 楼主可以看看 bigtable。 然后在说可行性.

如果真的如楼主所言想索引全网 （支撑全网数据更新），成本非常非常大，几乎不可能。

只说其中一个小环节（存储）中的冰山一角：
a. 如果想索引亿级别的 pages，存储成本是天量的。这还没算需要进行 cache 缓存之类、热点处理之类的实时库更新
b. 技术上成本也非常大：
- 能找到成熟且良好支持 scan 操作的分布式开源项目么？ 能开发、维护、运维这个开源项目项目的 team 人力成本有多大？
- 海量存储最后怎么跟实际提供服务缓存存储对接？ 缓存怎么设计？
- pages 更新机制是怎么样的? 热点数据怎么存储？ 冷数据怎么存？数据备份怎么办？


另外，商业上想，为什么这个项目能存活？ Github 能运营是有内部商业逻辑的。如果没有内部的商业逻辑推动，这个开源项目怎么活下来呢？

@Buffer2Disk 二分法增加 log 试试。

这样缩小范围到具体是哪儿卡住了。 我调试多线程一般就是靠日志，哈哈。 一般玄学问题大部分都是代码逻辑问题。 真遇到编辑器或者库缺陷的，太少了，除非你直接操作了非常非常底层的东西