1. 增强一个java类中的某个方法的三种方法:
1.继承方式 : 能找到父类,能控制这个类的构造
2.装饰者方式 : 在IO中应用最多,包装的对象和被包装的对象都要实现相同的接口;获得被包装对象的引用.
缺点: 如果接口中方法比较多,增强的方法少,其他的功能方法需要原有的调用;
步骤:
自定义类实现和被包装类的接口,然后在构造方法的形参接收被包装类的引用,
创建成员属性被包装类, 在自定义类的方法内,调用被包装类的方法.
注意:PreparedStatement要有返回值
3.动态代理的方式 : 被增强的对象的只要实现了接口就可以
====================================秒杀技术=============================================
分布式秒杀,为什么需要分布式锁:
1. 当A服务 和B服务,同时接受到秒杀请求的时候,因为都是先get库存,然后在set库存,
而redis因为是单线程的会根据发出的命令串行化到序列中,
这样就可能造成A服务和B服务的get请求挨着执行获得的数据是一样的,
结果造成他们同时都会set进去同样的值,这样就会超卖.
2. 分布式锁:
① redis自身分布式锁: 用setNx,当第一个请求加锁的时候, 但是要自己考虑不能拒绝下一个请求,这个时候即使第一个请求
已经解锁,但是尝试加锁方不知道,只能按照自己设置不断循环尝试加锁,对redis很大压力,性能特别差
② lock单服务锁性能好的原因: JVM直接支持, 没有网络开销,lock和unLock是由通信的,
就是unlock的时候会通知尝试获得锁的那个线程,直接解锁
③ redisson分布式锁,结合了lock,redis, netty框架,他的上锁同样适用的setNx,不过他的
Lock和unlock方法也是用的java中的本地锁redis异步发送消息通信, ,用到了任务计时器来动态算尝试解锁间隔时间
3. 秒杀应该限流,
①做成可配置的放在数据库配置表内,在拦截器里面,用RateLimiter拦截每秒并发量等待或者丢弃
②利用redis的incr,来控制到每个商品的点击抢购数量
③ 限流器: guava : 漏铜算法, 请求倒入桶中,下面处理是桶漏洞,当请求大于漏洞的时候就拒绝,可以设置每秒的令牌数
4. 秒杀应该在发MQ之前,就应该先执行校验操作,去掉大部分请求,直接返回给前端
5.发送MQ后,需要在用redisson分布式锁,把结果放到redis里面,让前端去轮循请求
6.BeanUtils的copyproperties性能差替换为 BeanCopier.copy
==============================单点登录========================================================
首先所有用户访问的微服务都通过user服务来鉴权, user服务鉴权两种方式一种是
① userId和uuid, 这里uuid存在的意义在于用户登录态失效,单点登录
② 单点登录: 重新登录后会生成新的uuid, uuid放在redis里面有过期时间
跨域鉴权:
1. 判断是否有userid和token,
①有则把token和userid放到cookie里面
②没有则清除cookie信息,去请求其他域名user服务同时带上自己的页面url,
2.user服务进行鉴权
③:鉴权未通过,打开登录页面,登录完成后,前端取出页面url跳转过去.并且带上token
④:鉴权通过,拼上token跳转到商品详情页,拦截器进行拦截,通过token获取到userid
===================================订单多渠道路由=======================================
1.创建各个对应支付渠道的实例类
2.创建工厂类: 根据传入的渠道类名称来创建相应的支付类
3.封装统一的创建修改查询方法类
