jamblues

@ichubei 1w pv 5 块算低的了，我了解的 10 块-30 块都正常

@cdlixucd 解决方案就是多个小文件合成大文件 降维 减少 I/O 开销，推荐可以试试 pika 或者 ssdb，优势是支撑几 kw 问题不大 内置分布式 也不用自己维护同步 弱点是性能只有在 ssd 下才能体现 如果要求不高 普通硬盘也可以试试

@kisshere 文件多了都会在 I/O 上有瓶颈 无论是 rsync 还是 lsync 底层是绕不过的

机器之间同步太耗时耗力了，而且如果是异地机房同步的话尽早放弃吧。

比较节约成本和省事的办法：

1. 将源图存 qiniu 或者 oss 三方存储上
2. 部署 5 台 CDN，使用 nginx 反向代理至图源，并本地缓存
3. 用 nginx 缓存管理，设置热数据存储大小就行了

这方案扛千万或者亿级数据问题不大，更大的话提供不了参考。

相信我，inotify 文件多了，每次机器重启或者服务重启 I/O 会卡到你怀疑人生。

目前比较实用的方案就是用 K/V 方案存 leveldb 类似的产品（如 ssdb 或 pika ）做集群。

29 岁 80w
30 岁 120w
31 岁 300w

机遇和处境在 30 岁上下会有大变化
如果你懂得抓住机会的

@veike
你好：
1. 权重问题，用 article/id-page.html 影响的是 /article/ 目录的权重，如果你想 /article/ 有好的排名，你就必须得走 /article/id-page.html 的文件形式让文件输出权重给目录。而且，对于长尾词，html 后缀权重更高。P.S. 当然，我举的例子只是方便让大家理解，并不代表就是实际是这么应用的。
2. 层次问题，全走 / 或者全走某个 - 或者 _ 之类的分隔符，意味着你站点的层次不够清晰，SEO 并非空穴来风，层次清晰的数据才是他们判断优质网站的标准。P.S. 我没说层次不清晰搜索引擎就不会有好的排名了，只是需要的时间更久而已。
3. 收录问题，目录层级越深，收录所耗的时间越长，但是单纯的追求浅层次的 URL，代表站点内容单一，久了也不一定会有好的排名。

在路由这个简单的问题上，我对度娘实战的经验、思考和理解不止于此，介于篇幅，先做以上通用的解释吧。

@kisshere
为什么要怕？大家愿意把我当笑话看，我十分荣幸。技术怎么解决路由重要，我也知道有一万种方式去解决。但包括你在内，大部分人都认为这两个 URL 在 SEO 里没区别。我不想过多解释，也就笑笑，我想这也是为什么很多大牛不愿出来交流的最终原因。

感谢楼上各位的建议，受小弟一拜~

只是，大哥们个个都用 2019 年来说事~

小弟我想说，既然都承认 2019 年了，为什么一定要去断定某件事情对与错呢？

SEO 没有实战结果的大哥，可以说你的见解，讲你的故事，但是评价甚至抨击他人的对错是不是过头了点哈？

我花了 2 年时间，一点一滴的思考，如何做好每一个环节。

目前凭个人能力养活了：月活 2 千万 UV，3 亿 PV 的站群，如果这算是错误的话，我愿意一直错下去~

当然，这也只是互联网的一角罢了，比小弟搞 SEO 的大牛多了去，只是不愿意露面罢了，

大家没必要自己做不好 SEO 去就去 BALA：

别玩啦，整不好的。

这技术 2019 年没用啦。

等等

只是因为你没有花心思，没有在这领域里细心钻研，仅此而已。

最后，我还是那句话，只是简单吐个槽：

框架有时候并非万能，也不一定就是你想要的。

谢谢各位，见笑了。