1. 缓存穿透
和缓存击穿的区别
- 缓存穿透:
- 现象:指查询的数据在缓存和数据库中都不存在,每次请求都会落到数据库,导致数据库压力过大。
- 解决方案:
- 布隆过滤器:在缓存层加一个布隆过滤器,快速判断数据是否存在。
- 缓存空值:当数据库返回空数据时,设置一个短期的空缓存,避免频繁查询数据库。
- 缓存击穿:
- 现象:指热点数据在缓存过期后,大量请求瞬时到达,直接打到数据库,造成数据库瞬时压力过大。
- 解决方案:
- 缓存预热:在热点数据即将过期前主动刷新缓存。
- 加互斥锁:通过分布式锁机制确保同一时间只有一个线程能加载数据。
2. 死锁的典型场景
-
定义:多个进程或线程因资源争用相互等待,导致无法继续执行。
-
示例:两个线程分别持有资源 A 和资源 B,互相等待对方释放资源。
class DeadlockExample { private static final Object resourceA = new Object(); private static final Object resourceB = new Object(); public static void main(String[] args) { Thread thread1 = new Thread(() -> { synchronized (resourceA) { System.out.println("Thread 1: Locked resource A"); try { Thread.sleep(50); } catch (InterruptedException ignored) {} synchronized (resourceB) { System.out.println("Thread 1: Locked resource B"); } } }); Thread thread2 = new Thread(() -> { synchronized (resourceB) { System.out.println("Thread 2: Locked resource B"); try { Thread.sleep(50); } catch (InterruptedException ignored) {} synchronized (resourceA) { System.out.println("Thread 2: Locked resource A"); } } }); thread1.start(); thread2.start(); } }
3. CAP 定理
- 定义:在分布式系统中,Consistency(一致性)、Availability(可用性) 和 Partition Tolerance(分区容错性) 无法三者兼得。
- 本质:类似于一种不可能三角,需要根据实际业务场景进行取舍。
- CP:强一致性和分区容错性,可能牺牲部分可用性。(如 Zookeeper)
- AP:高可用性和分区容错性,可能放松一致性要求。(如 Cassandra)
- CA:理论上无法实现,因为分区容错性是分布式系统的基本要求。
4. 脏写问题
- 定义:指在事务未提交时,其修改的数据被其他事务读取或覆盖。
- 问题的“脏”体现:
- 数据修改尚未持久化却被错误使用,可能导致数据混乱或错误。
- 解决办法:
- 数据库隔离级别:
- READ COMMITTED:避免脏读。
- REPEATABLE READ:避免不可重复读。
- SERIALIZABLE:避免幻读。
- 乐观锁或悲观锁:保证事务之间互不干扰。
- 数据库隔离级别:
5. TCC 模式
- 定义:TCC(Try-Confirm-Cancel)是分布式事务的一种实现模式。
- 原理:
- Try:预留资源,检测操作的可行性。
- Confirm:真正执行操作。
- Cancel:回滚操作,释放资源。
- 应用于文字修改的场景:
- Try:预锁定目标文本的区域。
- Confirm:正式提交文本的修改。
- Cancel:回滚修改,释放锁定的区域。
6. TCC 的事务隔离
- 问题:如何在多个事务同时操作时,保证资源的隔离性和一致性?
- 解决方案:
- 资源锁定机制:
- 在 Try 阶段锁定资源,避免其他事务对该资源的操作。
- 幂等性和防悬挂机制:
- 确保 Confirm 和 Cancel 操作能够多次执行结果一致。
- 防止事务异常情况下资源长时间锁定。
- 资源锁定机制:
7. 最大努力通知模式
- 定义:一种尽量保证消息可靠送达的机制,但不保证消息一定送达。
- 特点:
- 不直接参与事务控制。
- 不解决分布式系统的一致性问题,仅提高通知的送达率。
- 场景:支付系统向物流系统通知发货。
- 事务一:支付系统更新订单状态为支付成功。
- 事务二:通知物流系统处理发货。
- 机制:通过日志记录和重试机制提高通知成功率。
8. 最大努力通知与回滚操作
- 问题:如果事务一成功而事务二失败,如何回滚或补偿?
- 解决方案:
- 显式回滚机制:
- 对事务一的操作设计回滚逻辑。
- 例如:撤销支付状态。
- 幂等补偿机制:
- 针对事务二进行多次重试,直到成功。
- 事件溯源机制:
- 记录所有事件状态,异步对失败事件进行补偿或人工干预。
- 通知中间件与延迟消息补偿:
- 使用消息队列确保通知可靠送达,结合延迟任务进行后续处理。
- 显式回滚机制:
9. 最大努力通知与一致性
- 不解决一致性:最大努力通知只是一种通知机制,旨在提高消息传递的可靠性,但一致性问题需要其他机制解决。
- 配合幂等性和补偿机制:通过幂等性设计和补偿机制,尽量减少分布式系统中不一致的影响。