字节（2023-5-15）

zset的结构

zset（有序集合）是Redis中的一种有序数据结构，它与set相同，保证元素的唯一性，但它的每个元素都附带了一个分值（score），用于排序。

在Redis的实现中，zset数据结构会使用两个内部数据结构实现，一个是基于跳跃表（skiplist）的实现，另一个是基于哈希表的实现。

跳跃表充当有序集合的主体，保证集合中元素的有序性。它由多层节点组成，在每一级上使用跳跃指针降低全局复杂度，从而在理论上等价于红黑树，但是相比于红黑树，跳跃表在插入和删除元素时有更好的性能表现。

哈希表则用于记录元素和元素分值的对应关系，它将元素和分值存储在同一个哈希表节点中，以便于快速查询和修改指定元素的分值。这样，有序集合中的元素就可以通过其分值进行排序，但元素本身也可以根据自身的属性进行查询和修改。

有序集合的实现可以使得Redis可以高效地处理类似排名、前K个等排序相关的问题，被广泛应用于榜单排名等场景。

分布式锁实现方式

分布式锁是一种用于保护多个进程或线程访问共享资源的机制。在分布式系统中，常见的实现方式有以下三种：

基于数据库：使用数据库的事务机制来实现分布式锁。可以将共享资源的状态存储在数据库中，控制锁的获取和释放操作。
基于第三方中间件：使用像Zookeeper、Redis等第三方中间件服务来实现分布式锁。这些服务提供了分布式锁功能的API，具有高效和可靠的特性。
基于时间戳：使用时间戳来实现分布式锁。每个进程在获取锁时先记录当前时间，将当前时间+锁持有时间的值存储到共享资源中，并比较该值与当前时间的大小关系，以判断锁是否被其他进程持有。如果锁已在被占用，则等待一段时间后重试。这种方式实现简单，但不够精确和可靠。

以上三种实现方式，每种方式都有其优缺点，根据实际情况选择合适的方式。

分布式锁造成的阻塞问题

分布式锁是通过在多个进程间协调资源访问的一种技术，但是它有可能导致进程阻塞问题，尤其是在高并发场景。当一个进程获取了分布式锁后，其他进程会不断尝试获取锁，这时候如果锁一直被占用，其他进程就会一直阻塞，无法继续执行下去。

为了解决这个问题，可以考虑在分布式锁的设计中引入超时机制。具体来说，如果一个进程尝试获取锁的时间超过设定的超时时间，就自动放弃获取锁，可以根据具体场景采用不同的处理方式，例如重试、返回失败等。同时，为了避免由于网络延迟等原因导致获取锁时出现长时间等待的情况，可以采用异步非阻塞的方式获取锁，这样即使锁一直被占用，进程也可以继续执行其他任务，不会被长时间阻塞。

另外，还可以考虑使用基于Redis等内存数据库的分布式锁，这种锁是基于内存的，具有高效、可靠的特点，同时也支持超时机制和异步非阻塞获取锁。

缓存雪崩解决方案

设置不同的随机的过期时间
多级缓存

mysql索引设计

where a = x and b = y
where a = x and c = z and b = y

对于第一条SQL语句"where a = x and b = y"，可以添加一个复合索引(a, b)，这样查询时可以先根据a的值定位到对应的行，然后再根据b的值进行过滤。

对于第二条SQL语句"where a = x and c = z and b = y"，可以添加一个复合索引(a, b, c)，这样查询时可以先根据a的值定位到对应的行，然后再根据b和c的值进行过滤。这个索引也可以满足第一条SQL语句的查询需求，因为它包含了第一条SQL语句所需要的两个列(a、b)。同时，这个索引也可以更高效地完成第二条SQL语句的查询需求。

HTTPS证书交换过程

HTTPS证书交换过程主要包括以下步骤：

