如何架设一个高性能和智能更新的小说站点？（无聊听—www.wuliaoting.com）

很早之前，就想做一个属于自己的小说站，因为自己非常喜欢看小说，恰好又是程序员，为何不自己搞一个小说站呢，这个念头一直存在脑海里，但就是一直没有动手。

看着身边有朋友在小说站点捞金，羡慕不已，也后悔不已（没早点架设起来运营），现在终于下定决心开始要建一个小说站，于是着手分析了一些小说站点。

碰到的问题：

1 ）数据量大：自己以前运营过其他站点，都是普通 CMS 就能搞定的，但是这个小说站点数据不是一般的庞大，一部长篇小说就有几千章节，几万本小说那的几千万篇数据，万万没想到数据量这么庞大，日后的数据递增也会越来越多，想想自己近几年来开发的项目都没这么大数据量，这得对系统的性能要求肯定很高啊。普通的 CMS 根本跑步起来。

2 ）数据量大意味着对数据库查询要求就要非常高，表怎么查询这么大的数据呢？

3 ）还有就是小说篇幅要实时更新，怎么才能更智能和准确呢？

4 ）用户如何搜索自己想要的内容呢？

下面看看是怎么解决以上四个问题的吧

解决 1 ）如果小说章节的数据全部存一张表，那会导致单个表文件大小非常大，单位以 G 来计算，系统 IO 肯定吃不消，不可取，这得从 mysql 分表或者分区来下手，分表顾名思义就是把文章内容表划分多张表，比如 article_1,article_2,article_3，以此类推，每张表有规律的存储 ID，程序在对应去处理计算，得到相应的具体表位置，还有一种简单的方法就是分区，mysql 底层已经为我们做好了表的分区划分，只要我们对应的设置每张表的数据值范围就 OK，比如按时间来分，一周、一月的数据一张表，或者根据 ID 范围来划分，第一章表 50WID，第二章表从 50W 到 100W 的 ID 数据，分表或分区大大提供 mysql 存储的性能。（具体 mysql 分区自行百度）

解决 2 ） SQL 查询，提供三个思路，第一减少 sql 查询的次数，可以借助 memcache 或者 redis 存储已读取的数据，下次直接读取，不用在请求数据库，第二不要模糊查询，比如 like '%aa%',这会导致数据库直接卡死，第三，要在小说数据表的关键字段加上联合索引，比如 cid stauts sort,这个非常关键，加联合索引和不加那根本是不能比的，效率大大提高。

解决 3 ）小说的数据量是相当庞大的，单个人工是没办法编辑和更新的，前期可以借助采集器采集，找好目标站，等数据填充过后，我们就要提供脚本去实时抓取了，做好一些设置判断，如果已存在的数据就不要替换了，只做新的内容添加。

解决 4 ）看了很多小说站，都没有搜索功能，这也是跟站长们的技术水平有很大关系，这么大的数据量肯定不能直接模糊查询，为大家推荐一下好用的组件，xunsearch （迅搜），PHP 可接入使用，具体使用到官方去查了哦。

总的来说，你可以选择自己熟悉的 CMS，然后在基础之上二次开发，优化程序体搜索，优化数据库，使用缓存和其他的组件配合使用，效果一定会不错的。

附上我的站点无聊听 http://www.wuliaoting.com ，如果有技术上什么问题可以回复我。

SquirrelMAN

2019-07-25 20:16:11 +08:00

新京报报道，北京公安局网安总队会同通州公安分局破获一起非法获取计算机信息系统数据案，抓获犯罪嫌疑人 10 名，查获涉案计算机、手机等设备 26 部，关停相关网站 8 个，涉案金额达 400 余万元。在公安部组织开展的净网 2019 专项行动中，飞卢小说网的相关人员报案，称其文学网站多个会员账户被盗用。网站上部分独家授权的付费小说被 “克隆” 在其他网站上，供人免费阅读，给公司造成经济损失。报道称，一名犯罪嫌疑人称利用黑客技术获取了多个正版网站的大量会员账户信息出售给其他人，但会员信息如何被盗没有给出详细解释，只是笼统的以“黑客”之名冠之，是网站漏洞还是其他问题，目前并不清楚。