“评论盖楼”的设计思路

这样的需求其实挺特殊，每一个“楼”都是一个独立的“树”，每一个“楼”都“几乎”不用依赖其余的“楼”。
最简单、最高效的方式是用文件来存 储每个楼，每一个新闻一个楼，使用xml、json等树形结构的文件格式来规范评论和新闻内容。这样每进一个楼只须要访问一个文件，发评论只是建立一个文 件，把楼盖高，只是给增长新内容。而新闻列表能够存储在数据库中，也能够用lucene作索引。

若是必定要用数据库实现，那么新闻（主贴）作一张表，评论（回贴）作一张表，评论表中添加新闻id字段做为与新闻表的外键关联便可。若是要进一步完善树形结构，评论表上补充一个指回评论表的外键便可。

 

若是性能很是重要，这个方式是颇有意义的，并且新闻列表必定是用lucene作索引。
新闻首页必定不是直接查询数据库，而是静态化该页面。在后台作一个轮训器，按期更新这个静态页，若是有重大新闻发生，强制更新该页面。
新闻内容、评价页静态化或者单文件处理，能极大下降服务器压力，毕竟没有数据库操做。天天一个目录，或者每小时一个目录，在文件存储方面就不会对文件系统造成较大压力。

 

二、
于数据压力，用数据库的话，能够分拆为每一年、每月再或者每周一个新闻库，只须要每次新增一个库便可。具体的处理方式就要看你用的数据库。
某些状况下，将当月、重点的新闻单独提炼出来静态页面项目，须要对当月、重点的新闻作大规模的负载均衡，对其余不重要新闻则使用普通的方式。

新闻内容若是静态化
优点：可使用apache甚至lighttpd、nginx服务器，对应的处理压力的能力较强。
方式：能够用新闻内容自己+新闻模版生成静态的新闻文件，在新闻文件上用ajax异步加载新闻的评论。
缺点：新闻页面上的其余因素成为开发起来比较麻烦的东西，好比广告、相关文章链

新闻内容若是不静态化
缺点：使用的服务器受到你的系统的架构的影响，处理压力的能力受限。
方式：能够将该新闻的内容、评论等相关因素放在一个xml里面，访问该新闻时仅仅读一个新闻xml，仅一次读IO，性能上不会有较大压力。前端能够再加一个集中式缓存(好比memcached),将读的次数很是多的新闻存在缓存中，进一步减小IO数。
有点：灵活。