快手一面0522

1.使用redis缓存设计主要解决的问题（缓存击穿、穿透、雪崩，布隆过滤器、逻辑过期）

2.四次挥手的过程

3.为什么第二次和第三次挥手不能合并

4.synchronized关键字的底层原理

5.synchronized关键字锁升级的机制

6.threadlocal的应用场景和底层原理

7.threadlocal的作用为什么不能用static关键字替代

8.线程和进程的区别

9.线程间同步和通信的方式

10.数据库主从同步的原理，binlog是如何实现主从同步的

binlog是MySQL数据库的一种日志文件，可以记录数据库操作的详细情况，包括数据库的增删改操作。主从复制是MySQL的一种高可用架构模式，其中一个MySQL实例作为主服务器（Master），其余的服务器作为从服务器（Slave），从服务器复制主服务器的更新操作，从而实现数据的同步。

在主从同步中，主服务器会记录所有对数据库的操作，并将这些操作以binlog的形式保存在文件中。当从服务器需要同步主服务器的数据时，它会连接到主服务器并请求 binlog 文件的最新更新。主服务器会将binlog文件的内容发送给从服务器，并按顺序执行binlog中所包含的每一个更新操作，以保证数据的完全一致。

从服务器在执行binlog中的操作时，会将每一条操作记录到自己的中继日志（relay log）中。这样，即使主服务器出现故障，从服务器也能够从中继日志中获取未同步的更新操作，从而保证数据的完整性和一致性。

总的来说，binlog为MySQL提供了完备而可靠的主从同步机制，可以保证数据的可靠性和完备性，同时为高可用架构提供了一种简单而有效的数据同步方式。

在 MySQL 数据库中，binlog 是一种二进制日志文件，用来记录所有的数据库变更操作，包括 INSERT、UPDATE、DELETE 等语句以及数据定义语句（如 ALTER TABLE 等）。当 MySQL 执行一条 SQL 语句时，它会将这条语句的操作记录在当前正在活动的 binlog 文件中，并在将来回放这些操作以实现基于时间点的数据恢复。

binlog 文件中的内容就是由操作语句和对应数据构成的，其主要包括以下字段：

- timestamp：操作时间戳
- server_id：服务器 ID
- event_type：事件类型，比如 Query、Xid、Table_map 等
- thread_id：执行 SQL 语句的线程 ID
- schema_name：数据库名称
- table_name：表名
- column_count：涉及到操作的列数量
- data：操作数据

其中，data 字段是最重要的字段，它包含了操作语句中受影响的行以及其对应的数据值。在 binlog 文件中，每行记录都是由一条完整的 SQL 语句构成的，这些 SQL 语句被序列化之后以二进制的形式存储在 binlog 文件中。

在主从同步中，当从服务器连接到主服务器并请求 binlog 文件的最新更新时，主服务器会将 binlog 文件的内容发送给从服务器，并按顺序执行 binlog 中所包含的每一个更新操作。因此，binlog 文件中记录的数据就成为了主服务器与从服务器之间数据同步的基础。

11.redolog怎么保持事务的持久性

Redo Log 日志是 InnoDB 存储引擎用来确保事务的持久性的一个重要组件。其主要作用是记录数据库中每个“页”的所有变化情况。当事务提交时，InnoDB 将 Redo Log 日志持久化到磁盘上，并将这些变化应用到数据库中，从而确保在数据库崩溃后也能够将所有已提交的事务重做以使数据恢复到一致的状态。

具体来说，对于 InnoDB 存储引擎来说，它是通过以下步骤来保持事务的持久性的：

1. 当执行事务更新操作时，在内存中记录下该操作对应的 Redo Log 日志，也就是物理日志。

2. 在写入 Redo Log 日志之后，InnoDB 不会立即将更新操作刷新到磁盘上对应的数据页中，而是将所有的更新操作都记录在内存中的页缓冲池中，也就是逻辑日志。

3. 当事务提交时，InnoDB 会将 Redo Log 日志持久化到磁盘上，从而确保即使发生系统崩溃，也能够在恢复时将已经提交的事务重做。

4. 同时，InnoDB 将事务修改的最新数据刷新到磁盘上对应的数据页中，在此过程中，InnoDB 会先将 Redo Log 中未被刷新到数据页中的记录应用到数据页中，然后将数据页刷新到磁盘，以保证数据的持久性。

由于 Redo Log 日志的物理和逻辑日志都被存储在内存中，并且具有异步写入磁盘的特点，所以 InnoDB 存储引擎能够在保证数据的可靠性的同时，保证数据库系统的性能表现。同时，Redo Log 日志的存储策略也使得 InnoDB 存储引擎能够应对大量的并发数据修改，从而具有良好的扩展性。

12.redolog页修改之后为什么不能直接刷盘

Redo Log 是 InnoDB 存储引擎的一个核心组件，用于确保事务的持久性。当 InnoDB 执行事务更新操作时，它会先在 Redo Log 中记录更新操作（也就是物理日志），然后再将这些更新操作应用到磁盘上的数据页中（也就是逻辑日志），通过这种方式确保了即使在系统崩溃的情况下，通过恢复 Redo Log 就可以将所有未完成的事务更新操作重新应用到数据页中。

Redo Log 的写入和刷盘是一个异步的过程，数据页的更新过程如下：

1. 当 InnoDB 执行事务操作时，会先将事务的 Redo Log 记录在内存中的 Redo Log 缓冲区中。

2. 当 Redo Log 缓冲区满或者事务提交时，InnoDB 将 Redo Log 缓冲区中的记录刷入磁盘的 Redo Log 文件中。这个过程是异步进行的，因此如果系统崩溃，仍然存在尚未刷盘的更新操作。

3. 当数据页需要更新时，InnoDB 会先将 Redo Log 文件中与该更新操作相关的记录加载到 Redo Log 缓冲区中，然后再通过逻辑日志将更新应用到磁盘上的数据页中。

由于 Redo Log 的写入和刷盘是异步进行的，因此在数据页修改完后不能直接刷盘，需要等待 Redo Log 缓冲区的更新记录持久化到磁盘的 Redo Log 文件中后才可以进行刷盘。否则如果系统发生崩溃，由于尚未持久化的 Redo Log 记录会丢失，数据的一致性就无法得到保障。因此，InnoDB 会通过限制 Redo Log 缓冲区的大小避免因 Redo Log 缓冲区无法容纳更多记录而导致数据页修改后不能直接刷盘的情况。

11.手写实现ArrayList