大话后端开发的奇淫技巧-2
从事服务端工作,已经有大几年了,从懵懂的小菜鸡,成长为可以自由飞翔的秃鹰,那些逝去青春和的头发见证了自己的成长
或许,这就是高手的应该有样子吧
这里将会把类似的问题/业务场景的解决方案中,提炼出相对通用的部分,作为经验进行梳理罗列出来,共勉
幂等
业务场景:
用户多次点击按钮,或者因为设备的性能问题,连接的网络问题,点击按钮没反应,用户就会继续尝试点击,导致触发多次请求提交
解决方案:
客户端防重点击:
防重点击,只允许点击一次,通过记录按钮的状态值,控制按钮不可点击,等响应结果回来才能再次被点击
服务端:
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(微服务),谈不上每个语言都有多么的熟练,一般的业务开发是没有多大问题
其实语言就是一个实现业务需求的工具,就像锄头和镐子,镰刀和柴刀,菜刀和小刀,基础使用方式差不多,就是在不同的需求场景下优势不一样,适合的场景使用适合的工具
参与这么多个项目和涉猎这么多的语言,会发现服务端的经验是通用的,与语言和项目无关,就是解决一些问题和业务场景的解决思路和方案
竟可能在一段时间里对参与过的业务/问题的解决方案进行梳理总结,这样才能很好的把共同场景的解决方案,提炼成自己的经验,不然时间一长很多做过的内容都忘记了