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