加群联系作者vx：xiaoda0423
仓库地址：webvueblog.github.io/JavaPlusDoc…
webvueblog.github.io/JavaPlusDoc…
你遇到的问题是 Maven 3.8.x 及以上版本默认 屏蔽 HTTP 仓库（非 HTTPS） ，这正是错误中所提到的：
maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories
背景说明：
从 Maven 3.8.1 开始，出于安全考虑，默认禁止从 http:// 地址下载依赖。如果你的仓库（如阿里云）仍使用 http:// 协议，就会被默认拒绝访问并缓存该失败，导致后续也不再尝试。
✅ 解决方案（推荐使用 HTTPS 仓库或配置允许 HTTP）
✅ 方法一：改用 HTTPS 仓库地址（推荐）
如果你用的是阿里云仓库，建议在你的 settings.xml 或 pom.xml 中 更换为 HTTPS 版本的地址：
<mirror>
<id>aliyunmaven</id>
<mirrorOf>central</mirrorOf>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>
也可以用 https://maven.aliyun.com/nexus/content/groups/public/。
✅ 方法二：显式允许 HTTP 仓库
你可以在 settings.xml 中添加如下配置，允许某些特定仓库使用 HTTP 协议：
<settings>
<mirrors>
<!-- 其他 mirror 配置 -->
</mirrors>
<profiles>
<profile>
<id>allow-http</id>
<repositories>
<repository>
<id>aliyun-http-repo</id>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>allow-http</activeProfile>
</activeProfiles>
</settings>
✅ 方法三：使用 -U 强制更新 + 清除缓存
清除 .m2/repository/com/oracle/ojdbc6 目录，强制 Maven 重新尝试下载：
rm -rf ~/.m2/repository/com/oracle/ojdbc6
mvn clean install -U
✅ 方法四：将 ojdbc6 手动安装到本地仓库
Oracle JDBC 驱动常常不托管在中央仓库，最稳妥的是手动安装：
mvn install:install-file \
-DgroupId=com.oracle \
-DartifactId=ojdbc6 \
-Dversion=11.2.0.3 \
-Dpackaging=jar \
-Dfile=/path/to/ojdbc6.jar
总结
| 方法 | 说明 |
|---|---|
| ✅ 推荐 | 替换为 HTTPS 仓库地址（最省事） |
| ✔ 兼容 | 在 settings.xml 里允许 HTTP 仓库 |
| ⚠ 临时 | 使用 -U 并清除缓存后强制更新 |
| 🔒 稳妥 | 手动安装 Oracle 的依赖到本地仓库 |
这个错误：
Could not find artifact com.jackson0714.xx:xx:pom:0.0.1-SNAPSHOT
说明 Maven 在阿里云公共仓库中找不到 xx 项目的依赖，而这个依赖是：
com.jackson0714.xx:xx:0.0.1-SNAPSHOT
属于一个自定义的、非中央仓库托管的 SNAPSHOT 版本。
✅ 解决方案分析
✅ 方案一：检查这个依赖是否是你本地项目的模块
如果你是这个 xx 项目的作者：
- 你可能还没有 install 当前模块，或者其他模块依赖它但它没有被打包。
- 请在项目根目录下运行：
mvn clean install
这会把 xx:0.0.1-SNAPSHOT 安装到本地仓库 ~/.m2/repository。
✅ 方案二：确认是否正确引用了子模块
如果你用了多模块结构（如 parent -> xx-api -> xx-common），确保你的 parent pom.xml 中包含所有模块：
<modules>
<module>xx</module>
<module>xx-api</module>
<module>xx-common</module>
</modules>
然后还是执行：
mvn clean install
✅ 方案三：你引用了别人的项目但它没发布
如果你在 GitHub 上找到了某个项目引用了 com.jackson0714.xx:xx，那这个项目很可能没有发布到公开仓库（如 Maven Central、阿里云等） 。
此时你应该：
- 去找该项目的源码（例如 GitHub）
- clone 到本地
- 然后手动 install：
git clone https://github.com/jackson0714/xx.git
cd xx
mvn clean install
✅ 方案四：排查 SNAPSHOT 版本缓存问题
如果你之前用的是 http 仓库（被屏蔽了），Maven 会缓存下载失败的依赖。建议清理缓存再重新尝试：
rm -rf ~/.m2/repository/com/jackson0714
mvn clean install -U
总结
| 情况 | 解决方法 |
|---|---|
| 是你自己写的模块 | 用 mvn clean install 安装本地 SNAPSHOT |
| 是多模块工程 | 确保父模块 pom.xml 的 <modules> 正确声明所有子模块 |
| 是别人项目的依赖 | 去 GitHub 下载源码后自己 install 到本地 |
| 缓存失败的问题 | 清理 .m2/repository 中对应目录并使用 -U 强制更新 |
ES的分布式架构原理
在搜索这块，lucene 是最流行的搜索库。几年前业内一般都问，你了解 lucene 吗？你知道倒排索引的原理吗？现在早已经 out 了，因为现在很多项目都是直接用基于 lucene 的分布式搜索引擎—— ElasticSearch，简称为 ES。
而现在分布式搜索基本已经成为大部分互联网行业的 Java 系统的标配，其中尤为流行的就是 ES，前几年 ES 没火的时候，大家一般用 solr。但是这两年基本大部分企业和项目都开始转向 ES 了。
ES 的分布式架构设计能介绍一下么？就看看你对分布式搜索引擎架构的一个基本理解。
ElasticSearch 设计的理念就是分布式搜索引擎，底层其实还是基于 lucene 的。核心思想就是在多台机器上启动多个 ES 进程实例，组成了一个 ES 集群。
ES 中存储数据的基本单位是索引，比如说你现在要在 ES 中存储一些订单数据，你就应该在 ES 中创建一个索引 order_idx ，所有的订单数据就都写到这个索引里面去，一个索引差不多就是相当于是 mysql 里的一个数据库。
index -> type -> mapping -> document -> field
这样吧，为了做个更直白的介绍，我在这里做个类比。但是切记，不要划等号，类比只是为了便于理解。
index 相当于 mysql 数据库。而 type 没法跟 mysql 里去对比，一个 index 里可以有多个 type，每个 type 的字段都是差不多的，但是有一些略微的差别。假设有一个 index，是订单 index，里面专门是放订单数据的。就好比说你在 mysql 中建表，有些订单是实物商品的订单，比如一件衣服、一双鞋子；有些订单是虚拟商品的订单，比如游戏点卡，话费充值。就两种订单大部分字段是一样的，但是少部分字段可能有略微的一些差别。
所以就会在订单 index 里，建两个 type，一个是实物商品订单 type，一个是虚拟商品订单 type，这两个 type 大部分字段是一样的，少部分字段是不一样的。
很多情况下，一个 index 里可能就一个 type，但是确实如果说是一个 index 里有多个 type 的情况（注意， mapping types 这个概念在 ElasticSearch 7. X 已被完全移除，详细说明可以参考官方文档），你可以认为 index 是一个类别的表，具体的每个 type 代表了 mysql 中的一个表。
每个 type 有一个 mapping，如果你认为一个 type 是具体的一个表，index 就代表多个 type 同属于的一个类型，而 mapping 就是这个 type 的表结构定义，你在 mysql 中创建一个表，肯定是要定义表结构的，里面有哪些字段，每个字段是什么类型。
实际上你往 index 里的一个 type 里面写的一条数据，叫做一条 document，一条 document 就代表了 mysql 中某个表里的一行，每个 document 有多个 field，每个 field 就代表了这个 document 中的一个字段的值。
你搞一个索引，这个索引可以拆分成多个 shard ，每个 shard 存储部分数据。拆分多个 shard 是有好处的，一是支持横向扩展，比如你数据量是 3T，3 个 shard，每个 shard 就 1T 的数据，若现在数据量增加到 4T，怎么扩展，很简单，重新建一个有 4 个 shard 的索引，将数据导进去；二是提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器上并行分布式执行，提高了吞吐量和性能。
接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有一个 primary shard ，负责写入数据，但是还有几个 replica shard 。 primary shard 写入数据之后，会将数据同步到其他几个 replica shard 上去。
通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊，还有别的数据副本在别的机器上呢。高可用了吧。
ES 集群多个节点，会自动选举一个节点为 master 节点，这个 master 节点其实就是干一些管理的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举一个节点为 master 节点。
如果是非 master 节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。
说得更简单一点，就是说如果某个非 master 节点宕机了。那么此节点上的 primary shard 不就没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。
其实上述就是 ElasticSearch 作为分布式搜索引擎最基本的一个架构设计。
ES在数据量很大
ES 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？
其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 510s ，坑爹了。第一次搜索的时候，是 510s ，后面反而就快了，可能就几百毫秒。
你就很懵，每个用户第一次访问都会比较慢，比较卡么？
说实话，es 性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。
性能优化的杀手锏——filesystem cache
你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。
es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。但如果是走 filesystem cache ，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。
这里有个真实的案例。某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G 。每台机器给 es jvm heap 是 32G ，那么剩下来留给 filesystem cache 的就是每台机器才 32G ，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T ，那么每台机器的数据量是 300G 。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。
归根结底，你要让 es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。
根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 es 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 filesystem cache 的是 100G，那么你就将索引数据控制在 100G 以内，这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在 1 秒以内。
比如说你现在有一行数据。 id,name,age .... 30 个字段。但是你现在搜索，只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的少数几个字段就可以了，比如说就写入 es id,name,age 三个字段，然后你可以把其他的字段数据存在 mysql/hbase 里，我们一般是建议用 es + hbase 这么一个架构。
hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id ，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。
写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。
冷热分离
es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 filesystem os cache 里，别让冷数据给冲刷掉。
你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 shard。3 台机器放热数据 index，另外 3 台机器放冷数据 index。然后这样的话，你大量的时间是在访问热数据 index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 filesystem cache 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。
document 模型设计
对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。
最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。
document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。
分页性能优化
es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。
分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。
我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。
有什么解决方案吗？
不允许深度分页（默认深度分页性能很差）
跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。
类似于 app 里的推荐商品不断下拉出来一页一页的
类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 scroll api ，关于如何使用，自行上网搜索。
scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。
但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。所以现在很多产品，都是不允许你随意翻页的，app，也有一些网站，做的就是你只能往下拉，一页一页的翻。
初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。
除了用 scroll api ，你也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 sort 字段。
