评论评价服务进阶之路

初识商城评论

    第一个Java服务，面临Java技术框架、服务器JVM配置、跨语言接口设计等等挑战。接口协定为HTTP，后端服务通信采用DUBBO框架。评论数据表耦合在主库，4张表分别是，商品评论内容、商品评星、店铺评星、卖家回复。

小试牛刀－商品详情页评论接口迁移

     业务：评论列表，全部、带图、好、中、差评、标签条件查询，排序规则时间、最优算法

     设计：简单粗暴，SQL关联查询，商品评论内容和商品评星，memcache根据参数生成key缓存5～10分钟。表问我原因～

初出茅庐－写接口收拢

     评论写业务：添加评论、卖家回复、敏感词删除

     设计：写入接口收拢后才可以将数据进行迁移，分库分表等操作

略有小成－数据迁移

     评论写服务稳定运行后准备数据迁移。商城业务都在主库中写入，分离出评论库，减轻主库写的压力。目前评论相关表总数据量近4亿行，40G+，增长量**万行/天。

   数据迁移方案：

               1、评论库表结构微调优化（字段、索引），数据库与其它业务混用，配置2核16g（伏笔）

               2、上数据库双写，商城库写成功，异步写评论库，无分布式事务，异步写库失败纪录Redis＋报警。读服务不变，还读商城主库

               3、执行迁移程序，程序从商城库中读数据再写入评论库。配图（生产－消费方式，线程池，批量写，失败重试，记redis，重传），图左批量执行，重试逐条执行。

流程图

               4、数据检验，统计总数相同，并采用抽样检查数据方法，对数据准确性进行校验。

     细节：

          1、双写时，更新操作，有评论库的更新数据还没迁移过来的情况，此时需要先指定此ID数据行先迁后更新。

          2、迁移数据时，SQL用ID计算分页的效率远大于limit的分页方式

          3、程序调优生产和消费线程池大小，数据库连接大小，为提高迁移速度非了不少精力，生产环境迁移时，DBA防止读压力大影响商城从库，降低速度迁移。

持续升级－收拢读接口，换数据源

     换详情页读接口数据源至评论库。数据表基本没变化，程序不变，只换数据源。测试OK！理论没任何问题，上线出问题了，接口严重超时，平响太长，部署回滚。

     原因：

               1、商城主库硬件顶配，评论库配置较低，还是混用库

               2、每次查询SQL统计总条数耗时严重

      解决方案

               1、申请升级配置8核32g

               2、加redis计总条数，添加、更新时同步更新计数

     上线后一切正常！

     双写程序持续了一段时间，读接口逐渐收拢（痛苦的过程只有开发才能体会）。所有读接口都迁移至评论服务，监控一周时间，发现是后台复杂SQL慢查询积压导致，解决方案前后台服务分离，前台服务稳定运行，后台服务扩大报警上限阀值。

     最后通过日志和数据表rename的方式，确认评论业务再没有读商城库，程序停止双写。

放大招－分库分表

     某天导火索出现，运营反馈某店评论很久查不出来数据，单表的体积太大，还要关联查询。平均首次查询数据库没缓存情况耗时70～80秒，更有甚100多秒，http、dubbo、熔断等都直接返回失败。

     解决方案：

          1、临时解决方案，加索引表缩小查询范围，加快查询速度

          2、分库分表

          3、加ES为后台提供查询服务，与mysql混用

     讨论后确定双线并行，1和2方案，1方案上线解决眼前问题，2方案随后跟进。

     方案1:

          增加索引表记每天的最大ID和最小ID，查询时间范围时先根据索引表确定ID范围，再进行查询。

     方案2:

          分库分表，拆分规则，以店铺ID hash分4库每库分8张表，共32张表，数据为商品评论内容 和 商品评星 两表合并。目前没有以用户维度查看用户的评论列表，未来用户查看自己的评论也是通过订单号。以商品维度的话，店铺查询时会跨库跨表统计，综合比较店铺ID维度拆分更好。网上有很多拆分规则，选择最适合的业务查询的一个就好。技术采用sharding-jdbc。

          量级预估，目前单表一亿+，分32张表平均每张表约320w行数据，增长量每天**w计算，5年后至约千万级，当然业务量增加，增长量也会随之增加，可接受的范围。

分库分表规则细节：

        以店铺ID hash分库分表遇到的问题，以店铺ID 1000为例，4库分别c_0、 c_1、c_2、c_3，hash取模选到c_0；8表分别t_0、….、t_7，也是0。问题在选到c_0库，再hash选表时只会是t_0、t_4的两张表。哈哈...数据不均！！！

    解决方案，选表时先shopId/10，再%8。也就是店铺ID去掉末尾位再%8。办法不一定完美，但数据均匀分布了。

     功能测试，压力测试完成，上线～先从后台读换到分库表，再逐步将前台业务换过去。

未来－设想

     业务不断变化，数据量越来越大，单纯分库分表的解决方式过于单一，引入搜索和NoSQL数据库，再加Mysql混用的解决方案，系统更稳当、健壮。

     推荐文章：

http://mp.weixin.qq.com/s?__biz=MzIwODA4NjMwNA==&mid=2652897895&idx=1&sn=ca450cf86a75af53101edf7bf0d691e8&scene=19#wechat_redirect

感悟

     评论业务作为商城非主业务的存在，担当Java技术推进的试验场。如动态服务发现、路由策略、灰度、授权系统、熔断等等。是考验，亦是机会，尝试了99种失败，第100次的成功才会更加珍惜。

     分库分表中间件：Mycat、shardingJDBC、spring＋Mybatis手写，规则 hash、id增长横向扩展分片等。

     后续会写订单进阶之路！！！敬请期待～