今日面试时，面试官问到了 “三色标记法”，我得回答是根据垃圾回收的 可达性分析算法，在垃圾回收时进行的并发标记的处理，然后讲了实现思路，与G1垃圾回收器中采用 增量更新 解决的并发标记问题，说到其本质就是垃圾回收与应用运行时的一种并发处理，与 MVCC 并发事务类似，都是针对于并发下的处理。

其实我在这是进行的 埋点，希望面试官来问我 MVCC 机制，我接下打算结合日志体系如何保障事务 ACID 来吊打他，结果面试官转弯来问到 那并发事务中，为什么不采用增量更新的形式解决呢？

在面试中回答过多次分库分表的问题以后，经过几次复盘，我对分库分表的内容已然掌握的炉火纯青，接下来我将根据实际的业务场景，系统性地总结分库分表的回答思路与个人思考的解决方案。

上文中了解数据架构的演进，当读写分离后主节点的写入成为性能瓶颈，又或者单表数据量突破数千万大关，数据库性能急剧下降时，在经历读写分离、缓存优化、SQL与索引调优等手段后，核心指标仍然告警，那分库分表成为技术架构演进的必然选择。

今天，我将带你了解 Apache 软件基金会的顶级项目 ShardingSphere ，它提供了一套完整的分布式数据库解决方案，接下来将学习它的核心架构与实战应用，掌握如何将庞大的数据拆分得井井有条。

在互联网应用快速发展的今天，数据量的爆炸式增长和并发访问的急剧上升给传统数据库架构带来了巨大挑战。本文将带您了解数据库架构的演进之路，深入探讨读写分离和分库分表技术如何解决海量数据场景下的性能瓶颈。

作为 Java 开发者，我需要建立了一个坚实且全面的核心技术栈指南，覆盖了后端开发的绝大部分关键领域。最近面试的过程中也是发现了一些自身的不足，尤其是在面架构师的岗位时也是发现自己的思考角度没有站在更高的地方，为了在这条路上更进一步，并在更高层次的面试中脱颖而出，我需要从“广度覆盖”转向“深度与体系化”，从“技术使用者”转向“设计决策者和问题定义者”，在此对自己掌握内容进行一次复盘。

接下来我将梳理技术栈，在现有基础上，进行深化和补充的方向，它们将使我的技术视野和能力更加立体和完整