评论评价服务进阶之路

初识商城评论

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,830评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,992评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,875评论 0 331
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,837评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,734评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,091评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,550评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,217评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,368评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,298评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,350评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,027评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,623评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,706评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,940评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,349评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,936评论 2 341

推荐阅读更多精彩内容