SFLYQ

大话后端开发的奇淫技巧-2

2020-12-01
SFLYQ

从事服务端工作,已经有大几年了,从懵懂的小菜鸡,成长为可以自由飞翔的秃鹰,那些逝去青春和的头发见证了自己的成长

或许,这就是高手的应该有样子吧

头秃图

这里将会把类似的问题/业务场景的解决方案中,提炼出相对通用的部分,作为经验进行梳理罗列出来,共勉


幂等

业务场景:

用户多次点击按钮,或者因为设备的性能问题,连接的网络问题,点击按钮没反应,用户就会继续尝试点击,导致触发多次请求提交

解决方案:

客户端防重点击:
防重点击,只允许点击一次,通过记录按钮的状态值,控制按钮不可点击,等响应结果回来才能再次被点击

服务端:

1.表约束

表设计字段的唯一约束,比如:签到记录表,用户 ID+签到日期这两个字段组合建立唯一索引 UNIQUE,使用事物操作,先 INSERT 签到记录,成功后再去 UPDATE 积分 并行执行的时候,必然只能有一个 INSERT 成功,其他都失败,最终只会累加一次积分

2.分布式锁

分布式锁约束,可以利用 redis incr 原子操作的特性来实现

在操作业务前,先获取用户 ID 的 incr,获取到值=1,代表获取到锁成功,进行原子操作,然后执行业务逻辑,执行成功后删除掉 key

如果获取到值>1 获取执行锁失败,代表执行没结束,锁没有释放,无法继续执行,直接返回失败

这里需要注意避免网络抖动或者业务执行报错导致最终 key 删除没成功,所以再执行 incr 获取锁成功后,同时获取下 ttl 值,如果 ttl 没设置,这个时候需要对 key 设置下 ttl,超出时间后让 key 自动过期,以免锁没释放,导致死锁

3.token 机制

在操作前先获取令牌 token,token 只能被使用一次,执行业务逻辑前,需要去 update token 使用状态,update 成功,才能执行后续业务逻辑,update 失败,代表 token 已经被使用,返回失败

可以使用 mysql token 表+redis list,list 作为令牌桶,需要的业务从队列中 pop 获取令牌,使用的时候状态 update token 表


主从延迟

业务场景:

用户反馈说看不到刚提交的数据或者没更新成功,或者触发了非正常流程能理解的逻辑,排查后发现数据正常

解决方案:

说到主从延迟,大家应该就不陌生了,只要数据库(mysql,redis)部署是主从分离的,多多少少都会遇到过这种问题

低概率场景,就是数据写入/更新到主库,从库因为网络抖动等原因,没有及时同步到,然后查询的时候走的是从库,导致查到的是脏数据,这种情况就只能竟可能保障服务器环境稳定

其实出现这种问题比较多的情况是,insert/update 到主库成功后,马上就查询数据,这个时候可能数据还没同步到从库,虽然主从同步会比较快,但是还是有一定的延迟性

这种情况就需要将查询指定到主库上进行操作,就可以避免主从延迟,查询不到最新数据的问题


并发

业务场景:

用户快速点击按钮,或者通过压测工具,写脚本发起并发请求分发到多台服务器,多台同时接收到请求,多次/并发请求有机率会并行执行,导致超出正常逻辑范围的问题

往往在这种情况下,会出现很多异常的数据,比如:同一天多条的签到记录,并且多次累加积分奖励

职业羊毛党使用工具或者写脚本恶意发起并发请求接口,翻倍获利后提现,从漏洞中谋取利益

解决方案:

表约束
同 ↑ 幂等的解决方案


安全隐私

业务场景:

在涉及用户隐私数据或者一些商业性敏感数据业务,接口下发数据的时候没有做脱敏,把用户的隐私的数据赤裸裸的暴露出来,如:将用户的手机号,身份证号码,等重要信息直接明文及接口输出

将用户 ID 作为图片命名,可以轻松遍历用户上传的图片,身份证照片等,用于非法用途

解决方案:

数据脱敏:

在不违反系统规则条件下,对真实数据进行改造,进行数据脱敏

  • 根据规则改造敏感数据输出
    • 中间加星
    • 截断
    • 替换
  • 敏感数据传递,加密处理
    • aes 加密
    • hashids 足够短,不可预测且唯一的数字 ID

CND 媒体地址安全:

大部分 cdn 平台都支持

  • URL 鉴权
    • 防止通过规则去构造地址
  • 防盗链
    • 地址设置过期时间,超时后不可访问
  • 限制访问
    • Referer 防盗链
    • UserAgent 黑白名单
    • IP 黑白名单
    • 等(具体看第三支持)

MQ 业务解耦神器

异步业务解耦

业务场景:

比如,订单下单结算成功后,发送推送通知、发放优惠券奖励,操作业务异步任务,通知用户领取,等

类似这种非业务主流程里内容,主流程执行完成后可以立即返回响应给用户,其他一些成功后的附加操作通过入列到 MQ,进行异步的处理

MQ也可以用于实现跨进程,跨语言消息通讯

通多订阅方便业务拓展,ack 机制保障执行的完成,死信队列,进行容错处理

不同的MQ中间件的支持略有差异,各有各的特性,大同小异,不同MQ优势也不一样,可以根据自己的需求场景选择合适的中间件

  • rabbitmq
  • kafka
  • rocketmq

缓存大法

在高并发场景下,通过缓存热数据,减轻 DB 压力,提高响应速度

缓存可以分为服务端缓存和客户端缓存

服务端缓存:

当前使用比较多的分布式内存缓存数据库就是 redis,结合支持的数据类型和特性,再加上开发的创造力,可以满足大部分需求


但是在使用的过程中也会遇到一些使用不当的问题,这里罗列下常见的问题:

