评价系统设计篇

评论系统大家都见得非常多了，大到京东、淘宝、亚马逊，小到个人网站、博客都有评论系统，小型网站采用传统PHP+Mysql方式就能很快将系统搭建起来，同时采用单库单表方式就能轻松解决数据存储、数据查询等问题，但是对于上述中大型网站而言，已经远远不能支撑系统正常运行了。接下来将从系统架构、数据存储、高性能服务等方面来揭示京东的评价系统在面对海量数据、海量请求的情况是如何处理的。

 系统架构

 
   评论系统整体架构如下：

      京东的商品评论目前已达到数十亿条，而且每年还在成倍增涨，面对如此庞大的文本数据，存储的选择十分重要。从sqlserver的单库单表到mysql+nosql的存储方式，评论系统的稳定、数据的读写性能有了巨大的提升，同时更易于扩展，为今后的高可用服务打下了扎实基础。

Mongo、Hbase

      文本存储我们选择了nosql，一是减轻了mysql存储压力，释放msyql，庞大的存储也有了可靠的保障；二是nosql的高性能读写大大提升了系统的吞吐，这让我们偿到了甜头。过程中我们尝试过cassandra、mongodb等分布式的nosql存储，cassandra适用于写多读少的情况，而mongodb也是基于分布式文件存储的数据库，介于关系型数据库与非关系型数据库之间，同时也是内存级数据库，mongo写性能不及cassandra，但读写分离情况下读性能相当不错，因此从应用场景上我们选择了mongodb，而且一用就是好几年。mongodb确实不错，也支持了我们系统稳定运行了好几年，但从今后的数据增长、业务扩增、应用扩展等多方面考虑，最终还是选择了Hbase，它的存储能力、可靠性、可扩展性都是毋庸置疑的。

       文本存储解决了，但评论系统还要面对前台用户列表、评分切面统计、列表筛选、后台全字段检索等业务应用，仅通过hbase/mongo是难以解决的，为此我们引入了关系型数据库mysql、全文检索框架solr/Elasticsearc、流式计算框架Storm.

MYSQL      

        Mysql作为基础数据库，主要存储评价基础信息、扩展信息、图片及标签等数据，因此拆分方案可参考如下：评价基础数据按用户ID进行拆分，扩展信息数据量及访问并不大无需进行拆分，图片及标签根据商品编号进行拆分。因人而异、因地制宜，根据不同的数据场景选择不同的拆分方案，便能有效解决数据存储与查询问题。

        京东的评论是以用户和商品两个维度进行划分的，对于用户而言，用户需要发表评论、上传晒图、查看自己的评论等，因此只要根据userId进行拆库拆表便能解决用户数据写入、查询的问题；对于商品而言，前台需要将统计商品的评论数并将所有评价展示出来，后台需根据评论的全字段进行检索，同时还带模糊查询，而评价数据是按userId进行库表拆分的，现在要按商品去获取评论，显然当前的拆分库是无法实现的。起初考虑过根据商品编号再进行拆库拆表，但经过多层分析后发现行不通，因为再按商品编号进行拆分，得再多加一倍机器，硬件成本非常高，同时要保持用户及商品两维度的分库数据高度一致，不仅增加了系统维护成本及业务复杂度，同时也无法解决评论的数据统计、列表筛选、模糊查询等问题，面对前台如此巨大的流量压力，我们只能选择其它解决方案，为此引入了全文检索框架solr/Elasticsearch、高性能缓存redis。

全文检索框架+Redis