jt项目采用分布式聚合型结构，如右图所示
项目以jt为父类，目录下子类继承父类的pom文件依赖
公共接口：
jt-common消费者：
jt-web（前端页面模块）生产者：
jt-cart（购物车模块）（消费者继承了公共接口中定义的pojo和接口）
jt-manage（后端数据模块）
jt-order1（订单模块（因模块命名冲突故加了了1））
jt-sso（单点登录系统）
重点依赖介绍：
jt的pom.xml文件中引入
SpringBoot框架依赖：
org.springframework.boot
spring-boot-starter-parent
2.3.4.RELEASE
与spring相比，在部署环境中Spring Boot的一些优点包括
- 提供嵌入式容器支持
- 使用命令java -jar独立运行jar
- 在外部容器中部署时，可以选择排除依赖关系以避免潜在的jar冲突
- 部署时灵活指定配置文件的选项
- 用于集成测试的随机端口生成
Spring Boot只是Spring本身的扩展，使开发，测试和部署更加方便。
（1）引入MP（Mybatis-Plus）依赖
com.baomidou
mybatis-plus-boot-starter
3.2.0 ~~~~
MP的宗旨是简化开发，但是它在提供方便的同时却容易造成代码层次混乱，我们可能会把大量数据逻辑写到service层甚至contoller层中，使代码难以阅读。凡事过犹不及，在使用MP时一定要做分析，不要将所有数据操作都交给MP去实现。毕竟MP只是mybatis的增强工具，它并没有侵入mybatis的原生功能，在使用MP的增强功能的同时，原生mybatis的功能依然是可以正常使用的
（2）添加httpClient依赖：
org.apache.httpcomponents
httpclient
在java代理内部可以使用httpClient发起http请求访问服务器获取资源.(工具API)
白话文：可以通过httpClient方式进行跨域跨服务器进行访问获取资源
（3）引入dubbo配置：
com.alibaba.boot
dubbo-spring-boot-starter
0.2.0
dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
面向接口的远程调用：面向公共接口，我们jt项目中有公共的接口项目jt-common，项目分布式结构大概为三个角色：生产者，消费者（jt-web）和公共接口（jt-common）公共的接口业务可以直接从jt-common中直接获取，而消费者可以利用dubbo跨域的方式直接获取生产者返回的数据
负载均衡：在@Reference标签后添加指定的负载均衡策略
@RestController
public class UserController {
//利用dubbo的方式为接口创建代理对象 利用rpc调用
//@Reference(loadbalance = "random") //默认策略 负载均衡随机策略
//@Reference(loadbalance = "roundrobin") //轮询方式
//@Reference(loadbalance = "consistenthash") //一致性hash 消费者绑定服务器提供者
@Reference(loadbalance = "leastactive") //挑选当前负载小的服务器进行访问
private UserService userService;
}服务自动注册和发现：
#关于Dubbo配置
dubbo:
scan:
basePackages: com.jt #指定dubbo的包路径 扫描dubbo注解
application: #应用名称
name: provider-user #一个接口对应一个服务名称 一个接口可以有多个实现
registry: #注册中心 用户获取数据从机中获取 主机只负责监控整个集群 实现数据同步
address: zookeeper://192.168.126.129:2181?backup=192.168.126.129:2182,192.168.126.129:2183
protocol: #指定协议
name: dubbo #使用dubbo协议(tcp-ip) web-controller直接调用sso-Service
port: 20880 #每一个服务都有自己特定的端口 不能重复.在子类项目配置文件application.yml中配置指定的注册中心，本项目中使用的是zookeeper插件进行项目业务的注册和调配；协议中规定了使用dubbo协议（封装了tcp-ip）协议
（4）spring整合redis
redis.clients
jedis
org.springframework.data
spring-data-redis
Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。
一、为什么使用
- 解决应用服务器的cpu和内存压力
- 减少io的读操作，减轻io的压力
- 关系型数据库的扩展性不强，难以改变表结构
二、优点：
- nosql数据库没有关联关系，数据结构简单，拓展表比较容易
- nosql读取速度快，对较大数据处理快
三、适用场景：
- 数据高并发的读写
- 海量数据的读写
- 对扩展性要求高的数据
四、不适场景：
- 需要事务支持（非关系型数据库）
- 基于sql结构化查询储存，关系复杂
redis持久化方式介绍
（1） RDB模式
特点:
1.RDB模式是redis的默认的持久化策略.
2.RDB模式记录的是Redis 内存数据的快照. 最新的快照会覆盖之前的内容 所有RDB持久化文件占用空间更小 持久化的效率更高.
3.RDB模式由于是定期持久化 所以可能导致数据的丢失.
（2） AOF模式
特点：
1.AOF模式默认条件下是关闭的,需要用户手动的开启
- AOF模式是异步的操作 记录的是用户的操作的过程 可以防止用户的数据丢失
- 由于AOF模式记录的是程序的运行状态 所以持久化文件相对较大,恢复数据的时间长.需要人为的优化持久化文件
关于持久化操作的总结
1.如果不允许数据丢失 使用AOF方式
2.如果追求效率 运行少量数据丢失 采用RDB模式
3.如果既要保证效率 又要保证数据 则应该配置redis的集群 主机使用RDB 从机使用AOF
Redis内存策略
（1）### LRU算法：
LRU是Least Recently Used的缩写，即最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。
（2）### LFU算法
LFU（least frequently used (LFU) page-replacement algorithm）。即最不经常使用页置换算法，要求在页置换时置换引用计数最小的页，因为经常使用的页应该有一个较大的引用次数。但是有些页在开始时使用次数很多，但以后就不再使用，这类页将会长时间留在内存中，因此可以将引用计数寄存器定时右移一位，形成指数衰减的平均使用次数。
（3）### RANDOM算法
随机删除数据
（4）### TTL算法
把设定了超时时间的数据将要移除的提前删除的算法
缓存穿透
问题描述: 由于用户高并发环境下访问 数据库中不存在的数据时 ,容易导致缓存穿透.
如何解决: 设定IP限流的操作 nginx中 或者微软服务机制 API网关实现.
缓存击穿
问题描述: 由于用户高并发环境下, 由于某个数据之前存在于内存中,但是由于特殊原因(数据超时/数据意外删除)导致redis缓存失效. 而使大量的用户的请求直接访问数据库.
俗语: 趁他病 要他命
如何解决:
1.设定超时时间时 不要设定相同的时间.
2.设定多级缓存
缓存雪崩
说明: 由于高并发条件下 有大量的数据失效.导致redis的命中率太低.而使得用户直接访问数据库(服务器)导致奔溃,称之为缓存雪崩.
解决方案:
1.不要设定相同的超时时间 随机数
2.设定多级缓存.
3.提高redis缓存的命中率 调整redis内存优化策略 采用LRU等算法.