实现原理 redisson实现

分布式事务 分布式事务模式总结 方案 简介 事务分类 一致性 总结 实现 / 产品 / 框架 两阶段提交（2PC） 二阶段分别指的是准备和提交两个阶段 数据库层面 强一致性 锁资源 - 阻塞 - 效率低 Seata 三阶段提交（3PC） 准备阶段、预提交阶段和提交阶段 数据库层面 强一致性 引入一个阶段也多一个交互，因此性能会差一些 TCC（补偿事务） TCC 指的是 Try - Confirm - Cancel 业务层面 最终一致性 执行效率高，基于 TCC 实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口，所以代码实现复杂度相对较高。 Seata Saga 模式 Saga 是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务 业务层面 最终一致性 一阶段提交本地事务，无锁，高性能 事件驱动架构，参与者可异步执行，高吞吐 补偿服务易于实现不保证隔离性 Seata 最大努力通知 柔性事务的思想：尽力最大的努力达成事务的最终一致；直接传递消息消费，要是成功则成功，要是失败则多重试几次，还是不成功就算了 业务层面 最终一致性 适用于对时间不敏感的业务；最大努力通知事务方案既没有使用本地表扫描，也未使用可靠消息机制,一般会提供主动查询接口 本地消息表 本地消息表其实就是利用了 各系统本地的事务来实现分布式事务 业务层面 最终一致性 此方案的核心是将需要分布式处理的任务通过消息日志表的方式来异步执行，执行成功后修改消息的状态；此外另起一个线程，不断轮询本地消息表中未处理成功的消息再次发起调用。与 tcc 相比，实现方式较为简单，开发成本低。缺点： 事务业务与消息发送业务耦合 、业务数据与消息表要在一起 MQ 消息事务 RocketMQ 事务消息的功能 业务层面 最终一致性 该方案与本地消息最大的不同是去掉了本地消息表，由 MQ 来实现消息的可靠性传递，确认消息一定被消费。业务相对简单，不需要编写三个阶段业务 缺点：代码侵入,还需要编写回查接口， 依赖于 MQ 的可靠性.

缓存 Redis 常见数据结构 缓存淘汰策略 rdb与aof 常见缓存问题及解决方案 缓存雪崩 缓存穿透 bloomfilter 缓存击穿 缓存一致性问题及解决方案 延时双删

分布式ID简介 雪花算法 美团Leaf 号段模式 改进的雪花算法 redis随机自增 参考资料 Leaf——美团点评分布式ID生成系统 分布式唯一 ID 生成方案浅谈

精品学习资料 数据结构 书籍: Java高并发与集合框架：JCF和JUC源码分析与实现 视频: 恋上数据结构第一季 玩转数据结构 从入门到进阶(慕课网) DDD DDD（领域驱动设计）思想解读及优秀实践

本质: 双向链表 序列化时仅需要按顺序序列化元素本身无需序列化Node，只需要在反序列化时重建双向链表即可 不推荐作为Deque,Queue,Stack(不允许存储null)使用,因为LinkedList可以存储null,不符合取出元素返回null时集合为空的接口定义

本质:底层使用数组，超出数组容量后会扩容50%并将数据拷贝到新数组对应位置 序列化的优化:仅序列化存有元素的数据,不序列化未使用数组部分 使用modCount做简化的并发检测，并不能做到并发安全，可以控制使用迭代器时无法修改集合，仅能通过迭代器提供的操作进行处理 Collection#toArray接口要求返回一个新的存有集合数据的数组，不能返回底层数组防止被意外修改影响原集合功能

单个测试覆盖率 直接选择"Run with Coverage"即可 所有测试的覆盖率(gradle) 在gradle插件中找到test任务(Tasks/verification/test),右键test选择"Run with Coverage"即可