客户端向服务器发起HTTPS请求。
服务器将自己的公钥以数字证书的形式发送给客户端。
客户端接收到数字证书后，会对证书的真实性进行校验，如果校验通过，则说明服务器的公钥可以信任。
客户端生成一个随机值，并使用服务器的公钥进行加密，然后将加密后的随机值发送给服务器。
服务器使用自己的私钥进行解密，得到了客户端的随机值。
服务器和客户端都使用这个随机值来生成对称密钥，用于后续的通信加密。

这样一来，HTTPS的证书交换过程就完成了。在此之后，客户端和服务器都使用对称密钥进行加密通信，保证数据的安全性和机密性。

百度（2023-5-16）

MySQL如何分库分表，之后如何进行关联

MySQL的分库分表是一种常用的分布式数据库架构设计方案，它将大数据量的表拆分成较小的表来分散数据，提高数据库性能和扩展性。

MySQL分库分表的主要实现方式有两种：

垂直分表：通过将单张表的列进行分离，将不必要的列放在一个表中，将常用的或关联紧密的列分到另外一个表中，实现大表的分割。
水平分表：将一张大表分成某些基于列的小表，以此来缩小单个表的规模。

在MySQL中，分库分表后，需要使用关联查询来实现跨表查询。常用的关联方式有三种：

内连接（Inner Join）

内连接可以将两个或多个表中的记录联合在一起，通过匹配相应列中的值，返回完全匹配的记录。内连接会将匹配的记录返回，而不会返回不匹配的记录。

左连接（Left Join）

左连接返回左表中所有的记录，以及匹配的右表中的记录。

右连接（Right Join）

右连接返回右表中所有的记录，以及匹配的左表中的记录。

例如：

SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.id;

这条查询语句可以将table1和table2表中id相同的记录联合在一起返回。

MySQL读写可能遇到什么问题

MySQL读写可能会遇到以下问题：

数据库连接问题：连接数据库时可能会出现连接失败的问题，例如连接超时或无法连接到数据库服务器等。这可能是由于网络问题、数据库服务器故障或其他配置问题造成的。
并发问题：如果多个客户端同时向数据库发送读写请求，可能会导致并发问题，例如读取了过时的数据或写入了不一致的数据。为了解决这种问题，通常需要通过锁定机制或事务来保证数据的一致性。
慢查询问题：查询过于复杂或表中数据量过大可能导致查询速度变慢，用户需要优化查询语句或增加索引来提高查询效率。
数据库性能问题：如果数据库服务器负载过高，可能会导致响应时间变慢或无法响应。这可能是由于硬件问题、配置问题或查询优化不当等原因造成的。
数据库容量问题：如果数据库中存储的数据太多，可能会导致数据库的容量不足，这时需要对数据库进行清理或增加存储容量。

综上所述，MySQL读写可能会遇到一系列问题，需要通过维护数据库健康、优化查询、加强安全策略等方式来提高数据库的性能和稳定性。

缓存穿透中的布隆过滤器实现步骤

缓存穿透是指缓存和数据库中都没有的数据，在高并发的情况下，可能会打到数据库中，导致数据库压力过大甚至崩溃。为了解决这个问题，可以使用布隆过滤器实现缓存穿透的防范。

下面是使用布隆过滤器实现缓存穿透的大致步骤：

首先需要引入布隆过滤器的库，比如Java中的Google Guava库或者Java Bloom Filter库。
创建布隆过滤器实例，并指定预期元素数量和期望的误判率。
把数据库中的存在的数据的一些特征（比如ID）加入到布隆过滤器中。
当请求到来时，先进行布隆过滤器判定，如果判定不存在，则直接返回不需要访问数据库；如果存在，则再去查询缓存或数据库，如果缓存或数据库中都没有，则返回不存在。
如果布隆过滤器判定不存在，但实际上数据确实存在，此时需要加入“缓存穿透保护”机制，将查询结果写入缓存，或者加入一些特殊标识符，比如-1，表示这个不存在的数据已经查询过了，下一次再查询时就直接返回-1，而不再回源数据库。这样可以防止缓存穿透。