1.缓存更新

对于一些用户私有数据,一般会在数据更新的时候,del cache,然后后续获取的数据的时候,先从 cache 中获取,如果不存在,再从 db->cache,最后输出给用户

但是由于网络抖动等,有可能会低概率的导致 del cache 没成功,所以,一般我们会在设置 cache 的时候加过期时间,让脏数据可以在短时间内失效,这样也可以对于一些不常查询的数据进行过期清理

对于一些公用的热数据,如:商品列表等,运营人员通过后台配置商品,配置完成后,最后操作缓存更新,这个时候需要对缓存进行平滑的过度更新,不能先删除 key,再写入缓存,这种操作会导致有用户在缓存更新进去前,短暂时间区间内获取不到商品

之前做过类似的需求,解决方案就是,会在创建的缓存 key 设计版本号规则,然后缓存创建成功后,在替换可以展示的版本号,把旧的版本号的数据设置过期时间

旧版本数据不能马上删除,设置合理过期时间,是因为旧版本数据还会在短时间内被使用,比如:用户已经使用旧版本数据查询,并且继续后面的分页查询,设置过期时间可以合理时间内再过去清理掉旧不使用的数据

数据获取就先获取当前要展示的版本号,然后获取本号对应的数据

早前有写过一个类似的,场景会更佳复杂的缓存更新的方案,高并发业务接口开发思路

2.穿透

cache 和 db 中都没有数据,读完 cache 没有,再读 db 还是没有,每次都请求到 cache 和 db

一般情况就是 null 数据问题导致,解决方案就是,可以将null也缓存起来,避免穿透到 DB 如果有较多 null 数据,可以使用 bitmaps 布隆过滤器,来标识存储 null 的数据,节约存储空间

3.击穿,雪崩

出现大量 cache 数据同时过期,导致大量请求同时请到 db

对于高并发业务的热数据的缓存,就不能删除/设置过期时间,只能通过平滑的过度进行更新,类似上面缓存更新中提到的方案

4.压缩数据,数据过期

redis缓存使用的是内存空间,所以比较稀缺,即使财大气粗分布式再多的机器,也经不起不起随意的霍霍

对于不使用的字段,或者数据,都不要存储到缓存,有时候就是为了方便,直接json序列化整个对象,就直接缓存起来了

对于用户私有的缓存,或者热度不高的缓存,需要设置缓存过期时间,避免长期不查询的垃圾数据堆积,占用空间,后面遇到的瓶颈,再来清理就麻烦了


客户端缓存:

1.缓存版本数据

客户端缓存数据+数据版本号,每次获取数据的时候上传数据版本号参数,服务端校验是否最新数据,如果是最新就不下发数据,客户端可以继续使用本地数据

2.增量拉取更新

服务端接口返回数据的时候,返回当前时间戳,客户端对数据和拉取时间戳进行缓存,后续客户端请求带上时间戳,服务端匹配更新时间>时间戳时间的数据,进行下发,实现客户端数据的增量/修改更新


redis 巧用


日志/监控

关于日志:

当线上用户反馈问题的时候,我们需要去排查问题,就靠用户的几段描述和APP的截图,有时候很难排查出根本问题

这个时候如果能提供用户的请求日志轨迹就可以很好帮助到排查

我们目前对于日志这块的支持有两块,一个是nginx请求日志,通过elk搭建日志系统,进行日志的收集和展示

同时在数加也会备份可一份长时间的请求日志,对于历史过长的请求日志,可以到数加进行表查询

一般的错误日志也可以上报到elk中,独立出一个err group方便查询

  • ELK
  • 数加历史请求日志

关于监控:

监控可以分为,服务器的监控,业务功能的监控

线上服务器稳定性,决定了业务功能的稳定一个重要因素,这部分主要是运维这边去保障

业务功能的监控,除了偶尔翻下错误日志,修复异常情况以外,还需要对于一些业务进行功能的监控,比如:一些定时的服务,定时的推送,每天整点需要对没有记录的用户进行提醒推送,需要保障圈定用户的效率和推送的速度,保障在规定时间内容推送出去

随着业务增长,数据不断的增加,原本一个小时搞定的执行,可能会一直的延长,最后可能一整天都执行不完,对应这种业务,就需要在用户反馈之前,优先的get到问题,然后进行优化改善

这个时候就需要有一个监控功能,对业务功能进行监控,超出预警进行预警通知,尽快的改善问题


总结

在服务端开发的这几年,参与过公司里的好几个项目,有电商相关,工具类相关,等,因为项目本身技术背景和技术改进需要,在开发语言上也涉猎了好几门,有 .net(项目),java(项目),nodejs(项目),python(采集,爬虫),php(转岗项目),golang(微服务),谈不上每个语言都有多么的熟练,一般的业务开发是没有多大问题

其实语言就是一个实现业务需求的工具,就像锄头和镐子,镰刀和柴刀,菜刀和小刀,基础使用方式差不多,就是在不同的需求场景下优势不一样,适合的场景使用适合的工具

参与这么多个项目和涉猎这么多的语言,会发现服务端的经验是通用的,与语言和项目无关,就是解决一些问题和业务场景的解决思路和方案

竟可能在一段时间里对参与过的业务/问题的解决方案进行梳理总结,这样才能很好的把共同场景的解决方案,提炼成自己的经验,不然时间一长很多做过的内容都忘记了


首发于Github:🌈大话WEB开发,欢迎star 😻


有任何想说的请留言哦
转载请申明原文地址,谢谢合作

Follow @sflaqiu

老铁们关注我的《大话WEB开发》微信公众号,跟踪我的原创博文

并不定时推荐WEB开发相关技术博文,共勉与学习交流!二维码↓

我的公众号

类似 文章


留言