SpringBoot通过注解实现权限控制，每一个增加权限注解的API，都会严格校验权限。
在RBAC（Role-based access control）设计中，一般有用户表、角色表、权限表，用户表和权限表通过中间角色表关联起来，二者一般不直接关联。
在简单的场景中，可以不使用权限表，直接通过角色口头或文档约定其权限，前后端也只通过角色判断权限操作。
在复杂场景中，或者权限很细的场景中，必须使用权限表，前后端主要通过权限字符串判断权限操作，角色主要作用是关联了二者的数据，但大多时候不被直接使用判断权限操作。
权限操作过程中，后端通过权限接口返回用户所有的权限信息，如角色、权限字符串，甚至权限菜单等。前端在权限事件触发前，都需要校验用户是否具备权限，一种是不具备权限则不显示，另一种是不具备权限提交被打回。当前端请求到后端后，后端API上已注解需要的权限，控制层之前的过滤器会校验用户是否具备此权限，如具备则放行，否则拦截返回，提示权限不足等错误。
more >>注入一个 Bean 有三种方式（set 注入，构造器注入，字段注入），Spring 推荐使用构造器的方式注入 Bean。
推荐使用Lombok提供的 @RequiredArgsConstructor 注解注入Bean，其本质是构造器注入。
more >>到目前为止有两种压测方式：
不扩容压测一般不推荐，这种方式需要对业务指标打折作为目标来进行压测，最后在扩容的时候还是需要压测一次，因为局部压测不能完完全全代表整体压测，如果整体压测出现问题，那么所有的局部压测都是白费苦工。局部压测主要为了优化局部API，所谓木桶理论，需要补高短板，才能提高整体的效果。（谨慎一点的话，可以先局部再整体）
扩容压测，就是指容量扩容到大促支撑位，然后进行压测。
值得注意的是，压测一定是针对生产！
有些同学对开发环境、测试环境、预发环境、灰度环境、仿真环境进行压测，从而推断出生产环境的性能。这是万万不可取的，因为环境不同，服务器的性能不一样，生产环境和其他环境的 DB 性能也不一样，还有一些中间件性能也不一样。所以，压测一定要在生产环境压测，但是有一个缺点，就是会对线上的正常流量产生影响，这也是不可避免的，所以压测的时候，一般都会选择流量不大的时候进行，尽量减少对正常流量的影响，一旦产生影响，请立即停止压测。
还有就是压测需要流量爬坡，切记不可一步到位，按照一定比例逐渐施压，每一个坡度都观察几分钟，没问题继续施压，达到目标后观察几分钟没问题直接停止压测，不可恋战！
为什么不恋战？因为大促的流量趋势就是那几分钟，长久的施压对服务器的性能有一定影响，比如 CPU 飙高啊，频繁 GC 啊等，所以在在压测过程中还需要不断观察系统整体性能，还有就是也会影响到正常的用户访问。举个例子，奥运会举重，明明只需要保证举起来三秒即可，你训练的时候难道要举起来三分钟吗？
python下载网络url图片到本地
关键方法
1 | from urllib.request import urlretrieve |
在支付场景中，订单超时状态改变后，必须把支付链接的有效性失效，否则可能出现掉单错误。如：用户支付界面一直在，订单超时后，用户又去支付，就会导致付钱不到货。
支付链接失效须实现两层：第一层是Redis缓存的失效，即用户通过系统无法再获取支付链接；第二层是支付服务商提供的支付超时失效，即一定设置支付超时时间（timeoutExpress），这点尤其重要，从根本上失效了支付链接。
另外，支付链接的超时时间 一定小于等于 订单状态的超时时间。建议小于订单状态的超时时间，因为当存在用户接近订单超时去支付时，支付成功的回调可能在订单超时执行之后，则又出现掉单错误。因此，最好保证：支付链接超时时间 + 支付回调时间 <= 订单状态超时时间。
为降低掉单到最小概率，在订单状态超时执行过程中，一定再去查询一次订单支付结果，如果发现订单已经支付，则跳出执行支付成功方法，否则继续执行支付失败的订单超时方法。
tag:
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true