评论评价服务进阶之路

初识商城评论

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

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

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

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

初出茅庐-写接口收拢

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

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

略有小成-数据迁移

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

   数据迁移方案:

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

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

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


评论评价服务进阶之路_第1张图片
流程图

               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增长横向扩展分片等。

     后续会写订单进阶之路!!!敬请期待~

你可能感兴趣的:(评论评价服务进阶之路)