php小刀模板技巧_大年夜话后端开拓的奇淫技巧

从事做事端事情，已经有大几年了，从懵懂的小菜鸡，发展为可以自由飞行的秃鹰，那些逝去青春和的头发见证了自己的发展

或许，这便是高手的该当有样子吧

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

用户多次点击按钮，或者由于设备的性能问题，连接的网络问题，点击按钮没反应，用户就会连续考试测验点击，导致触发多次要求提交

客户端防重点击：防重点击，只许可点击一次，通过记录按钮的状态值，掌握按钮不可点击，等相应结果回来才能再次被点击

做事端:

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 作为图片命名，可以轻松遍历用户上传的图片，身份证照片等，用于造孽用场

数据脱敏：

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

CND 媒体地址安全：

大部分 cdn 平台都支持

业务场景：

比如，订单下单结算成功后，发送推送关照、发放优惠券褒奖，操作业务异步任务，关照用户领取，等

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

MQ也可以用于实现跨进程，跨措辞通讯

通多订阅方便业务拓展，ack 机制保障实行的完成，去世信行列步队，进行容错处理

不同的MQ中间件的支持略有差异，各有各的特性，大同小异，不同MQ上风也不一样，可以根据自己的需求场景选择得当的中间件

在高并发场景下，通过缓存热数据，减轻 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方便查询

关于监控：

监控可以分为，做事器的监控，业务功能的监控

线上做事器稳定性，决定了业务功能的稳定一个主要成分，这部分紧张是运维这边去保障

业务功能的监控，除了偶尔翻下缺点日志，修复非常情形以外，还须要对付一些业务进行功能的监控，比如：一些定时的做事，定时的推送，每天整点须要对没有记录的用户进行提醒推送，须要保障圈定用户的效率和推送的速率，保障在规定韶光内容推送出去

随着业务增长，数据不断的增加，原来一个小时搞定的实行，可能会一贯的延长，末了可能一整天都实行不完，对应这种业务，就须要在用户反馈之前，优先的get到问题，然后进行优化改进

这个时候就须要有一个监控功能，对业务功能进行监控，超出预警进行预警关照，尽快的改进问题

在做事端开拓的这几年，参与过公司里的好几个项目，有电商干系，工具类干系，等，由于项目本身技能背景和技能改进须要，在开拓措辞上也阅读了好几门，有 .net（项目），java（项目），nodejs（项目），python（采集，爬虫），php（转岗项目），golang（微做事），谈不上每个措辞都有多么的闇练，一样平常的业务开拓是没有多大问题

实在措辞便是一个实现业务需求的工具，就像锄头和镐子，镰刀和柴刀，菜刀和小刀，根本利用办法差不多，便是在不同的需求场景下上风不一样，适宜的场景利用适宜的工具

参与这么多个项目和阅读这么多的措辞，会创造做事真个履历是通用的，与措辞和项目无关，便是办理一些问题和业务场景的办理思路和方案

竟可能在一段韶光里对参与过的业务/问题的办理方案进行梳理总结，这样才能很好的把共同场景的办理方案，提炼本钱身的履历，不然韶光一长很多做过的内容都忘却了

如果你以为这篇内容对你还蛮有帮助，我想约请你帮我三个小忙：