需要注意的是，布隆过滤器会有一定的误判率，也就是会把不存在的数据误判成存在的，因此布隆过滤器只能用于缓存穿透的防范，而不能完全代替缓存和数据库的存在判定。同时，布隆过滤器的大小可以通过预期元素数量和期望的误判率来调整，需要根据实际情况进行适当的调整。

redis崩了的场景更像缓存雪崩还是缓存穿透

Redis崩溃可能涉及到多种原因，因此可能很难简单地归类为缓存雪崩或缓存穿透。

如果 Redis 是作为一个缓存层，在缓存失效的时候，大量请求涌入 Redis 导致 Redis 压力过大崩溃，那么这种情况可能更像是缓存雪崩。

如果 Redis 的 key 存在但是 value 为 null 或者 Redis 中不存在请求的 key，导致每次请求都会打到数据库，从而导致数据库过载或者宕机，那么这种情况可能更像是缓存穿透。

但需要指出的是，Redis崩溃的原因可能并不仅限于这两种情况，而且可能是多种因素的结果，因此针对具体的场景，需要进一步分析才能判断引起 Redis 崩溃的确切原因。

读写分离解决了多线程什么问题

读写分离可以解决多线程并发读写操作所带来的一些问题。

在多线程环境下，如果多个线程同时对同一份数据进行读写，就会出现读数据不一致或写数据被覆盖的情况，这样就会破坏数据的完整性和准确性。

而采用读写分离的策略可以避免这些问题，因为读写分离将读和写的操作分别放到不同的数据库服务器上，从而避免了并发读写冲突的情况。

换句话说，多个线程可以同时读取数据，但只有一个线程可以进行写操作。这种方式可以提高数据的读取效率，并且也可以减少写操作对系统的影响。

读写分离场景可以使用乐观锁来保持数据一致性吗？如果不可以，那么需要采用什么方法

乐观锁是一种并发控制机制，它通过在数据上加标记来防止数据竞争和脏读的发生。在读写分离场景下，乐观锁可以用来保证不同数据库实例之间读取数据的一致性，但并不一定能够完全避免数据一致性问题的出现。

具体来说，读写分离场景下通常使用的是主从复制，主库用来写入数据，从库用来读取数据。当主库写入数据之后，需要将这些数据同步到各个从库上，由于同步时间的存在，不同从库之间读取的数据可能存在较小的时间差异。如果此时使用乐观锁，可能会出现数据一致性问题，因为前一个事务的修改可能还没有同步到其他从库上，而后续事务中读取到的数据可能来自于已经同步到其他从库上的数据。

因此，在读写分离场景下，除了乐观锁以外，还需要采用其他机制来保证数据的一致性，例如：

同步等待机制：在从库读取数据时，需要等待主库同步完毕后才返回数据，防止读取到不一致的数据。
分布式锁机制：在写入数据时，可以使用分布式锁来确保只有一个进程可以修改数据，避免数据竞争。
数据同步策略优化：可以对数据同步策略进行优化，例如采用异步复制策略，尽量缩短主从库之间的同步时间，减少数据不一致性的可能性。

综上所述，读写分离场景下不能只依靠乐观锁来保证数据的一致性，需要结合其他机制来综合实现数据的读写分离和一致性。

针对某个函数写测试用例

假设你要实现一个函数 find_in_array(target, array)，用于在一个数组中查找目标值是否存在，其中 target 是要查找的目标值，array 是输入的数组。

可能会导致函数崩溃的用例包括：

数组为空：如果输入一个空数组，函数可能没有判断数组的长度导致越界，从而导致崩溃。
目标值不存在：如果目标值在数组中不存在，那么在查找该值时，可能会访问数组中不存在的索引导致越界，从而导致崩溃。
目标值为非数值类型：如果目标值不是数值类型，如字符串、布尔值等，那么函数可能无法正确处理该值，从而导致崩溃。
数组元素为非数值类型：如果数组中存在非数值类型的元素，如字符串、布尔值等，那么函数可能无法正确处理该元素，从而导致崩溃。
目标值或数组元素包含 NaN（非数值）：如果目标值或数组元素包含 NaN（非数值），那么函数可能无法正确处理，从而导致崩溃。

