最后
分享一些资料给大家，我觉得这些都是很有用的东西，大家也可以跟着来学习，查漏补缺。
《Java高级面试》
《Java高级架构知识》
《算法知识》
通过在主表冗余计算好的数据，可避免频繁重复计算数据。如下场景适合在主数据表内冗余数据：
-
应用系统需要经常获取计算好的数据
-
冗余的原始数据不经常变化
优点：方法简单，容易实现
缺点：侵入业务逻辑，拖慢业务代码性能的同时，长期迭代所产生的变化可能会有稳定性风险
表级处理 宽表预构建 / Cube 预构建
主要操作就是构建宽表，或者构建数据立方体（Data Cube）。构建好的宽表包含了用户查询时需要的所有维度、度量信息。
常见的表级处理包括：应用多写、数据库自身实现的物化视图、数据迁移同步。
应用多写
在主数据相同数据库内创建宽表，应用写入数据的同时也想宽表写入数据（事务保证一致性），复杂查询即可从该表进行。
优点：实现简单、低成本
缺点：对主数据库造成更大的读写压力，外加业务改造成本
RDBMS 物化视图
物化视图（快照）是包括一个查询结果的数据库只读对象，它是远程数据的本地副本，或者用来生成基于数据表求和的汇总表。通过数据冗余与预计算减少 join、聚合，从而提升查询性能。
优点：数据库引擎自身支持，使用成本较低
缺点：RDBMS 实现的方式有自己的局限性，比如生成物化视图的数据需要做一些业务紧相关变换就无法满足，或者某些数据库并没有完整实现该能力
数据迁移同步
借助数据同步工具，准实时将主数据表数据组织变换（包括按照业务逻辑变换）形成普通表或大宽表，写入第三方存储引擎。复杂查询直接在预构建好的表或者 cube 上执行，从而达到良好的性能。数据迁移工具的选择较多，总体上按照其侧重点，可以分为如下几类：
大数据类、流计算类、消息类、数据库类、云厂商类、专业数据迁移同步工具
优点：
主库更稳定：异步化解耦业务系统事务查询和复杂查询，避免复杂查询对主数据库产生影响。
易运维、链路稳定：数据迁移同步链路有标准化产品支撑，和主业务系统、主库读写解耦。整体架构上职责清晰，易于维护和问题追踪。
缺点：需要对纷繁多样的数据迁移同步工具、承载复杂查询数据库产品选型。
MySQL 到 ES 数据实时同步技术架构
在此介绍 “MySQL 到 ES 数据迁移同步” 的技术解决方案
为什么选 Mysql？
高并发能力：MySQL 内核特征特别适合高并发简单 SQL 操作，链接轻量化（线程模式），优化器、执行器、事务引擎相对简单。
稳定性好：主数据库最大的要求就是稳定、不丢数据。MySQL 主备系统在应对崩溃的情况下快速切换，innodb 存储引擎也保障了 MySQL 下盘稳定。
操作便捷：良好、便捷的用户体验，容易上手，学习成本低。
开源生态：MySQL 开源，让上下游厂商围绕其构建工具相对简单，HA proxy、分库分表中间件让其实用性大大加强，同时开源的特质让其有大量的用户。
为什么是 ES？
ES 的几个显著特点，能有效补足 MySQL 在企业级数据操作场景的缺陷
文本搜索能力：ES 是基于倒排索引实现的搜索系统，配合多样的分词器，在文本模糊匹配搜索上表现得比较好，业务场景广泛。
多维筛选性能好：亿级规模数据使用宽表预构建（消除 join），配合全字段索引，使 ES 在多维筛选能力上具备压倒性优势，加上文本搜索能力，独此一家。
开源和商业并行：ES 开源生态非常活跃，具备大量的用户群体，同时其内后也有独立的商业公司支持，而这让用户根据自身特点有了更加多样、渐进的选择。
为什么是数据迁移同步方式？
稳定性好：迁移同步对主数据库的操作主要是进行数据和日志的顺序读取，同时并发小，对主数据库稳定性影响较小（较多的下游订阅可能在网络层面存在影响，一般用消息解决）。另外日志（Binlog/WAL/Redo 等）可重放特质，让下游丢数据的可能性大大减小（处理好幂等的情况下）
业务解耦：一般而言主数据库更多承载事务型操作，而下游数据系统承载运营等层面的业务。
业务侵入小：数据迁移同步对业务无侵入，双端对接标准数据库（源），可以便利地找到开源、商业、云等各个方向的成熟解决方案或产品。
业务适配性好：某些数据迁移同步产品能够嵌入业务逻辑，让下游获取到更加贴近业务的数据，从而让数据服务更加有效和便捷。
数据迁移同步模型选择
订阅消费
优点：
堆积能力：由于引入了消息队列，所以整个链路是具备变更数据的堆积能力的。假设变更数据消费的比较慢，MySQL 本地较老的 binlog 文件由于磁盘空间的不足而被删除时，消息队列的数据依然存在，数据同步依然可以进行。
数据分发能力：引入消息队列后可以支持多方订阅。如果下游多个应用都依赖源端的变更数据，可以订阅同一份 topic 即可。
数据加工能力：由于变更数据是由下游消费者订阅，因此订阅后可以灵活的做一些数据加工。例如从外部调用微服务接口或者反查一些数据来做数据加工都是比较方便的。
缺点：
运维成本相对较高：包含了较多的组件和应用，运维保障相对复杂。
稳定性风险较高：一环出问题会导致整个数据同步链路的稳定性收到影响。而且排查和定位问题也会比较困难。
端对端直连
优点：
低延迟：端对端的直接同步，链路较短，延迟低
稳定性好：链路组件少，出问题概率较低，定位排查均比较容易。适合对数据精确性高的严苛场景。
功能拓展性强：对端写入消息系统，模拟订阅模式，可拓展性强
运维部署检点：链路组件少，部署运维更简单
数据迁移同步模型选择总结
如果没有众多的下游数据订阅，建议采用直连模式。数据同步链路往往置于在线业务中，随着业务规模以及重要性逐渐加大，链路稳定性更为重要些。
另外端到端模式只要支持对端数据源为消息中间件，可立即实现订阅模式，数据加工能力在某些数据迁移同步产品上可通过上传业务代码运行的方式解决。
数据架构在满足业务需求的同时，简洁和清晰能够让系统更加易于维护和排查，当遇到链路每天同步大量数据、偶尔丢几条需要排查，或同步链路卡住不同步等情况，端对端方式往往体现出相当大的优势。
MySQL 关联表在 ES 上的设计
关系型数据库中的表 join 关系在 ES 可以用几种数据类型来表达，包括 objected，nested，join 三种。
objected
object 类型可以存储嵌套结构。
优点：表示主 field 和 object 内部 field 之间的一对多关系，支持 doc 的 join 查询。由于所有查询时依赖的关联数据也都在一个文档内，避免了 ES 内部的 join，查询效率较高。
缺点：一对多关系只能保留一层，多于一层的会被打平，会丢失嵌套 field 内部的关联关系。
nested
nested 类型可以存储嵌套结构，表示一对多关系，是 object 类型的拓展。
优点：
不会出现 object 的缺点，整个嵌套关系是完整维护的，子文档内部关联关系保存是完整的
关联数据通过实现上自然关联到主文档上，搜索时性能较好（相对于 join）
缺点：
一个 nested field 只能属于一个主文档
在 nested 类型中，子文档和主文档之间强绑定，主文档更新的时候会强制更新子文档。在写多读少的场景，新能开销较大。
child 文档的查询必须通过父文档再找到子文档
子文档频繁修改的话会影响别的子文档和父文档，因为本质上在 lucene 实现上是父文档下的冗余存档
join
join 类型可以配置父子文档，通过父子文档来实现一对多的能力，一个索引只能建一个。相比 nested 类型，该类型更加灵活。父子文档之间通过 parentId 来关联，实际实现上他们就是独立的文档。
优点：
我的面试宝典：一线互联网大厂Java核心面试题库
以下是我个人的一些做法，希望可以给各位提供一些帮助：
整理了很长一段时间，拿来复习面试刷题非常合适，其中包括了Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等，且还会持续的更新…可star一下！
283页的Java进阶核心pdf文档
Java部分：Java基础，集合，并发，多线程，JVM，设计模式
数据结构算法：Java算法，数据结构
开源框架部分：Spring，MyBatis，MVC，netty，tomcat
分布式部分：架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等
微服务部分：SpringBoot，SpringCloud，Dubbo，Docker
还有源码相关的阅读学习
dis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等
微服务部分：SpringBoot，SpringCloud，Dubbo，Docker
[外链图片转存中…(img-d07qaEzE-1714866764035)]
还有源码相关的阅读学习
[外链图片转存中…(img-HWmiIuKh-1714866764036)]
731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
