2017 November 27 订单

评价系统设计

基础库Mysql，根据用户ID进行拆库拆表，只存储评价的基础信息，如用户、时间。其他的信息如图片，并不是所有的评价都有，会有单独的表存储，这样可以减少Mysql这种以行存储的空间，但是会放在同一个库中，方便检索。

文本存储开始主存储是MongoDB，用了几年，使用读写分离的方式，后面好像主存储切到了Hbase，MongoDB为备用的存储，rowkey为商品的ID，主要应对就是查看商品评价这一主要需求，没有使用cassandra主要原因是虽然些性能高，但读取性能不如Hbase。MongoDB的备用存储是在Hbase集群出现问题的时候，也能够把MongoDB当作存储，先写入MongoDB，等Hbase恢复后同步数据，在切回到Hbase上。

搜索服务前台是solr后台是ES，前台主要对评论星级进行统计，并且支持按照星级查看，比如查看5星好评的评论。先通过solr查询5星好评的评价ID，在根据ID去Hbase中查询评价的信息，然后给前台使用。后台的检索主要是模糊检索，使用ES。而且前台的solr根据文中表述后续会迁移到ES中。

缓存服务使用Redis，通过商品查看的主要是第一页的评论，和评论总数等缓存在Redis中。此外如果是秒杀类的，会提前放在本地的堆缓存中，减少堆Redis的压力。减少缓存使用内存的套路也差不多，减短key长度、去掉多余属性、压缩文本等方式节省内存空间。

高可用的设计，目前是机房的主从结构，直接盗图如下：

最主要问题就是更新只能在一个机房的主数据库上，更新有限制。后面作者意思要切到多服务中心，不同用户可以到不同的机房服务，当故障的时候进行故障转移，这里有些不确定的地方，虽然是多服务中心，但是每个服务中心的数据应该是完整的一份数据，这样故障转移的时候就不用考虑哪个机房有数据之类的了，不同用户划分，应该会对用户分块，一个服务中心服务一批，转移的时候，一个服务中心的多个服务块均衡转移到其他机房上，与ES很像，而且数据同步也是只会从主分块到副本分块。上述是猜测，还有一点疑问，主要的业务应该是根据商品查评论，那是不是应该按照商品分而不用户分呢。

还有一点有些疑问，这Mysql的存在原因，可以与商品的搜素一样，也放在ES中么，难道是从可靠性上考虑么，放在Hbase中也可以么，不知道是不是历史的原因才有这Mysql的存在。