以上这些情况都需要在函数中进行正确处理，以避免函数崩溃。

百度（2023-5-18）

如何理解测试和开发之间的紧密联系

测试和开发之间有着非常紧密的联系，因为他们是软件开发生命周期中的两个关键环节。下面几个方面，解释了测试和开发之间的紧密联系：

沟通和协作：测试和开发团队需要密切合作，以确保软件的质量和稳定性。测试团队需要积极地向开发团队反馈项目中发现的缺陷和问题，而开发团队需要快速修复并测试代码。
迭代式开发：现代软件开发通常采用敏捷或迭代式方法，这意味着开发人员会尽早介入测试和反馈循环，以便及早识别和解决问题。测试团队需要持续测试新的代码并向开发团队反馈测试结论，以确保处于开发周期的代码一直处于高质量水平。
质量保证：测试和开发之间的紧密联系起到的重要作用是确保软件在质量和稳定性方面得到充分的保证。测试团队需要确保测试计划和测试用例的准确性和全面性，同时开发人员需要积极开发和修复项目中的缺陷。
自动化测试：自动化测试是测试和开发之间紧密联系的另一个重要方面。自动化测试可以帮助测试团队快速执行测试用例，而开发人员可以在其代码改变时运行自动化测试套件以确保不会引入新的错误。

总而言之，测试和开发之间的紧密联系可以确保软件在质量和稳定性方面获得充分的保障，并且可以在软件开发过程中提高团队的协作和效率，帮助企业达到更快速的上线和更新产品的目标。

什么场景下选择mysql，什么场景下选择redis

MySQL 和 Redis 都是常用的数据库系统，但它们在功能和使用场景上存在差异，因此可以根据不同的应用场景来选择使用。

MySQL：MySQl 是一种关系型数据库，常用于需要存储结构化数据的应用程序。MySQL 支持 ACID 事务，具有较好的数据一致性、数据完整性和数据可靠性。因此可以在需要进行复杂的数据处理，包括事务管理、多表联结、复杂查询、数据安全等方面的业务上使用 MySQL。
Redis：Redis 是一种基于内存的非关系型数据库，通常用于处理高并发、高性能的业务场景。Redis 支持多种数据结构，包括字符串、列表、集合、散列和有序集合等，这使得 Redis 可以高效地处理诸如缓存、会话管理、分布式锁、计数器等任务。因此可以在需要高并发性能、实时数据处理和数据快速查询等方面的业务上使用 Redis。

综上所述，MySQL 和 Redis 在不同的应用场景和功能上都有所特点，应根据实际业务需求来选择合适的数据库系统。如果需要处理结构化数据或进行复杂的事务管理，应该使用 MySQL；如果需要高并发性能，或者快速查询，就应该使用 Redis。在一些复杂的场景中，还可以结合使用两种数据库系统，来达到更好的数据处理效果。

为什么redis比较快

Redis 相比传统关系型数据库 (如 MySQL) 等的优势主要有以下几点:

基于内存: Redis 能够实现很高的读写性能的主要原因是它的数据存储基于内存，这意味着它可以快速处理数据并避免了在硬盘上进行读写操作的瓶颈。
单线程模型: Redis 是一种单线程的数据库，所以可以避免线程之间的锁竞争和上下文切换的开销。它使用基于事件驱动的 I/O 多路复用机制来实现高并发，所以能够快速响应大量的请求。
持久化支持: Redis 支持多种数据结构和多种持久化机制，包括 RDB、AOF 和混合模式等。这使得 Redis 在数据持久化方面更加灵活，并能够在发生数据丢失或重启后快速恢复。
数据结构丰富: Redis 支持多种数据结构，包括字符串、哈希表、列表、集合等，这些数据结构能够更好地满足不同的业务需求。

