鉴权系统的梳理及并发问题的考虑
oauth2的思想类似于post 2次TCP
1、客户端url -> 授权服务器 (申请获取授权)
客户端url <- 授权服务器 (返回唯一授权标识token)
2、客户端url + token -> 资源服务器 (验证token 放行)
所以系统的工程划分为：授权工程和鉴权工程
授权：可供网关gateway实现微服务对外权限的授予 （应用在登陆领域）
鉴权：可供网关gateway实现微服务对外权限的签定 （应用在API领域）
授权服务的工作流程梳理：
extends WebSecurityConfigurerAdapter重写configure 配置formLogin登录入口URL (spring security的验证配置)
extends AuthorizationServerConfigurerAdapter重写configure 配置token、身份认证器，配置认证方式等 （认证服务配置）
implements TokenEnhancer 自定义token携带内容 （token增强器）
implements UserDetailsService.自定义查询数据库中用户信息
签权服务的工作流程梳理：
URL -> gateway filter
step1: 不需要鉴权的url放行
step2: 未携带token 直接跳出
step3: 调用签权服务看用户是否有权限 如果有则放行 请求资源微服务
签权服务
step1: token是否有效 （通过jwt解析判断是否有效）等一些验证工作(鉴权客户端)
step2: 从鉴权服务端 处理是否有权限（用户权限资源 与 请求的URL 比对是否有权限）
注：
用户权限资源：通过security获取authentication的用户名得到拥有权限资源
其中的权限资源 则通过 rbac 的资源服务器去查询
请求的URL：通过URL请求+ Method 则是取 初始化资源数据
step4：step3返回true 则放行 否则反之
在鉴权服务端在启动时初始化资源数据
-------------------------------------------------------------------------------------------------
socket再io的资源的读写之间回生成一个线程，严重的资源浪费
socket中nio是一个线程 采用多路复用机制，线程内部client轮询连接是否有数据可读，server轮询是否又新的连接，NIO底层由epoll实现，空轮询会导致cpu升高，编程复杂
Netty封装了JDK的NIO，只需要关心业务逻辑
Netty在内部使用了回调来处理事件；当一个回调被触发时ChannelHandler实现处理当一个新的连接已经被建立时，ChannelHandler的channelActive()回调方法将会被调用
ChannelFuture提供了几种额外的方法，这些方法使得我们能够注册一个或者多个ChannelFutureListener实例。监听器的回调方法operationComplete()
轮询客户服务端继承ChannelInboundHandlerAdapter 重写 -主要工作是等待并接受服务器发回的消息
channelRead()——对于每个传入的消息都要调用；响应
channelReadComplete()——通知ChannelInboundHandler最后一次对channel-Read()的调用是当前批量读取中的最后一条消息；
exceptionCaught()——在读取操作期间，有异常抛出时会调用。
ngix + Keepalived（分流 + 健康状态选举）
解决并发超卖问题：
数据库压力导致响应变慢，查询慢、写入慢甚至是服务无响应、宕机
数据库会首先出现访问瓶颈，将操作非常频繁的数据在内存缓存中进行，然后将数据异步写回数据库
在缓存数据库中(redis/memcached)解决锁的问题，缓存数据库提供了两种解决方式。
第一个是乐观锁，第二个是队列。
乐观锁：在加锁的数据上增加版本号
大数据量的考虑问题：
考虑表拆分-（表名字不一样，但是结构完全一样）
按业务分，比如 手机号的表，我们可以考虑 130开头的作为一个表，131开头的另外一张表 以此类推
如果是交易系统，我们可以考虑按时间轴拆分，当日数据一个表，历史数据弄到其它表
限流问题：
限流就是限制系统的输入和输出流量已达到保护系统的目的，比如：延迟处理，拒绝处理，或者部分拒绝处理等等
令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 当桶满时，新添加的令牌被丢弃或拒绝。
1、使用guava提供工具库里的RateLimiter类(内部采用令牌捅算法实现)进行限流 （不适应分布式限流）
2、使用Redis实现，存储两个key，一个用于计时，一个用于计数。请求每调用一次，计数器增加1，若在计时器时间内计数器未超过阈值，则可以处理任务
