关于网站建设的建议的征集,联合办公室设计,新闻聚合网站开发,开发公司副总经理岗位职责问题分类具体解释可能导致的后果解决方法备注主从延迟数据库写后立即读的场景#xff0c;比如订单落地成功抛消息#xff0c;消息接收方再读订单推订单中心、发触达、落地数据等场景#xff0c;再读数据时走从库#xff0c;可能读不到数据。脏数据业务逻辑有问题延迟消费。…问题分类具体解释可能导致的后果解决方法备注主从延迟数据库写后立即读的场景比如订单落地成功抛消息消息接收方再读订单推订单中心、发触达、落地数据等场景再读数据时走从库可能读不到数据。脏数据业务逻辑有问题延迟消费。方案简单但无法保证彻底解决。强制走主库。底层服务提供方需要注意强制走主库的逻辑要收口主库不能被拉挂。收口的意思是只是部分的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查询发送给供应商的消息时候都不存在所有都可以执行insertt1执行了insertt2执行相同的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:0001-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 更新时间,