总的来说，Redis 的高性能和快速响应能力得益于它的基于内存、单线程和事件驱动的特点，同时它的多种持久化机制和丰富的数据结构也为开发人员提供了更大的灵活性。

什么场景会用到mysql的主从同步和读写分离

MySQL的主从同步和读写分离常用于以下场景：

高可用：主从同步可以提高系统的可用性，当主库发生故障时，可以快速切换到备库，保证系统的正常运行。
应用读写分离：将读操作与写操作分离，通过主库写入数据，再通过从库将数据读取出来，减轻主库读写压力，提高系统性能。
负载均衡：将读请求均衡地分配到多个从库上，通过增加从库的数量，使得系统能够处理更多的并发请求，提高系统的吞吐量。
数据库扩容：通过增加从库来扩展系统的容量，提高数据库的读写性能。

需要注意的是，使用主从同步和读写分离需要在系统架构设计和实现过程中进行充分考虑，必须进行详细的测试和验证，以确保系统的可靠性和数据一致性。

为什么读写操作同时进行会造成数据的不一致，读写分离并不能解决数据不一致问题

读写操作同时进行可能会导致数据不一致是因为，在MySQL数据库中，读操作和写操作使用的是不同的锁机制。在默认的情况下，MySQL的读操作使用的是共享锁（Shared Lock），可以让多个读操作并发地执行，不会造成数据的冲突。而写操作使用的是排他锁（Exclusive Lock），只能被一个写操作所持有，其他的写操作必须等待锁释放后才能执行。因此，如果写操作和读操作同时进行，可能会出现以下两种情况：

脏读（Dirty Read）：当一个事务对数据进行更新，但更新操作还没有提交时，其他事务读取到了没有提交的数据，造成数据的不一致。
不可重复读（Non-Repeatable Read）：当一个事务读取一个数据时，在这个事务未提交之前，另一个事务修改了这个数据，并提交了修改，那么在同一事务中，两次读取相同的数据可能会得到不同的结果。

读写分离的作用是减轻主库的压力，提高系统的性能，但并不能完全解决数据不一致的问题。如果需要保证数据的一致性，可以通过其他手段来解决，例如在应用程序中加入分布式锁，或者使用数据库的事务机制来保证数据的一致性。

加索引为什么能够提高查询速度，为什么排完序之后可以增加查询速度

索引可以提高查询速度的原因是因为索引可以加强数据的快速检索，通过对列进行索引，可以建立一种类似于目录的数据结构，以便快速定位到数据。如果没有索引，那么就必须对整个表进行扫描，查询时间将随着表的数据量的增加而增加，查询效率会大大降低。

当建立索引后，查询时可以利用索引进行快速定位到符合条件的行，从而大大缩短了数据查询的时间。

对于排序操作，排序通常是按照指定列的值进行排序的，如果通过这个列建立了索引，那么排序操作可以基于索引实现，使得排序操作更加高效。通过索引实现的排序不需要对整个表进行扫描，只需要对索引进行遍历即可，因此比传统的排序方法更加高效。

需要注意的是，建立索引和排序操作也会带来相应的开销，例如索引占用磁盘空间和对索引进行维护的开销以及排序操作需要占用CPU等资源，因此需要对建立索引和排序进行谨慎的考量，根据实际情况进行优化。

什么情况下需要分库分表？分库是什么？分表是什么？

当数据量变得越来越大时，一个单一的数据库系统可能无法满足数据处理和管理的需求，因此需要进行分库和分表来进行扩展。

分库指的是将一个大的数据库分成多个部分，分别存放在多个数据库实例中，每个子数据库有自己的独立存储结构和数据文件，每个数据库实例可独自工作。分库的优势在于可以通过不同的服务器并行处理多个子数据库，从而极大地提高数据库的处理能力和吞吐量。

