redis持久化
RDB 的优缺点
优点:
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。
缺点:
1 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
AOF 的优缺点
优点:数据的完整性和一致性更高
缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。
redis 内存淘汰策略
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据。
- noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
- allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key。
- allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个key。
- volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key。
- volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key。
- volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的key优先移除。
bidmap
spring事务传播
事务传播行为
用来描述 一个被事务传播行为修饰的方法 被 嵌套进另一个方法 时,事务如何传播。
7种传播行为
PROPAGATION_REQUIRED:外围有事务则加入形成同一个事务,外围无事务则新开启,内部事务之间相互独立
PROPAGATION_REQJIRES_NEW:外围有无事务都开启新事务,相互独立,且与外围事务相互独立开
PROPAGATION_SUPPORTS:若外围没有事务则非事务执行,有事务则同 REQUIRED
PROPAGATION_NOT_SUPPORT:非事务执行,若外围存在事务则挂起该事务
PROPAGATION_MANDATORY:使用外围事务,若外围无事务则抛出异常
PROPAGATION_NEVER:非事务执行,当外围有事务则抛出异常
PROPAGATION_NESTED:外围无事务,则同 REQUIRED 内部开启新事务相互独立。外围有事务,则内部事务是其子事务,主事务回滚则子事务全部回滚,子事务回滚不影响其他子事务和主事务
在Spring的@Transaction中,有个重要的属性:Propagation,指的是事务方法之间发生嵌套调用时,事务的传播行为(当前调用的这个方法的事务,和当前的其他事务之间的关系)。
在TransactionDefinition中定义了7种事务的传播行为,这里简单记录一下。
分布式自增ID
方案一
1.使用独立的一张表保存,如ids来保存最小未被使用的id值,该表每条记录对应一个业务表的id使用,该表有两个字段key, value, key对应于每个业务表,value是相应的id值
2.每当前台应用初始化的时候,就从该表中读取出value,同时将value + 100后写回ids表中。(表示从value - value+99(该值可以根据实际情况进行设置,越大值回写数据的操作越少,但是若应用启动频繁则id浪费较多) 这个区间内的id值将由该台应用独自使用)。
3.使用两个变量来辅助ID的生成,nextId:下一个Id的值, maxId:当前允许的最大Id,当有生成Id请求时,首先判断 nextId > maxId,若条件成立,则重新执行2中的步骤从ids表中读取并更新value,然后将value赋值给nextId,将maxId赋值为value+99,将nextId加
方案二
Twitter-Snowflake 64位自增id算法
消息堆积怎么解决
增加消费者 扩容
rocketMQ 和 kafka 的区别
以及其他技术选型
下单过程怎么性能优化
如何保证缓存和DB 的一致性
dubbo安全机制以及如何序列化
线程池拒绝策略以及自定义拒绝策略
zookpeer 测试和生产用一个的话 可以通过group区分不同的根节点
拦截器 过滤器 还有 aop的区别
@Autowired 与@Resource的区别(详细)
hashMap 和 arraylist 扩容
redis集群的三种方式以及原理
垃圾收集器 和垃圾回收算法
线上内存溢出有几种分别是怎么处理的
ConcurrentHashMap源码
runable 和callable的区别