2020年社招面经与问题总结（二）

说下本人现在的基本情况，毕业一年，双非本科，之前是项目外包，坐标上海，目标中大型互联网公司

知乎

一面：

Eureka底层原理、单点登录授权码模式、如何实现HTTP长连接、现在项目的CI/CD流程、NIO和BIO的区别、JVM运行时数据区、JVM垃圾回收器、内存泄露和内存溢出的区别、synchronized和Lock对比、synchronized底层实现、synchronized锁升级过程、ReentrantLock公平锁实现、创建线程的几种方式、线程状态转换、多线程执行任务同步获取结果有哪几种方式、线程池7个参数、线程池底层原理、使用Executors创建线程池的问题（无界队列）、二叉树中序遍历（递归和栈两种实现，面试的时候递归的写出来了，但是栈的实现忘记了，算法的时间复杂度）

二面：

两数之和、三数之和

知乎一面之后技术问题就相对少了

1、内存泄露和内存溢出的区别

内存溢出：指程序在申请内存时，没有足够的内存空间供其使用，出现Out Of Memory

内存泄露：指程序在申请内存后，无法释放已经申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后的结果很严重，无论多少内存，迟早会被占光。即为不再会被使用的对象的内存不能被回收就是内存泄露

2、synchronized和ReentrantLock对比

synchronized是JVM层实现的锁，可以修饰实例方法（当前实例加锁）、静态方法（当前类对象加锁）、代码块（加锁对象），不需要手动加锁解锁

ReentrantLock是Java代码层面实现的，底层实现采用的是AQS，需要调用lock()和unlock()（在finally中释放锁）两个方法手工加锁解锁，ReentrantLock提供了很多实用的方法，比如设置获取锁的时候设置超时时间，还支持公平锁的实现

从性能方面，JDK早期版本synchronized性能较差，在后续版本进行了较多改进，包括锁升级的优化，在低竞争场景中性能可能优于ReentrantLock

这个问题在面试的过程中可以展开问的点很多，比如synchronized底层实现、synchronized锁升级过程、ReentrantLock公平锁和非公平锁实现、AQS等等。所以面试之前一定要把相关的知识点过一遍，保证面试的时候问起来能把自己的理解说出来

3、ReentrantLock公平实现