分表指的是将一个大的数据表按照某种规则分成多个小的数据表，每个小表维护部分数据，但是整个大表的数据仍被管理在同一个数据库中。分表的好处在于 reduces lock contention 并且可以通过在不同的物理位置存储数据，以避免单表数据过大造成的问题，如索引长度限制、表维护复杂等，提高查询效率和管理效率。

通常情况下，当数据库的数据量变得很大时，就需要考虑进行分库、分表或两者结合的方式进行扩展。分库和分表的具体原则取决于实际需求，包括但不限于数据增长率、访问模式、查询效率、数据关联性等因素，需要充分考虑业务实际情况，进行详细的测试和验证，以确保分库和分表的正确性和可靠性。

面试官说：分表的两个主要场景

热点数据，分表，比如淘宝热门数据
数据的信息太多，比如学生数据有很多列，如果都在同一张表中，容易把表查崩

Java中的Array、ArrayList和LinkedList的区别，为什么要有Array和ArrayList这两个数据结构

Java中的Array、ArrayList和LinkedList都是常用的数据结构，它们各自有不同的优缺点以及适用场景。

Array是一种静态数据结构，长度在创建时就已经确定，不可以动态扩容或缩小。数组在内存中占用一段连续的内存空间，因此可以利用CPU的缓存机制进行高速访问。数组可以直接通过下标定位元素，因此访问速度比较快。但是数组的缺点是插入和删除操作比较低效，需要移动数组中元素的位置。
ArrayList是一种基于数组实现的动态数据结构，可以动态地增加或删除元素，实现了List接口，具有可变长度的特点。ArrayList的底层实现是一个可变长度的Object数组，当需要扩容时会自动创建一个新的更大的数组，并把原数组中的元素复制到新数组中，因此，ArrayList在插入和删除元素时比Array更具有优势。
LinkedList是一种基于链表实现的数据结构，可以在任意位置插入或删除元素，是一个可以动态扩容的数据结构。LinkedList的优点是插入和删除元素时只需要修改指针指向，不需要移动元素，因此比ArrayList更适合于频繁的插入和删除操作。

为什么Java中要同时存在Array和ArrayList这两种数据结构？

主要是因为Array在创建后长度不能改变，而ArrayList可以动态扩容，适合在应用程序执行过程中产生动态数据的情况。而Array在执行需要高效访问元素的操作时，由于是连续的内存空间，因此具有速度较快的优势，但是在数据变化较频繁的情况下会显得低效。因此，在实际开发中，需要根据具体的场景选择应用哪种数据结构更加合适。

hashmap如何计算hash值（hashcode）的，根据什么算的

在Java中，HashMap是一种存储键值对的数据结构，它的底层实现是基于哈希表（Hash Table）实现的。哈希表是一种利用哈希函数和数组实现的数据结构，可以快速地进行查找、插入和删除操作。

在HashMap中，每个键值对都有一个哈希码（Hash Code），哈希码用于映射到哈希表中的位置。HashMap中的哈希算法是通过计算键的哈希码（Hash Code）然后取模（mod）运算得到键在数组中的位置。

HashMap中用的hashCode函数是Object类中定义的hashCode函数。hashCode()方法的实现方式是根据对象的地址来计算哈希码的，不同的对象在内存中的地址不同，因此哈希码也不同。在自定义类中，如果没有重写hashCode方法，则继承自Object类的hashCode方法实现方式为将对象的内存地址转为一个整数作为hashCode返回。

当调用put()方法向HashMap中加入一个键值对时，先计算出键的哈希码，然后通过哈希算法计算键在数组中的位置。如果该位置上已经存在键值对，则采用链表的形式将新的键值对添加到链表尾部。如果该位置上没有键值对，则直接添加键值对。当调用get()方法获取键对应的值时，也通过哈希算法计算键在数组中的位置，然后遍历链表查找对应的键值对。

需要注意的是，哈希码的计算和哈希算法的实现方式对HashMap的性能影响较大，因此，尽量使哈希码分布均匀且不易冲突，可以提高HashMap的性能和稳定性。

【Java学习】面试复盘