2025.5.13
我自己先学习了solr，了解到solr支持分布式搜索、实时索引、动态聚类等企业级功能，并大概了解了如何连接 Solr 服务器,以及查询数据删除数据的一些API。师兄告诉我说项目中用solr主要是为了存储经纬度(经纬度是需要频繁查询的，所以使用solr，solr查询很快，如果使用mysql，首先存储那么多的数据就会有压力，其次的话查询数据的话也会很慢，很影响性能，如果使用Redis的话，虽然快，但是需要进行持久化保存到文件里，)，也就是用作一个存储的功能。和我们平时用的数据库类似、Solr 支持存储文档型数据（JSON、XML 等格式），json类似于一个键值对的形式去存储数据和mysql，redis其实本质大差不差，所以说solr肯定是可以当做数据库来存储数据的。
solr查询数据快的原因:全文检索能力
Solr 基于 Apache Lucene，支持复杂的文本搜索功能，如分词、模糊匹配、高亮、拼音搜索等。例如，中文场景下可集成 IK Analyzer 分词器，提升搜索精准度 。传统数据库的全文检索通常性能较差，需依赖外部工具。实时搜索与高并发
Solr 的倒排索引设计可实现毫秒级搜索结果返回，尤其适合高并发查询场景（如电商商品搜索）。数据库的模糊查询（如 LIKE）需全表扫描，性能随数据量增长急剧下降。
局限性
- 事务性不足 ：Solr 不支持 ACID 事务，无法保证数据的强一致性，不适合需要复杂事务处理的场景。
- 查询灵活性低 ：虽然支持简单筛选和排序，但缺乏 SQL 的复杂关联查询（如 JOIN）。
- 数据完整性弱 ：Solr 的字段约束（如唯一性、外键）不如传统数据库严格
我也问过师兄，这里solr不需要用到联表查询，这里应该也不是复杂事物处理的场景，所以说的话用solr完全可以。我还问了为什么不用Redis？Redis的确也快，但是只保存在内存里，数据容易丢失，所以必须进行持久化，但是持久化的话AOF和RDB，肯定是选择AOF，因为RDB只能记录某一时刻的数据，而且还不适合多次进行bgsave命令，开销太大了，那就只能AOF日志了，将做的操作的命令写到文件里，但是数据多的话读取文件里的命令肯定也是一个耗时的过程，因此得出结论最好就是用solr
activeMQ
activeMQ和我之前学的RabbitMq基本原理都是一致的，我了解了activeMQ的核心功能，其核心功能包括：
异步通信 ：解耦生产者和消费者，提升系统响应速度（如用户注册后发送邮件通知）
应用解耦 ：系统间通过消息传递交互，减少直接依赖（如调用第三方服务时隔离业务逻辑）
流量削峰 ：在高并发场景下缓存请求，避免服务器过载（如秒杀系统处理瞬时流量）
多消息模式 ：支持点对点（Queue）和发布-订阅（Topic）模式，适应不同场景需求
包括activeMq是如何工作的，首先得创建连接工厂，其次创建会话，用会话来创建队列，再将队列作为参数来创建生产者，然后用生产者发送消息，同理创建消费者，然后可以采用同步接收或者异步监听的方式来接受消息。
我问了师兄，咋们项目中用到activeMq主要是先作为一个数据的中转作用，不是说来一个数据我就放在solr里，而是说等到队列里的数据存储到一定值的时候再统一放到solr里，这样其实也是为了提高性能，如果来一条数据就存储一次的话太麻烦对性能来说影响比较大。
Nginx
负载均衡
将客户端请求转发至多个 Java 应用服务器（如 Tomcat、Spring Boot），降低单点压力。支持轮询、权重、IP 哈希等负载均衡算法，提升服务可用性
Nginx 反向代理详解
Nginx 反向代理是 Nginx 最核心的功能之一，它通过接收客户端请求并转发至后端服务器，再将响应返回给客户端，有效隐藏后端服务细节，提升系统的性能、安全性和可扩展性
请求处理流程
客户端请求 ：用户通过域名或 IP 访问 Nginx，DNS 将其解析为反向代理服务器的地址
请求转发 ：Nginx 根据配置规则（如 URL 路径、负载均衡策略）将请求转发至后端服务器（如 Tomcat、SpringBoot 应用）
响应返回 ：后端服务器处理请求后返回结果，Nginx 将结果传递回客户端，整个过程对用户透明
我问了下师兄，咋们公司项目中用nginx主要是解决端口的问题，如果一个网站上有多个系统，那就存在着多个端口号，那我们就可以用nginx去进行反向代理，前端访问后端的时候只需要用一个统一的端口8010，用这一个端口去代理多个服务，那后端根据前端url中的信息(项目名)会分发匹配找到对应后端的服务。
Gradle和maven 一样都是项目管理工具，可以引入和管理依赖
Svn 类似于Gitee，可以上传代码到码云仓库上
核心组件
仓库（Repository）检出（Checkout）提交（Commit）更新（Update）