如何架设一个高性能和智能更新的小说站点？（无聊听—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 ，如果有技术上什么问题可以回复我。