做一个小说网站， 预计后期日活（ UV） 30W， V 友来讨论下如何架构比较好？

[wwolf]

R.T.

[ericls]

我觉得系统的瓶颈在于搜索引 和 更新浏览量

如果你需要统计最近 24 小时浏览量什么的 可以用 influxdb

考虑横向扩展可以采用 jwt 的授权方式

其他的还真想不到什么瓶颈

[wolfan]

突然发现在大种花家同样是敲键盘的，码字的和码字母的人收入差距真的是很大吖。
果然还是学好 English 搞海外媒社才是码字反超码字母的正确方式吖。

[fhefh]

先 mark~~~

[boter]

建议做好跑路准备 ：）
版权越来越严格
搞电影的进去了好多人吧
做小说的也快了

[realpg]

充分结合 CDN ，静态 /半静态，一组服务器可以搞定。
而且我用的 LNMP+memcached ……那时候 redis 还没现在这么热

[wwolf]

@realpg 目前我们想法一致

[realpg]

@wwolf
我当年那个项目比你预期的日活和 PV 都要高
当时架构可以给你参考一下 当时是放在自己机房

LNMP 中 受限于 TCP 连接数、 TCP 连接开销，前面是四台 AMD 入门 PC 跑 nginx 反代后面的真实 webserver ，实际上直接用 webserver 顶在前面是没问题的，主要是总遇到采集器啥的，产生大量 time_wait 等 tcp 状态堵塞，所以前面我直接二手东组装了 4 台最便宜的 AMD CPU 的机器用来跑 nginx

真实 webserver 两台双路 X5650 ，并不是单机不够跑，本质是想要一主一备防止服务器故障，既然开着同时有程序部署，就变成两个都在用了
数据库服务器 32G 内存的 X5650 一台，分配 2GB RAM 给 memcached ，剩余充分优化的跑 MYSQL 。另有大量单位淘汰的七八年+机龄的破 PC 包含赛扬 1.7G 啥的统统丢到一个池子里跑全文搜索集群

全站没生成静态（个人习惯特别不喜欢手动处理 html 文件），前面顶了带缓存的全站 cdn ，书内容页和目录页采用一个 url 只用一次不可编辑的模式，一旦出现编辑就作废原页面，这样全站内容类的压力都打在 CDN 上。我玩这个的时候， CDN 还比较落后，还没有现在满地跑的阿里云啥的，那些传统 CDN 服务商都不给太大缓存空间，隔三差五是要回源的，一个采集器扫过来瞬间爆豆的回源连接，这也是为啥前面顶着 CDN 我还用四个入口机分流的原因

全站平时跑起来一天近千万 PV （包含被采集）都没啥压力，最大的压力还是在用户系统评论系统上，这些高实时的东西我都是不经过 CDN 直接去刷服务器的

其实最大的好处，还是当时并没有泛滥的 DDOS 攻击，自己好好的维护站，只要能匹配设计容量就足够了

[zachlhb]

楼主哪来的自信？

[youxiachai]

厉害.....国内的正版网文..应该被起点和纵横垄断了吧...还能有新人进场?

佩服

[chocotan]

> 小说站一般都有自己的用户体系，支付体系再加评论回复，点赞

很多小说站都没有你说的这些

[frittle]

@youxiachai 「现在已经确定， 30W uv 是最少的了，按 2W 本书算」一开始就预计 2W 本，你觉得能是原创么？不是盗版就是授权，真的有原创网站愿意授权转载吗？

[jiar]

一看这界面风格就知道是 bootstrap 。。。检查一看果然如此。个人感觉这个界面比较适合后台管理。

[firefox12]

做这样的网站 是不是就是用爬虫 把别人的书 爬过来，整理好 放上去？ 这个不怕别人一把爬掉吗？ 这样的网站看的人多吗？ 30w uv ？ 那至少几万 ip 访问了