一个小问题的分析

    今天线上出现了一个字符超长引起mysql抛出异常的问题

    问题本身不大,上游系统有bug,传递的字符串没有做trim处理,导致报文节点中的字段远远超出预留长度

    反应给领导的时候,领导对我的汇报并不满意

    我说,这个问题是由于上游传下的数据过长

    领导说,这是表象,出现这个问题的根本原因是什么?为什么在上游传下来的时候没有校验住,而使错误的数据流入系统了引起报警呢

    之后的对话有点记不清了,我提出这个校验应该由上游系统做,于是叫来了上游系统的负责人,在一旁的组长也加入了讨论

    讨论中大体涉及到了如下几点:

    • 错误的数据是前端下传的,还是系统bug引起的
    • 前端控件是否有限制,是否有校验,是否有提示
    • 是否应对数据长度添加校验

    讨论中还是感到了自己表述能力的匮乏。讨论中提到的点,我也大都能想到,但是当我向领导汇报的时候,我似乎只能说个,上游系统问题,上游应当校验,听起来倒有点推卸责任的感觉

    我所思考的内容是:

    这个数据到本系统时,已经分发到了多个其他系统,所以类似异常数据的处理,肯定不在本系统做,做了其他系统也要做,如果处理逻辑差异较大,会造成数据不一致

    而上游若要对字段长度做校验,那理论上所有字段都应该校验,但是关于数据长度,要么业务上有明确的限制,比如评论限制200条,那么底层保留两百的长度,这种校验则应在前端就有所体现,校验逻辑应当在前端直接提交的服务端有所体现。

    而如果没有明确的业务上的长度限制,如用户地址,理论上,用户想输入多少就输入多少,但是正常情况下,地址信息的长度是有限的,最详细的地址比如身份证上的地址,长度也是有限的,要保存数据的服务端预留一个长度即可,如果加上校验,则很被动,一旦出现真实的而又超出系统限制的字段,不仅需要修改数据库的长度,还要修改代码中的校验长度,无法快速的让正确信息保存下来

    所以,对于本次问题的结论,我想应当是:
    上游修正bug,其他系统不动

    validate