商品打标签设计踩过的坑

2016/08/07 Program

问题一:同步操作,导致批量处理过慢,锁超时

现象:

在批量打标过程中,由于之前设计的是同步操作,一次打标的商品数过多时,导致执行时间较长,运营以为操作失败,多次重新导入和点击,导致系统出现不可预知情况。

原因:

之前为了数据的一致性,对打标过程使用了事务处理,所以当批量打标的时候,相当于对这批数据都进行了行锁,其它操作这些数据的请求都会等待事务的提交,当等待超时,就报错了,“Lock wait timeout exceeded; try restarting transaction”(排查过程)。

代码:

解决方案:

分析业务非强一致性,允许出错,故将事务去掉,将任务修改为异步任务,引入了自动重试机制,并将出错的任务加入到异常队列,用户可以看到那些是失败的任务,并主动进行重试(一般失败原因为商品主图太大,比如20~30M,导致打标失败)。

总结:
  • 系统设计前缺乏整体性思考,明知道同步操作会导致业务处理缓慢,但未进行主动改进。
  • 对项目编写完整的技术方案还是有必要的,有助于梳理现有业务的特性,并为之提供特定的解决方案。

问题二:异步操作,线程池滥用

现象:

运营在一次批量打标3000+商品后,前端用户进行商详查询页面缓慢或超时。

原因:

由于之前紧急将同步操作修改为异步操作时,线程池使用了公用的线程池,此线程池还用于获取其他商品信息,当打标一次占用了太多的线程的任务时,其他请求就必须排队,由于打标是一个非常耗时的操作(每一个大约200~500ms不等),所以导致队列外的大量请求因为获取不到请求线程处于等待状态。

代码:

解决方案:

定义标签管理自己的线程池。

总结:
  • 深入了解线程池的使用方法,对系统中的线程池提前做好统一规划。
  • 一定程度上限制线程池的使用,防止线程池滥用或者过度使用。
  • 熟悉系统当前可能最大的线程数,系统支持的最大线程数,防止线程数超过外部限制。

    问题三:业务范围把握不清,多系统间数据处理遗漏

    现象:

    最开始标签只考虑了详情页和搜索列表页,忽略了订单列表页、CMS关联的活动列表页,导致用户在活动列表页、订单列表页中看不到商品标签。

    原因:

    缓存清理部分未对CMS活动列表页、订单列表页中商品数据进行更新导致数据不一致。究其原因,我们在对一个已经存在的功能进行业务重构时,必须首先完全掌握之前的业务处理流程,把各个与之相关的点都梳理出来,弄清楚业务边界,如果能拿到之前的文档最好,其次最好与之前的作者做好信息沟通,单纯的通过阅读代码很容易遗漏一些细节点。

    总结:
  • 对老功能重构,首先必须通过一些手段完全掌握业务的边界和技术的实现手段。
  • 我们在设计代码时,尽量做好抽象和代码的内聚性,减少代码的扩散和功能性逸出。
  • 方法标签上必要的业务注释可以帮我们更好的理解代码。
  • 当一个功能设计N个系统操作时,我们需要认真对待功能的设计,考虑数据的实时性、一致性。

    问题四:事务操作中存在消息、Redis等不支持回滚的操作

    现象:

    去标时,详情页的标去掉了,但是通过发消息进行的搜索结果中标未去掉,导致数据不一致。

    原因:

    事务处理过程中,先进行了数据删除,然后通过消息通知搜索进行商品索引重构并进行了缓存清理,此时为了防止缓存被击穿,对数据进行了加载,所有完成后才会进行数据提交,这导致了,数据提交前,搜索已经收到了消息并进行了搜索重构,搜索拿到的是事务未提交前的数据,所以导致数据未更新。

    代码:

    解决方案:

    取消事务的限制,在这样的一个处理链路中由于存在无法回滚的操作,所以嵌套事务是没有必要的,其次,嵌套事务还可能会带来更大的问题。

    总结:
  • 不是任何操作都是可以事务操作的,不要滥用事务处理机制。
  • 在进行功能设计的时候,全局考虑数据一致性方案,强一致性、弱一致性、最终一致性。
  • 在事务里面操作外部系统数据,一定要小心,需要考虑分布式事务的处理,否则请放弃使用事务。

    问题五:测试不充分,导致低级bug产生

    现象:

    CMS活动页面过期标签未失效,搜索、详情页、订单列表页均已失效。

    原因:

    搜索、详情页、订单列表页中标签失效的原因是虽然标签数据未被清理,但是通过时间戳判断做了失效,但是CMS只能通过新图覆盖的方式进行数据更新,所以如果去标的定时任务未执行时一定会导致数据未更新。

    代码:

    在进行结束时间移除标签的SQL中,由于通过代码拷贝,字段未修改,导致业务逻辑异常,查询出来的数据为空,故去标任务等价于未执行。

    解决方案:

    将第二个SQL中的start_time全部替换为end_time

    总结:
  • 没有经过验证的点,均有可能存在问题,不要抱侥幸心理。
  • 项目上线没有经过codeReview,且上线后没有做全功能的验证。
  • 任何反馈出来的问题,都可能是隐藏的bug,及时排查问题,防止问题进一步扩大。
  • 复制代码非常容易出错,必须格外小心,如果存在相同结构的代码,尽量通过抽象完成结构统一。

Search

    Post Directory