redis数据失效及springIOC的特性

redis数据失效的6种情况

失效----内存不足，还有写操作的时候，redis如何执行？

LUR：近似算法，访问率算法，频率算法

• 有效期过期策略，在全局数据范围内，找到设置有效期的数据，删除访问频率最低的，保存新数据
• 全局过期策略，在全局数据范围内，找访问频率最低的数据删除

全局：随机算法

• 有效期过期策略，在全局数据范围内，找有设置有效期的数据，随机删除一条
• 全局过期策略，全局数据范围，随机删除一条

无：没有任何算法

• 有效期，全局范围内，找剩余有效期最短的删除
• 永不，不删除任何数据，阻塞：写操作阻塞

1.volatile-lru:从设置了过期时间的数据集中，选择最近最久未使用的数据释放

2.allkeys-lru:从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，选择最近最久未使用的数据释放

3.volatile-random:从设置了过期时间的数据集中，随机选择一个数据进行释放

4.allkeys-random:从数据集中(包括了设置过期时间以及未设置过期时间)随机选择一个数据进行入释放

5.volatile-ttl：从设置了过期时间的数据集中，选择马上就要过期的数据进行释放操作

6.noeviction：不删除任意数据(但redis还会根据引用计数器进行释放呦~),这时如果内存不够时，会直接返回错误

spring: 描述ioc特性，并考虑是否存在潜在的安全问题

1.IOC是什么

IOC控制反转：控制-是对对象生命周期的控制

反转-是说将控制权力交出来

将对象的声明周期控制权力交给spring容器。

2.实现的角度

BeanFactory：简单的bean对象工厂，只能创建对象，并维护对象的属性注入。

ApplicationContext：应用上下文。应用-一个整体的代码系统，就是启动一次JVM虚拟机，上下文-和左侧定义相关的所有的数据集合。除BeanFactory功能之外，还包括：代理创建，事务管理，本地加载，表达式解析，测试环境准备等

3.功能的角度

解耦合，代码中没有对象生命周期的管理，都是面向接口和父类型开发的，所以各类型之间的耦合极低。需要修改实现的时候，使用扩展的方式，配合配置让容器提供新的实现即可。

4.安全的角度

潜在安全问题：

内存问题：springIoc容器默认启动的时候，创建所管理的所有bean对象。对象是否一定使用？对内存的压力是否过大?考虑局部lazy-init方式初始化环境。

bean数量问题：spring容器默认对bean的管理是单例的。如果使用默认管理方式，spring管理的bean对象，必须是线程安全的。否则需要提供scope=prototype才能解决单例线程安全隐患。

容器数量问题：如：在springmvc开发中，有两个容器ContextLoaderListener创建的，DispatcherServlet创建的，这两个容器适父子容器，父容器是ContextLoaderListener创建的，子容器可以直接使用父容器管理的所有bean对象（普通的bean，代理的bean，通知bean等）。父容器不能使用子容器管理的任何bean对象。且所有容器管理的properties（property-placeholder加载的内容）是容器独享的。

2.为什么使用ioc

第一，对象的实例化不是很简单的一件事，比如对象的关系比较复杂，依赖关系往往需要程序员维护，这是很麻烦的一件事情

第二，解耦，由容器去维护具体的对象

第三，托管了类的产生过程，比如我们需要在类的产生过程中做一些处理，最直接的例子就是代理，如果有容器程序可以把这部分过程交给容器，应用程序则无需去关心类是如何完成代理的

3.ioc与DI

在spring当中实现IOC的这个目标用的就是DI

DI依赖注入，

注入：容器把依赖对象填充到被依赖对象的过程叫做注入，比如容器把Order实例化，然后把Order通过各种方式 填充到User类中Order属性的过程叫做注入。这里的各种方式 分为两种方式分别是构造方法注入和setter注入，

dict扩容问题