1 AOP实现Redis缓存服务
1.1 现有代码的分析
说明:
1.虽然在业务层service中完成了代码的实现.但是该代码不具有复用性.如果换了其他的业务则需要重新编辑.
2.由于缓存的代码写在业务层service中,所以代码的耦合性高,不方便以后的扩展.
需求:
1.能否实现代码的复用.
2.能否降低代码的耦合性.
1.2 AOP
1.2.1 AOP作用
名称:面向切面编程.
一句话总结: 在不改变原有代码的条件下,对功能进行扩展.
公式: AOP = 切入点表达式 + 通知方法.
专业术语:
1.连接点: 在执行正常的业务过程中满足了切入点表达式时进入切面的点.(织入) 多个
2.通知: 在切面中执行的具体的业务(扩展) 方法
3.切入点: 能够进入切面的一个判断 if判断 一个
4.目标方法: 将要执行的真实的业务逻辑.
1.2.2 关于通知说明
1.前置通知: 目标方法执行之前执行
2.后置通知: 目标方法执行之后执行
3.异常通知: 目标方法执行之后抛出异常时执行
4.最终通知: 不管什么时候都要执行的方法.
说明:上述的四大通知类型不能控制目标方法是否执行.一般使用上述的四大通知类型,都是用来记录程序的执行状态.
5.环绕通知: 在目标方法执行前后都要执行的通知方法. 控制目标方法是否执行.并且环绕通知的功能最为强大.
1.2.3 切入点表达式说明
1). bean(bean的id) 类名首字母小写 匹配1个类
2). within(包名.类名) 按包路径匹配类 匹配多个类上述表达式是粗粒度的控制,按类匹配.
3).execution(返回值类型 包名.类名.方法名(参数列表))
4)[email protected](包名.注解名) 按注解进行拦截.
1.2.4 AOPDemo复习
1.3 实现Redis缓存
1.3.1 需求分析
1.自定义注解CacheFind 主要被注解标识的方法,则开启缓存的实现.
2.为了将来区分业务,需要在注解中标识key属性,由使用者自行填写.
3.为了用户提供数据超时功能.
1.3.2 自定义注解
1.3.3 编辑CacheAOP
1.3.4 关于环绕通知参数的说明
问题一:连接点必须位于通知的参数的第一位.
否则报错信息如下:
问题二: 其他四大通知了类型是否可以添加ProceedingJoinPoint对象
答案: ProceedingJoinPoint 只能添加到环绕通知中.
报错如下:
1.3.5 关于JoinPoint方法说明
1.4 商品列表分类实现缓存处理
说明:在业务方法中添加缓存的注解.
2.Redis分片机制
2.1 需求数据
如果需要在redis中进行海量的数据存储,如果只有一台redis显然不能实现该功能.如果通过扩大内存的方式也不能达到要求.因为时间都浪费在寻址中. 如何有效的存储海量的数据呢???
2.2 Redis分片说明
说明:一般采用多台redis,分别保存用户的数据,从而实现内存数据的扩容.对于用户而言:将redis分片当做一个整体,用户不在乎数据到底存储到哪里,只在乎能不能存.
分片主要的作用: 实现内存扩容.
2.3 Redis分片准备
2.3.1 创建目录
说明:在redis根目录中创建一个shards目录
2.3.2 分片搭建策略
说明:由于Redis启动是根据配置文件运行的,所以如果需要准备3台redis,则需要复制3份配置文件redis.conf. 端口号依次为6379/6380/6381
复制配置文件:
修改端口号:
根据配置文件名称,动态修改对应的端口即可.