rocketMQ 是通过Mmap写入 commitLog 文件的， rocketMq写入消息需要对单条数据进行操作，比如计算消息的tag，索引，偏移量，更新索引文件，延时信息，所有每条消息在写入时都需要进行解析。写入真正消息log文件时直接通过，调用操作系统write函数以顺序写方式写入log文件，没有使用 零拷贝技术，因为kafka是将一批消息数据，直接写入log文件，直接通过消息的量级，分摊了

当一个客户端尝试获取锁失败时（锁已被他人持有），Redisson 并不会立刻返回失败，而是会进入一个高效的阻塞等待模式。机制，解决了锁超时释放与业务执行时间不匹配的难题，同时在加锁、解锁的各个环节都做了精密设计，确保原子性与安全性。问题：依然存在主从/集群架构分布式锁失效（集群中从节点升级为主节点前未同步到主节点数据）方法的实现也至关重要，核心依然是 Lua 脚本，确保操作的原子性。在高并发场景线

using index condition使用到索引下推：扫描所有 name > ‘L’ 的行，在索引层判断 age 和 position（不满足的跳过），只回表满足条件的行。1：like “aa%”，一般情况下会使用索引下推。3.范围查询查询时可以将大的范围拆分成多个小范围。2 ：存储引擎不能使用索引中范围条件右边的列。1、根据自增且连续的主键排序的分页查询。2、根据非主键字段排序的分页查询。

一组操作，要么全部执行，要么全部不执行，保证数据最终一致性。

如果可以确定第一个线程重构缓存执行时间，设置线程的尝试加锁等待时间（预估缓存重建时间 + 缓冲时间），不在锁上无限等待，失败后直接去执行"超时后的重试逻辑"。线程3执行查数据库stock=10 ，与更新缓存中间时出现异常执行延迟，线程2此时执行写数据库并更新缓存，线程3恢复后又继续执行更新缓存，导致数据库与缓存之间数据不一致。线程3执行查数据库stock=10 ，与更新缓存中间时出现异常执行延迟，

在Redis7中，将这两部分分成了单独的⽂件，这样，即可以分别⽤来恢复⽂件，也便于控制AOF⽂件的⼤⼩。：sentinel节点会寻求其他节点对主节点的判断，如果超过半数sentinel节点认为master下线了，则认为master下线（客观下线O_DOWN），然后开始故障切换。2：调整slot的分布，将那些数据量多，访问频繁的热点slot进⾏重新调配，让他们尽量平均的分配到不同的Redis节点上。

实际存储的消息是topic下面对应的一系列的message消息队列，这些消息队列会尽量平均的分配到多个不同的broker当中 ，在集群当中，根据broker的数量均匀分配，这样有利于发挥broker的这种集群的性能优势。2、消费者需要实现MessageListenerOrderly接⼝，实际上在broker服务端，处理MessageListenerOrderly时，会给⼀个MessageQueue

每个类加载器对自己加载过的类都有一个缓存。

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推

AbstractQueuedSynchronizer 是 java.util.concurrent 包的基石，ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock 等同步器都基于它实现。AQS 提供了一个框架，用于实现依赖 状态（state） 和 FIFO 等待队列 的阻塞锁和同步器。