ReentrantLock这个类有两个构造函数，一个是无参构造函数，一个是传入fair参数的构造函数。fair参数代表的是锁的公平策略，如果传入true就表示需要构造一个公平锁，反之则表示要构造一个非公平锁

		//根据公平策略参数创建锁
    public ReentrantLock(boolean fair) {
    
    
        sync = fair ? new FairSync() : new NonfairSync();
    }

    static final class FairSync extends Sync {
    
    
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
    
    
            acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
    
    
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
    
    
              	//判断该线程是否有前驱节点,如果没有使用CAS操作修改state
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
    
    
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
          	//判断持有锁的线程是否是当前线程(可重入锁)
            else if (current == getExclusiveOwnerThread()) {
    
    
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

FairSync重写的tryAcquire方法在代码(1)在设置CAS前调用了AQS的hasQueuedPredecessors方法，该方法是实现公平性的核心代码，当hasQueuedPredecessors方法返回false时才允许当前线程占用锁

    public final boolean hasQueuedPredecessors() {
    
    
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }

hasQueuedPredecessors方法主要是用来判断该线程是否有前驱节点，或者说判断当前节点是否需要排队。如果当前线程节点有前驱节点则返回true，否则如果当前AQS队列为空或者当前线程节点是AQS的第一个节点则返回false

其中如果h==t则说明当前队列为空，直接返回false；如果h!=t && s==null则说明有一个元素将要作为AQS的第一个节点入队列（enq函数的第一个元素入队列是两步操作：首先创建一个哨兵头节点，然后将第一个元素插入哨兵节点后面；在执行完代码(1)尚未执行代码(2)时或者在第一个元素入队列时执行完代码(3)尚未执行代码(4)时的状态即为h!=t && s==null），那么返回true，如果h != t && ((s = h.next) == null || s.thread != Thread.currentThread())则说明队列里面的第一个元素不是当前线程，那么返回true

    private Node enq(final Node node) {
    
    
        for (;;) {
    
    
            Node t = tail;
          	//初始化队列
            if (t == null) {
    
    
              	//(1)
                if (compareAndSetHead(new Node()))
                  	//(2)
                    tail = head;
            } 
          	//元素入队
          	else {
    
    
                node.prev = t;
              	//(3)
                if (compareAndSetTail(t, node)) {
    
    
                  	//(4)
                    t.next = node;
                    return t;
                }
            }
        }
    }

这里可以对比之前的博客关于ReentrantLock非公平锁实现的讲解：https://blog.csdn.net/qq_40378034/article/details/108186842

4、线程状态转换

Java线程6种状态：

    public enum State {
    
    
        //初始化状态
        NEW,

        //可运行/运行状态
        RUNNABLE,

        //阻塞状态
        BLOCKED,

        //等待
        WAITING,

        //超时等待
        TIMED_WAITING,

        //终止状态
        TERMINATED;
    }

在这里插入图片描述

其实在操作系统层面，Java线程中的BLOCKED、WAITING、TIMED_WAITING是一种状态，即休眠状态。也就是说只要Java线程处于这三种状态之一，那么这个线程就永远没有CPU的使用权

1）、从NEW到RUNNABLE状态

Java刚创建出来的Thread对象就是NEW状态，NEW状态的线程不会被操作系统调度，因此不会执行。调用线程对象的start()方法从NEW状态转换到RUNNABLE状态

2）、RUNNABLE与BLOCKED状态的转换

等待synchronized隐式锁的线程从RUNNABLE状态转换为BLOCKED状态，而当等待的线程获得synchronized隐式锁时，就又会从BLOCKED转换到RUNNABLE状态

3）、RUNNABLE与WAITING状态的转换

有3种场景会触发这种转换：

获得 synchronized 隐式锁的线程，调用无参数的Object.wait()方法
调用无参数的Thread.join()方法
调用LockSupport.park()方法

4）、RUNNABLE与TIMED_WAITING状态的转换

有5种场景会触发这种转换：

调用带超时参数的Thread.sleep(long millis)方法
获得synchronized隐式锁的线程，调用带超时参数的Object.wait(long timeout)方法
调用带超时参数的Thread.join(long millis)方法
调用带超时参数的LockSupport.parkNanos(Object blocker, long deadline)方法
调用带超时参数的LockSupport.parkUntil(long deadline)方法

5）、从RUNNABLE到TERMINATED状态

线程执行完run()方法后，会自动转换到TERMINATED状态，当然如果执行run()方法的时候异常抛出，也会导致线程终止

Thread的interrupt()方法：

当线程A处于WAITING、TIMED_WAITING状态时，如果其他线程调用线程A的interrupt()方法，会使线程A返回到RUNNABLE状态，同时线程A的代码会触发InterruptedException异常

如果线程处于RUNNABLE状态，这时就得依赖线程A主动检测中断状态了。如果其他线程调用线程A的interrupt()方法，那么线程A可以通过isInterrupted()方法，检测是不是自己被中断了

参考：

https://time.geekbang.org/column/article/86366

5、多线程执行任务同步获取结果有哪几种方式

1）、CountDownLatch

CountDownLatch主要用来解决一个线程等待多个线程的场景

        CountDownLatch countDownLatch = new CountDownLatch(2);
        ExecutorService executorService = Executors.newFixedThreadPool(2);
        executorService.execute(() -> {
    
    
            try {
    
    
                TimeUnit.SECONDS.sleep(1);
                System.out.println("child threadOne over");
            } catch (InterruptedException e) {
    
    
                e.printStackTrace();
            } finally {
    
    
                countDownLatch.countDown();
            }
        });

        executorService.execute(() -> {
    
    
            try {
    
    
                TimeUnit.SECONDS.sleep(1);
                System.out.println("child threadTwo over");
            } catch (InterruptedException e) {
    
    
                e.printStackTrace();
            } finally {
    
    
                countDownLatch.countDown();
            }
        });

        System.out.println("wait all child thread over");
        countDownLatch.await();
        System.out.println("all child thread over");
        executorService.shutdown();

2）、`ExecutorService.submit()`

    public void demo() throws InterruptedException, ExecutionException {
    
    
        //要执行的任务
        List<Task> taskList = new ArrayList<>();
        for (int i = 0; i < 10; ++i) {
    
    
            taskList.add(new Task());
        }

        ExecutorService executorService = Executors.newFixedThreadPool(5);

        List<Future<String>> resultList = new ArrayList<>();
        //提交任务
        for (Task task : taskList) {
    
    
            resultList.add(executorService.submit(task));
        }

        //处理任务返回数据
        for (Future<String> result : resultList) {
    
    
            System.out.println("result:" + result.get());
        }
        System.out.println("task done!");
        executorService.shutdown();
    }

    class Task implements Callable<String> {
    
    

        @Override
        public String call() throws Exception {
    
    
            TimeUnit.SECONDS.sleep(new Random().nextInt(5));
            return Thread.currentThread().getName();
        }
    }

3）、CompletionService和ExecutorCompletionService

ExecutorCompletionService类是CompletionService接口的实现，它的内部内部维护列一个用于管理已完成的任务的队列，引用了一个Executor用来执行任务，submit()方法最终会委托给内部的Executor去执行任务，take()/poll()方法的工作都委托给内部的已完成任务阻塞队列，也就是说使用ExecutorCompletionService在处理任务返回结果的时候可以优先获取到已经完成任务的结果进行处理，所以使用这种方式相比于其他两种方式更好

    public void demo() throws InterruptedException, ExecutionException {
    
    
        //要执行的任务
        List<Task> taskList = new ArrayList<>();
        for (int i = 0; i < 10; ++i) {
    
    
            taskList.add(new Task());
        }

        ExecutorService executorService = Executors.newFixedThreadPool(5);
        ExecutorCompletionService<String> completionService = new ExecutorCompletionService<>(executorService);

        int n = taskList.size();
        //提交任务
        for (Task task : taskList) {
    
    
            completionService.submit(task);
        }
      
        //处理任务返回数据
        for (int i = 0; i < n; ++i) {
    
    
            Future<String> resultHolder = completionService.take();
            System.out.println("result:" + resultHolder.get());
        }
        System.out.println("task done!");
        executorService.shutdown();
    }

    class Task implements Callable<String> {
    
    

        @Override
        public String call() throws Exception {
    
    
            TimeUnit.SECONDS.sleep(new Random().nextInt(5));
            return Thread.currentThread().getName();
        }
    }

6、二叉树的中序遍历

两种实现时间复杂度均为 $O (n)$

1）、递归

    public List<Integer> inorderTraversal(TreeNode root) {
    
    
        List<Integer> result = new ArrayList<>();
        helper(root, result);
        return result;
    }

    private void helper(TreeNode root, List<Integer> result) {
    
    
        if (root == null) {
    
    
            return;
        }
        helper(root.left, result);
        result.add(root.val);
        helper(root.right, result);
    }

2）、基于栈

    public List<Integer> inorderTraversal(TreeNode root) {
    
    
        List<Integer> result = new ArrayList<>();
        LinkedList<TreeNode> stack = new LinkedList<>();
        TreeNode current = root;
        while (current != null || !stack.isEmpty()) {
    
    
            if (current != null) {
    
    
                stack.add(current);
                current = current.left;
            } else {
    
    
                current = stack.pollLast();
                result.add(current.val);
                current = current.right;
            }
        }
        return result;
    }

宇石网络

一面：

SpringBoot自动装配原理、Eureka底层原理、Eureka自我保护机制、如何确保消息不丢失、如何解决重复消费的问题、缓存雪崩和缓存穿透的解决方案、Redis分布式锁、线上OOM问题怎么排查、ReentrantLock非公平实现、AQS

二面：

SpringBoot自动装配原理、SpringBoot怎么启动Tomcat的、对象何时进入老年代、内存空间分配担保、垃圾回收器CMS和G1、MySQL索引原理、MySQL事务特性、MySQL事务隔离级别、可重复读是怎么实现的（undo log）、MySQL redo log binlog undo log的区别、Redis内存回收策略、Redis分布式锁实现、Redis集群模式、Docker有哪些组成、Docker常用命令、K8S是用来做什么的

消息队列相关问题：

例如确保消息可靠性、处理消费过程中的重复消息、处理消息积压等，由于这次没有复习消息队列相关的内容，后续准备学一下RocketMQ在进行回顾，可以先看下之前的博客：https://blog.csdn.net/qq_40378034/article/details/98790433

1、SpringBoot自动装配原理

从@SpringBootApplication入手

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = {
    
     @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
    
    

	@AliasFor(annotation = EnableAutoConfiguration.class)
	Class<?>[] exclude() default {
    
    };

	@AliasFor(annotation = EnableAutoConfiguration.class)
	String[] excludeName() default {
    
    };

	@AliasFor(annotation = ComponentScan.class, attribute = "basePackages")
	String[] scanBasePackages() default {
    
    };

	@AliasFor(annotation = ComponentScan.class, attribute = "basePackageClasses")
	Class<?>[] scanBasePackageClasses() default {
    
    };

	@AliasFor(annotation = ComponentScan.class, attribute = "nameGenerator")
	Class<? extends BeanNameGenerator> nameGenerator() default BeanNameGenerator.class;

	@AliasFor(annotation = Configuration.class)
	boolean proxyBeanMethods() default true;

}

@EnableAutoConfiguration代表开启SpringBoot自动装配

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
    
    

	String ENABLED_OVERRIDE_PROPERTY = "spring.boot.enableautoconfiguration";

  //按类型排除不需要自动装配的类
	Class<?>[] exclude() default {
    
    };
	
  //按名称排除不需要自动装配的类
	String[] excludeName() default {
    
    };

}

EnableAutoConfiguration中最关键的是@Import(AutoConfigurationImportSelector.class) ，借助EnableAutoConfigurationImportSelector，@EnableAutoConfiguration可以帮助SpringBoot应用将所有符合条件的@Configuration配置都加载到IOC容器中

public class AutoConfigurationImportSelector implements DeferredImportSelector, BeanClassLoaderAware,
		ResourceLoaderAware, BeanFactoryAware, EnvironmentAware, Ordered {
    
    

	private static final AutoConfigurationEntry EMPTY_ENTRY = new AutoConfigurationEntry();

	private static final String[] NO_IMPORTS = {
    
    };

	private static final Log logger = LogFactory.getLog(AutoConfigurationImportSelector.class);

	private static final String PROPERTY_NAME_AUTOCONFIGURE_EXCLUDE = "spring.autoconfigure.exclude";

	private ConfigurableListableBeanFactory beanFactory;

	private Environment environment;

	private ClassLoader beanClassLoader;

	private ResourceLoader resourceLoader;

	private ConfigurationClassFilter configurationClassFilter;

	@Override
	public String[] selectImports(AnnotationMetadata annotationMetadata) {
    
    
		if (!isEnabled(annotationMetadata)) {
    
    
			return NO_IMPORTS;
		}
		AutoConfigurationEntry autoConfigurationEntry = getAutoConfigurationEntry(annotationMetadata);
		return StringUtils.toStringArray(autoConfigurationEntry.getConfigurations());
	}
      
	protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
    
    
		if (!isEnabled(annotationMetadata)) {
    
    
			return EMPTY_ENTRY;
		}
    //获取@EnableAutoConfiguration注解的属性及其值
		AnnotationAttributes attributes = getAttributes(annotationMetadata);
    //在classpath下META-INF/spring.factories文件中查找org.springframework.boot.autoconfigure.EnableAutoConfiguration的值,并将其封装到一个List中返回
		List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
    //对上一步返回的List中的元素去重、排序
		configurations = removeDuplicates(configurations);
    //依据@EnableAutoConfiguration注解中获取的属性值排除一些特定的类
		Set<String> exclusions = getExclusions(annotationMetadata, attributes);
		checkExcludedClasses(configurations, exclusions);
		configurations.removeAll(exclusions);
		configurations = getConfigurationClassFilter().filter(configurations);
		fireAutoConfigurationImportEvents(configurations, exclusions);
		return new AutoConfigurationEntry(configurations, exclusions);
	}

@EnableAutoConfiguration作用就是从classpath中搜寻所有的META-INF/spring.factories配置文件，并将其中org.springframework.boot.autoconfigure.EnableutoConfiguration对应的配置项通过反射实例化为对应的标注了@Configuration的JavaConfig形式的IoC容器配置类，然后汇总为一个并加载到IOC容器。这些功能配置类要生效的话，会去classpath中找是否有该类的依赖类（也就是pom.xml必须有对应功能的jar包才行）并且配置类里面注入了默认属性值类，功能类可以引用并赋默认值。生成功能类的原则是自定义优先，没有自定义时才会使用自动装配类

在这里插入图片描述

所以功能类能生效需要的条件：

spring.factories里面有这个类的配置类
pom.xml里面需要有对应的jar包

参考：

https://www.jianshu.com/p/88eafeb3f351

https://www.jianshu.com/p/5cb57be5d0ea

2、Eureka自我保护机制

Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制

# 关闭保护机制,以确保注册中心可以将不用的实例正确剔除
eureka.server.enable-self-preservation=false

3、缓存雪崩、缓存击穿、缓存穿透

1）、缓存雪崩

缓存雪崩是指缓存集中在一段时间内失效，所有的查询都落在数据库上，对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机

解决方案：

1）加锁排队

mutex互斥锁解决，Redis的SETNX去set一个mutex key，当操作返回成功时，再进行加载数据库的操作并回设缓存，否则，就重试整个get缓存的方法

2）数据预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户直接查询事先被预热的缓存数据。可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key

3）双层缓存策略

C1为原始缓存，C2为拷贝缓存，C1失效时，可以访问C2，C1缓存失效时间设置为短期，C2设置为长期

4）定时更新缓存策略

实效性要求不高的缓存，容器启动初始化加载，采用定时任务更新或移除缓存

5）设置不同的过期时间，让缓存失效的时间点尽量均匀

2）、缓存击穿

缓存击穿是指大量的请求同时查询一个key时，此时这个key正好失效了，就会导致大量的请求都打到数据库上面去，造成某一时刻数据库请求量过大，压力剧增

解决方案：

上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存

3）、缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到对应key的value，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库

解决方案：

1）缓存空值

如果一个查询返回的数据为空（不管是数据不存在，还是系统故障）我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过5分钟。通过这个设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库

2）采用布隆过滤器BloomFilter

优势：占用内存空间很小，位存储；性能特别高，使用key的hash判断key存不存在

将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力

在缓存之前在加一层BloomFilter，在查询的时候先去BloomFilter去查询key是否存在，如果不存在就直接返回，存在再去查询缓存，缓存中没有再去查询数据库

4、MySQL redo log、binlog、undo log的区别

1）、redo log

在说redo log之前，我们先来看下MySQL缓冲池（Buffer Pool）

InnoDB存储引擎是基于磁盘存储的，而缓冲池是一块内存区域，通过内存的速度来弥补磁盘速度较慢对数据库性能的影响

在数据库中进行读取页的操作，首先将从磁盘读到的页存放在缓冲池中。下一次再读相同的页时，首先判断该页是否在缓冲池中。若在缓冲池中，称该页在缓冲池中被命中，直接读取该页。否则，读取磁盘上的页

对于数据库中页的修改操作，则首先修改在缓冲池中的页，然后再以一定的频率刷新到磁盘上。页从缓冲池刷新回磁盘的操作并不是在每次页发生更新时触发，而是通过一种称为Checkpoint的机制刷新回磁盘

MySQL里常说的WAL技术，全称是Write Ahead Log，即当事务提交时，先写redo log，再修改页。也就是说，当有一条记录需要更新的时候，InnoDB会先把记录写到redo log里面，并更新Buffer Pool的page，这个时候更新操作就算完成了

InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，循环使用，从头开始写，写到末尾就又回到开头循环写（顺序写，节省了随机写磁盘的IO消耗）

redo log中的Write Pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。Check Point是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件

Write Pos和Check Point之间空着的部分，可以用来记录新的操作。如果Write Pos追上Check Point，这时候不能再执行新的更新，需要停下来擦掉一些记录，把Check Point推进一下

当数据库发生宕机时，数据库不需要重做所有的日志，因为Check Point之前的页都已经刷新回磁盘，只需对Check Point后的redo log进行恢复，从而缩短了恢复的时间

当缓冲池不够用时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Check Point，将脏页刷新回磁盘

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失

redo log buffer：

在一个事务的更新过程中，日志是要写多次的。比如下面这个事务：

begin;
insert into t1 ...
insert into t2 ...
commit;

这个事务要往两个表中插入记录，插入数据的过程中，生成的日志都得先保存起来，但又不能在还没commit的时候就直接写到redo log文件里。所以，redo log buffer就是一块内存，用来先存redo日志的。也就是说，在执行第一个insert的时候，数据的内存被修改了，redo log buffer也写入了日志。但是，真正把日志写到redo log文件，是在执行commit语句的时候做的。单独执行一个更新语句的时候，InnoDB会自己启动一个事务，在语句执行完成的时候提交。过程跟上面是一样的，只不过是压缩到了一个语句里面完成

2）、binlog

binlog记录了对MySQL数据库执行更改的所有操作，不包括SELECT和SHOW这类操作，主要作用是用于数据库的主从复制及数据的增量恢复

redo log和binlog的不同：

1）redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用

2）redo log是物理日志，记录的是在某个数据也上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1

3）redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志

3）、undo log

InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的

而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它

也就是说，数据表中的一行记录，其实可能有多个版本（row），每个版本有自己的row trx_id

在这里插入图片描述

图中虚线框里是同一行数据的4个版本，当前最新版本是V4，k的值是22，它是被transaction id为25的事务更新的，因此它的row trx_id也是25

图2中的三个虚线箭头，就是undo log；而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来

5、Redis内存回收策略

当Redis内存使用达到maxmemory上限时触发内存溢出控制策略，具体策略受maxmemory-policy参数控制，Redis支持6种策略

noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，删除存活时间最短的key。如果没有对应的键，则回退到noeviction策略