问题 | 分类 | 具体解释 | 可能导致的后果 | 解决方法 | 备注 | |
---|---|---|---|---|---|---|
主从延迟 | 数据库 | 写后立即读的场景,比如订单落地成功抛消息,消息接收方再读订单推订单中心、发触达、落地数据等场景,再读数据时走从库,可能读不到数据。 | 脏数据业务逻辑有问题 | 延迟消费。方案简单,但无法保证彻底解决。强制走主库。底层服务提供方需要注意,强制走主库的逻辑要收口,主库不能被拉挂。 | 收口的意思是只是部分的appkey允许走主库?需要告知提供方走主库的需求 | |
水平越权 | 业务逻辑 | 如果未进行数据权限校验,则可能会出现A用户能看到B用户数据的场景,会造成严重的数据泄漏。如订单详情页把订单ID参数改一下,就可以看到别人的订单。 | 数据泄漏 | 所有私密数据的访问,都需要做水平越权防护,而且用来校验的ID来源一定要是前端Token解析出来的,而不是直接传的。 | 根据id查询用户信息、poi信息等隐私数据时,不能根据前端传递来的参数就直接rpc查询,需要向kms申请权限校验。即获取司机手机号,获取的加密后的token。需要解密才能拿到具体的手机号 | |
表情符号支持 | 数据库 | 如果数据库charset为utf8,则不支持字符串中的表情符号 | 插入数据失败 | 数据库charset改为utf8mb4。插入数据库时做过滤。 | ||
长度截断 | 数据库 | 备注之类的字符串字段,一般建表语句会限制长度,偶尔有某些数据超过了长度限制,插入时会被截断。虽然可能有些业务前端会做一些拦截,但并不能保证所有的地方都会有。 | 数据丢失 | 建表时字段选长点,但该方法不能真正完全解决问题。插入数据前手工数据截断,但数据一致性要求不高,但数据不能丢的场景适用,如插入新客资。接口进来时检查长度,过长向前端提示错误。无论何种处理方法,都不应该有数据库截断异常抛出来。 | 1.字段设计的时候,长度要限制住2.接口进来时检查长度,过长向前端提示错误区别list过大,插入数据库存在性能问题,需要list.partion截断 | |
Limit深分页 | 数据库 | 全量向外部同步数据的场景,有时会写代码根据查询条件并limit,但如果limit到最后可能会出现慢查询。 | 慢查询 | 不要使用limit,使用主键,每次查询的时候都主键id>上次返回的主键id即可。 | criteria.andIdGreaterThan*(id)* | |
消息重复 | 消息组件 | 一般的消息中间件,比如Kafka,会保证消息的必达性,但不会保证消息的唯一性,有可能消息会被重复消费。 | 脏数据逻辑重复执行 | 底层接口支持幂等。这个要注意,但凡是监听消息做某事的,逻辑一定要能幂等。 | 使用分布式redi将key比如orderId记录在redis中实现幂等疑惑:分布式系统,redis存入了,别的微服务能拿到对应的key-val么 | |
MapiGet重复请求 | 前端相关 | mapi接口如果是Get请求,客户端如果请求超时的话会发起重复请求的,这样后端可能就会连续收到两次请求,导致重复处理。 | 逻辑重复执行 | 写逻辑使用Post协议,否则一定要考虑好幂等问题。 | ||
强流程型业务中断无重试 | 业务逻辑 | 审核等强流程型的业务,中间某一步执行失败无重试、告警、定时扫描等处理,导致失败的流程永远无法再执行,如一直处于审核中。 | 业务流程问题,引起ASK | 强流程型业务失败接入Redo重试。流程失败时打告警。定时扫描失败的业务数据,如超期审核中的数据。 | 1.可以将失败的key发送至队列中,定时消费一下2.swan异步重试机制 | |
链接配置HTTPS | 前端相关 | 目前iOS限制链接都要为HTTPS,且公司各平台也都支持了HTTPS,在各种地方配置链接,如前端页面链接、触达跳转链接、推送订单中心链接等,都要配置HTTPS而不是HTTP。 | 全业务不可用,页面打不开 | 配置场景的链接一定要为HTTPS,如果一定要走HTTP,要有充足的理由并且要做说明。 | ||
类静态变量不要被修改 | 代码相关 | 有时我们会在Bean里面定义一些做为常量使用的静态变量,该静态变量如果是个对象,而业务代码中去修改该对象的内容,会导致不同请求的内容串掉。 | 业务脏数据 | 静态变量不要被修改。静态变量一般应该是基础类型,对象类型的可以考虑每次new一个。 | 共享变量只能读,不要写 | |
重复数据提交 | 并发控制 | 分布式场景,添加数据时,如果依赖查询是否有数据然后在做业务逻辑,比如插入,预约频次限制,强走主库没有作用,需要分布式锁控制,数据锁等手段 | 业务脏数据 | 大流量分布式锁做校验(推荐)小流量,影响数据行数少的情况,数据库锁一些场景采用重复提交校验组件 | 1.小流量使用乐观锁2.大流量使用redis分布式锁、zk分布式锁(t1、t2查询发送给供应商的消息时候都不存在,所有都可以执行insert,t1执行了insert,t2执行相同的insert语句的时候会抛出异常么?) | |
事务提交(写场景) | 高并发 | 同一个逻辑代码,如果采用了事务,事务存在先查后做逻辑判断的场景,高并发情况下需要考虑事务的可见性,未提交的事务在例外一个机器上是不可见的。由于不可见可能导致重复插入,逻辑判断错误等异常情况 | 业务脏数据 | 1.队列技术,kafka 按照ID 路由同一个partition,消费单线程处理(同一个供应商的msg,发送到同一个partion中,有序的消费)2.分布式控制3.数据库排他锁 | ||
关键业务异常,增加异常处理重试 | 可用性 | 如果触达或者客资服务突然完全不可用了,是否有最快的办法解决丢失的流量,回放流量问题 | 服务异常时间过长,服务不可用 | 1.方案设计可以采用WAH 思路,先记录消息。比如kafaka 消息等形式。 | ||
SimpleDateFormat 非线程安全 | 代码相关 | 不要在多线程情况下用SimpleDataFormat ,容易导致异常 | 业务异常 | 1.线程新建,不要共享此变量2.使用LocalDateTime工具类。 | 使用LocalDate类 | |
SimpleDateFormat格式化错误 | 代码相关 | 格式化YYYY是指基于周的年,所以2020-12-31这一天所在的周已经是2021年,所以使用YYYY-MM-dd格式化的时候会变成2021-12-31,这个只有一年最后一周才可能会出问题,极其隐蔽。另外DD指的是一年中的第几天,dd指的是一月中的第几天 | 业务异常 | 一般情况下应该使用yyyy及dd,不要使用大写的。LocalDateTime,放弃老式时间格式化类 | 使用LocalDate类 | |
时间边界问题 | 代码相关 | 前端向后端传的筛选条件如果为时间类型,比如按日期筛选订单,则可能只传了2021-01-01及2021-01-10,后端如果直接将OrderDate与这两个时间判断,可能2021-01-10的数据就筛选不出来。 | 业务异常 | 最后一天的日期在转化为时间戳时,要转化为当天的23:59:59,而不是00:00:00 | 01-01 00:00:00 - 01-02 00:00:0001-09 00:00:00 -01-10 00:00:0001-10 00:00:00 - 01-11 00:00:00这样10的数据也能覆盖 | |
价格数据类型 | 代码相关 | 1.使用浮点表示价格会有精度问题。2.使用整型表示价格,单位要统一,否则有些为元,有些分分,不对齐可能会有单位错误。 | 资损 | 统一使用整型,以分为单位,上下游接口沟通注意对齐。 | 1元 = 100分1.2元 = 120分遇到时,具体内容要学习他人代码或网上搜一下 | |
MySQL updatetime字段 | 数据库、代码相关 | 建表的时候必须设置该字段,并且设置更新赋值。同时,再做变更时注意updatetime字段会被同步更新。 | 排查问题时为了缩小范围,往往会有updatetime字段进行限制,如果没有更新会影响排查过程。 | 建表的时候指定更新时变更更新数据时,保证updatetime字段被更新 | updatetime字段的类型要注意 change_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', |
前车之鉴,后车之师
tmax52HZ2023-09-25 12:49
相关推荐
穷儒公羊6 天前
第三十一章 Spring之假如让你来写事务——融入IOC容器篇YZH啊13 天前
Spring事务和事务传播机制huisheng_qaq20 天前
【Spring源码核心篇-06】spring中事务的底层实现与执行流程YUELEI1181 个月前
Spring6 Transactional 事务菠菠萝宝1 个月前
【云岚到家】-day10-2-冷热处理及统计Shenqi Lotus2 个月前
Redis-事务、锁cyt涛2 个月前
主键冲突问题说淑人2 个月前
Redis & 事务 & 总结Hello-Brand2 个月前
数据库系列:主从延时优化络72 个月前
Spring18——Spring事务角色(事务管理员、事务协调员)