- 博客(116)
- 收藏
- 关注
RSS订阅原创 Spring面试题总结
循环依赖（Circular Dependency）指的是两个或多个 Bean 之间相互依赖，导致 Spring 在创建 Bean 时出现死循环。例如：A 依赖 B，B 也依赖 A，Spring 在实例化时会陷入循环创建。1️⃣ 三级缓存（Three-level Cache）机制Spring 在实例化 Bean 时，提前暴露引用一级缓存（singletonObjects）：存放完全初始化的 Bean二级缓存（earlySingletonObjects）：存放已经实例化但未填充属性的 Bean。
2025-03-03 00:28:38
934
原创 力扣Hot100刷题记录
关键在于每次选择数组的中间元素作为当前子树的根节点，这样可以确保左右子树的高度差不超过1，从而保证树是平衡的。中最近公共祖先的定义为：“对于有根树 T 的两个节点 p、q，最近公共祖先表示为一个节点 x，满足 x 是 p、q 的祖先且 x 的深度尽可能大（不需要从根节点开始，也不需要在叶子节点结束，但是路径方向必须是向下的（只能从父节点到子节点）。，想象自己站在它的右侧，按照从顶部到底部的顺序，返回从右侧所能看到的节点值。的链表，表示两个非负的整数。是指从根节点到最远叶子节点的最长路径上的节点数。
2025-02-21 19:03:23
911
原创 多线程基础面试题剖析
创建线程的方式有两种，一种是继承Thread，一种是实现Runable在这里推荐使用实现Runable接口，因为java是单继承的，一个类继承了Thread将无法继承其他的类，而java可以实现多个接口，所有如果实现了Runable接口后，还可以实现其他的接口。
2025-02-15 21:29:30
956
原创 Redis高可用相关面试题剖析
当我们启动多个 Redis 实例的时候，它们相互之间就可以通过replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步psyncpsync一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为，可以避免频繁建立连接的开销。
2025-02-12 17:37:39
610
原创 redis持久化原理相关面试题剖析
为了，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，。除此之外，为了进行，可以将持久化文件拷贝到一个远程位置既然redis的数据可以保存在磁盘上，那么这个流程是什么样的呢？前三步是由redis完成的，后两步是由OS完成的这5个过程是在理想条件下一个正常的保存流程，但是在大多数情况下，我们的机器等等都会有各种各样的故障，这里划分了两种情况（1）Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成。
2025-02-11 20:33:31
1252
原创 Redis底层数据结构面试题剖析
redis是一个支持 key-value 内存存储的数据结构服务器，如下：基于k,v存储的nosql数据库，其天然的就必须具备一个dict底层数据结构来支撑Redis的 dict 实现最显著的一个特点，就在于它的重哈希。我们知道，dict进行扩容时，我们要对列表中的每个元素遍历迁移到新的dict中，这样全量式的迁移开销太大，而且redis还是单线程的，当这个唯一的线程去做迁移去了，那并发的客户端请求不就得一直阻塞等待着，大大降低redis的并发及性能。然而，redis基于上述痛点是怎样做的呢？
2025-02-11 17:16:01
1031
原创 消息队列MQ面试题解，基础面试题
一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先完成操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误，并且执行的时候是多线程执行的，并不能保证执行的顺序性。
2025-01-26 01:27:26
1120
2
原创 JVM面试题解，垃圾回收之“垃圾回收器”剖析
表示该对象尚未被收集器访问过，在可达性分析结束后，仍为白色的对象表示不可达，即为垃圾。要被回收表示该对象已被收集器访问过，但是这个对象至少存在一个引用还未被扫描表示该对象已被收集器访问过，并且它的所有引用都已被扫描，黑色对象是安全存活的。另外：对于黑色对象1、如果有其他对象的引用指向了黑色对象，无需重新扫描一遍2、黑色对象不可能绕过灰色对象直接指向白色对象。
2025-01-23 22:05:11
973
原创 JVM面试题解，垃圾回收之“分代回收理论”剖析
什么是跨代引用分代回收也并不是简单划分一下内存区域这么简单，因为对象不是孤立的，对象之间存在跨代引用，譬如：现在要在新生代进行回收，但新生代的对象极有可能被老年代对象所引用，那为了找到这些可能存活的对象，不得不在既定的 GC Roots 之外，再遍历整个老年代对象确保可达性分析结果的正确性。反过来回收老年代也是一样。这样无疑带来了性能负担。
2025-01-23 00:23:39
1119
原创 JVM面试题解，垃圾回收之“对象存活判断”剖析
最常用的就是和引用计数法为每个对象维护一个计数器来跟踪有多少个引用指向该对象。每当创建一个新的引用指向某个对象时，计数器加1；每当一个引用失效或被移除时，计数器减1。当计数器降为0时，表示没有其他对象引用它，因此可以安全地将其回收。引用计数法有个非常大的问题就是循环引用。循环引用：如果两个或多个对象相互引用形成环状结构，即使这些对象不再被外部使用，它们的引用计数也不会降为0，从而导致内存泄漏。
2025-01-22 22:59:05
857
原创 Redisson中红锁（RedLock）的实现
当在单点redis中实现redis锁时，一旦redis服务器宕机，则无法进行锁操作。因此会考虑将redis配置为主从结 构，但在主从结构中，数据复制是异步实现的。假设在主从结构中，master会异步将数据复制到slave中，一旦某 个线程持有了锁，在还没有将数据复制到slave时，master宕机。则slave会被提升为master，但被提升为slave的 master中并没有之前线程的锁信息，那么其他线程则又可以重新加锁。
2025-01-15 23:44:29
1052
原创 业务幂等性技术架构体系之消息幂等深入剖析
在系统中当使用消息队列时，无论做哪种技术选型，有很多问题是无论如何也不能忽视的，如：消息必达、消息幂等等。本文以典型的RabbitMQ为例，讲解如何保证消息幂等的可实施解决方案，其他MQ选型均可参考。
2025-01-15 22:28:50
598
原创 业务幂等性技术架构体系之服务幂等深入剖析
简单来说，是指一个操作（或请求）无论被执行多少次，其对系统状态的影响都是一样的，就好像这个操作只执行了一次一样。换句话说，对于同一组输入参数，幂等的服务会给出相同的结果，并且不会改变系统的最终状态。与接口幂等的区别接下来我们将分别介绍几种服务幂等的解决方案。
2025-01-15 20:38:03
1281
原创 业务幂等性技术架构体系之接口幂等深入剖析
通过token机制来保证幂等是一种非常常见的解决方案，同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。无论先删token还是后删token，都会有一个相同的问题。每次业务请求都回产生一个额外的请求去获取 token。但是，业务失败或超时，在生产环境下，一万个里最多也就十个左右会失败，那为了这十来个请求，让其 他九千九百多个请求都产生额外请求，就有一些得不偿失了。虽然redis性能好，但是这也是一种资源的浪费。业务流程图1）修改工程中，新增生成令牌方法genToken@Autowired。
2025-01-14 21:21:36
804
原创 MySQL核心揭秘：InnoDB存储引擎高级特性
其实就是插入数据时，不进行立即的插入，即不进行立即的数据落盘，而是先将变更的操作记录到插入缓存中。具体的：当对非唯一二级索引进行插入、更新或删除操作时，如果这些索引页不在内存中（即不在缓冲池内），InnoDB不会立即读取这些页到内存以更新索引，而是将这些变更暂时记录在插入缓存中。然后再进行合并写入：插入缓存会定期地与实际的索引页进行合并。当某个索引页被加载到内存中时（例如由于其他查询访问了该页），InnoDB会检查插入缓存中是否有针对该页的未处理变更，并一次性应用所有相关变更。
2025-01-10 19:08:54
959
原创 MySQL核心揭秘：InnoDB存储引擎深度探索
InnoDB的整体架构分为三部分：缓冲池(Buffer Pool)、后台线程、文件，如下图所示三部分由于日常的DML语句操作时，首先操作的是缓冲池，并没有直接写入到磁盘，这有可能会导致内存中的数据与磁盘中的数据产生不一致的情况，而与磁盘中数据不一致的页我们成为"脏页"。而checkpoint的工作，就是将内存中的脏页，在一定条件下刷新到磁盘。如果在从缓冲池将页数据刷新到磁盘的过程中发生宕机，那么数据就无法恢复了；
2025-01-10 15:28:38
1043
原创 面试题解，Java中的“字节码”剖析
这一般发生在try-finally代码块中trycatchfinallyfinallyfinallyLocklock()unlock()unlock()unlock()finallyunlock()finally注意：还有一种隐式异常处理，JVM在遇到未被捕获的异常时，会按照异常表的规定顺序查找合适的处理程序。这意味着即使没有显式的catch块，只要存在finally块，JVM也会确保执行其中的清理逻辑，比如释放锁或其他资源。
2025-01-04 21:31:17
965
原创 面试题解，Java中的“对象”剖析
话不多说，看下图，对象的内存布局图一个对象的内存布局主要由三部分组成：对象头（Object Header）、实例数据（Instance Data）和对齐填充（Padding）。而数组类型的对象，还有4个字节的数组长度字段，所有new一个对象需要的内存大小为：8byte(对象头) + 4byte(类型指针) + 实例数据 + 填充字段 + 4byte数组长度(若为数组类型)
2025-01-04 21:11:11
829
原创 史上最强的Kafka可视化WebUI工具，涵盖多种功能
GitHub - lichengchuan/KafkaWebUIByLCC: Kafka Web UI By LCC 是一个专为简化Apache Kafka集群管理和操作而设计的图形化用户界面（GUI）。该项目旨在为开发者、运维人员和数据科学家提供一个直观且易用的平台，以进行Kafka主题（Topic）管理、消息生产和消费、以及集群监控等任务。通过该工具，用户无需编写复杂的命令行指令，即可轻松完成日常维护工作，并能更有效地监控和优化Kafka集群性能。
2025-01-04 14:38:39
8318
6
原创 分布式全文检索引擎ElasticSearch-数据的写入存储底层原理
1、内存缓冲区（Buffer）作用：用于临时存储写入的数据，提高写入性能。刷新机制：每隔一段时间（默认 1 秒）或当缓冲区满时，数据会被刷新到段（Segment）。2、事务日志（Translog）作用：用于记录所有未持久化到段的数据，防止数据丢失。持久化：写入操作在返回成功之前，必须确保数据被写入 Translog。Flush 操作：定期将数据从缓冲区刷新到段，并清空 Translog，生成新的空的 Translog。3、段（Segment）下一节将详细讲4、主分片与副本分片。
2024-12-17 16:39:52
1189
原创 ElasticSearch中的深度分页问题
"from": 0,"size": 10from：跳过的记录数size：返回的记录数例如，from=1000和size=10表示跳过前 1000 条记录，从第 1001 条开始获取 10 条记录。当from参数的值很大时（如from=10000以上），ElasticSearch 需要跳过大量数据来获取指定页的内容，这种情况称为深度分页。
2024-12-17 12:22:13
1910
原创 ElasticSearch中的模糊搜索：为什么输入错误还能搜索出来？
模糊搜索是一种搜索技术，允许用户即使在输入时存在拼写错误或笔误，也能够找到与之相近的匹配结果。常见的应用场景用户输入拼写错误，例如搜索“tesing”而不是“testing”。用户不确定正确的拼写，例如搜索“analyse”而不是“analyze”。搜索时存在同音字或者形近字问题。
2024-12-16 20:16:01
1116
原创 分布式全文检索引擎ElasticSearch-文档的CRUD原理
在索引库中，我们要将一个文档存储下来，由于索引是进行分片的，那么我们的一个文档来了，该存储到哪一个分片中呢？首先这肯定不会是随机的，_id通过上面的公式，我们理解并且也需要记住一个重要的规律：创建索引的时候就确定好主分片的数量，并且永远不会改变这个数量，数量的改变将导致上述公式的结果变化，最终会导致我们的数据无法被找到。
2024-12-16 16:30:04
1220
原创 ElasticSearch集群的故障与恢复机制
集群的master节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。
2024-12-16 14:17:40
628
原创 基于Sharding-jdbc实现水平分库、垂直分库、读写分离
面对日益增加的系统访问量，数据库的吞吐量面临着巨大瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的应用系统来说，将数据库拆分为主库和从库，主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能得到极大的改善。通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。
2024-12-14 22:59:48
931
原创 Sharding-jdbc基本使用步骤以及执行原理剖析
使用sharding-jdbc完成对订单表的水平分表，通过快速入门的开发，了解sharding-jdbc使用方法人工创建两张表，t_order_1和t_order_2，这两张表是订单表拆分后的表，通过sharding-jdbc向订单表插入数据，按照一定的分片规则，主键为偶数的进入t_order_1，另一部分数据进入t_order_2，通过sharding-jdbc查询数据，根据SQL语句的内容从t_order_1或t_order_2查询数据。
2024-12-13 22:51:29
1747
原创 Sharding-jdbc基本概念剖析
Sharding-JDBC是分布式数据中间件Sharding-Sphere中的重要组成部分。定位为轻量级Java框架，在Java的JDBC层提供的额外服务，它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，，完全兼容JDBC和各种ORM框架。简单理解，就是基于Java的实现分库分表的中间件Sharding-JDBC的核心功能为数据分片和读写分离通过sharding-JDBC，应用可以透明的使用jdbc访问已经分库，读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。
2024-12-13 17:38:01
883
原创 分布式全文检索引擎ElasticSearch-常用mapping讲解
mapping就是映射，可以简单理解为数据类型，只不过是规定了索引中每个字段的数据类型，我们以传统关系型数据库为例，数据库建表的时候，我们DDL依据一般都会指定每个字段的存储类型，例如：varchar、int、datetime等，目的很明确，就是更精确的存储数据，防止数据类型格式混乱，在Elasticsearch中也是这样，创建索引的时候一般也需要指定索引的字段类型，这种方式称为映射（Mapping）那么指定映射有两种方式，和。
2024-12-13 15:35:08
1326
原创 分库分表原则剖析以及产生的问题如何解决
MySQL是关系型数据库，数据库表之间的关系从一定的角度上映射了业务逻辑。任何分库分表的行为都会在某种程度上提升业务逻辑的复杂度，数据库除了承载数据的存储和访问外，协助业务更好的实现需求和逻辑也是其重要工作之一。分库分表会带来数据的合并，查询或者更新条件的分离，事务的分离等等多种后果，业务实现的复杂程度往往会翻倍或者指数级上升。所以，在分库分表之前，不要为了分而分，去做其他力所能及的事情，比如升级硬件，升级网络，升级数据库库版本，读写分离，负载均衡等。所有分库分表的前提是，这些都已经尽力了。
2024-12-12 17:05:04
1172
原创 分库分表基本概念讲解
分库分表之后，比如我们要插入一条数据，该插入到哪一张子表中呢，查询某条数据又该从哪一张子表查呢？这有很多的中间件来帮我们完成这些事情阿里的TDDL,DRDS和cobar开源社区的民间组织的MyCAT360的Atlas按照架构类型划分Client模式Proxy模式。
2024-12-11 22:26:03
872
原创 分布式全文检索引擎ElasticSearch-基本概念介绍
索引，可以理解是我们的目录，看一本书的时候，可以根据目录准确快速定位到某一页，那么索引就可以帮我们快速定位到某条数据在庞大的数据表的哪一个位置。我们常见的索引包括正排索引和倒排索引。
2024-12-11 20:41:25
1586
原创 分库分表背景下，千万级订单id的生成策略详解
随着业务数据量增加，数据库一般会存在单表的性能瓶颈，因此需要对一个数据表甚至一整个数据库做拆分，那么拆分后，如何保证多个子表之间订单id的唯一性呢？这时候是否还能够依赖于数据表自身的主键自增策略呢？
2024-12-10 21:53:13
966
原创 单点登录深入详解之技术方案总结
断言是一个包含了由SAML授权方提供的0到多个声明（statement）的信息包。SAML断言通常围绕一个主题生成。该主题使用声明。SAML 2.0规范定义了三种断言声明，详细信息如下：身份验证（）：该断言的主题是在某个时间通过某种方式被认证。属性（Attribute）：该断言的主题和某种属性相关联。授权决策（）：该断言的主题被允许或者被禁止访问某个资源。-- SAML断言的根元素，包含了断言的所有信息 -->-- 发行者元素，标识了断言的发行实体 -->
2024-11-28 18:34:23
1425
原创 单点登录深入详解之设计方案总结
用户登录之后将认证信息存储至Cookie，当再次访问本服务或者访问其他应用服务时，直接从Cookie中传递认证信息，进行鉴权处理。
2024-11-27 23:32:29
1524
原创 精心修炼Java并发编程（JUC）-volatile与synchronized关键字
volatile 是 JVM 提供的，中文意思是不稳定的，易变的，用volatile修饰变量是为了保证变量在多线程中的可见性，它表达的含义是：告诉编译器，对这个变量的读写，需要基于主内存保证多CPU的缓存一致性。保证变量对所有线程的可见性：当一条线程修改了 volatile 变量的值，新值对于其他线程来说是可以立即得知的。而普通变量不能做到这一点注意：1、volatile并不能保证并发操作的原子性，即不保证线程安全。
2024-11-27 21:14:25
1074
原创 精心修炼Java并发编程（JUC）-ThreadLocal
ThreadLocal类并不是用来解决多线程环境下的共享变量问题，而是用来提供线程内部的独享变量。在多线程环境下，可以保证各个线程之间的变量互相隔离、相互独立。使用案例这些场景都会用到我们的ThreadLocal。
2024-11-27 20:16:06
511
Hadoop辅助工具-winutils
2024-11-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人