EasyExcel（报表导出）
技术方案Java解析、生成Excel比较经典的技术是Apache poi，但它存在一个严重的问题就是非常的耗内存
基于这种情况，阿里团队就开发了一个新的技术，叫EasyExcel，它解决了耗费内存的问题
官网：https://easyexcel.opensource.alibaba.com/
读取Excel本小节来研究读取一个Excel文件中的内容
参考网址 https://easyexcel.opensource.alibaba.com/docs/current/quickstart/read
输出Excel本小节来研究写出一个Excel文件中的内容
https://easyexcel.opensource.alibaba.com/docs/current/quickstart/write
填充Excel本小节来研究填充一个Excel文件中的内容
https://easyexcel.opensource.alibaba.com/docs/current/quickstart/fill
上传和下载本小节来研究Excel文件的上传和下载
https://easyexcel.open ...
XXL-JOB
XXL-JOB介绍为了程序更具备健壮性，需要使用定时任务更新缓存
可以用来做定时任务的框架有很多，常见的有：
SpringTask：单节点定时任务框架，只能用在单体项目中
XXL-JOB：分布式定时任务框架，适用于单体项目和分布式项目
XXL-JOB是一个轻量级分布式任务调度平台，它的主要角色有两个：
调度中心：负责按照调度配置发出调度请求，主要职责为执行器管理、任务管理、监控运维、日志管理等
任务执行器：负责接收调度请求并执行任务逻辑；主要职责是执行任务、执行结果上报、日志服务等
安装接下来根据官方提供的文档开始安装xxl-job：分布式任务调度平台XXL-JOB
使用XXL-JOB的使用主要就是分为两步：
在代码端编写定时任务要执行的代码
在控制端配置代码的执行时机和其他信息
编写代码端
导入准备好的演示工程
准备好要执行的任务代码
修改配置文件
配置控制端
配置执行器：在任务调度中心，点击进入”执行器管理”界面，添加执行器
AppName：执行器的唯一标识，不能重复
名称：执行的名称
注册方式：调度中心获取执行器地址的方式
机器地址：执行器的地址，当注册方 ...
Jmeter快速入门
Jmeter快速入门1.安装JmeterJmeter依赖于JDK，所以必须确保当前计算机上已经安装了JDK，并且配置了环境变量。
1.1.下载可以Apache Jmeter官网下载，地址：http://jmeter.apache.org/download_jmeter.cgi
当然，我们课前资料也提供了下载好的安装包：
1.2.解压因为下载的是zip包，解压缩即可使用，目录结构如下：
其中的bin目录就是执行的脚本，其中包含启动脚本：
1.3.运行双击即可运行，但是有两点注意：
启动速度比较慢，要耐心等待
启动后黑窗口不能关闭，否则Jmeter也跟着关闭了
2.快速入门2.1.设置中文语言默认Jmeter的语言是英文，需要设置：
效果：
注意：上面的配置只能保证本次运行是中文，如果要永久中文，需要修改Jmeter的配置文件
打开jmeter文件夹，在bin目录中找到 jmeter.properties，添加下面配置：
1language=zh_CN
注意：前面不要出现#，#代表注释，另外这里是下划线，不是中划线
2.2.基本用法在测试计划上点鼠标右键，选择 ...
Canal
Canal的工作原理
Canal伪装自己为MySQL的从节点，向MySQL主节点发送dump协议
MySQL主节点一旦收到dump请求，开始推送binlog给canal
Canal会接收并解析这些变更事件并解析binlog，并发送到其它服务器（比如es、redis等等）
环境安装MySQL-Canal-MQ-ES的环境基本已经配置完毕
配置Mysql
在MySQL中需要创建一个用户，并授权
123456789101112131415# 进入mysql容器docker exec -it mysql /bin/bash# 使用命令登录mysql -u root -p# 创建用户 用户名：canal 密码：canalcreate user 'canal'@'%' identified WITH mysql_native_password by 'canal';# 授权# SELECT：允许用户查询（读取）数据库中的数据# REPLICATION SLAVE：允许用户作为 MySQL 复制从库，用于同步主库的数据# ...
ElasticSearch
前情提要黑马商城作为一个电商项目，商品的搜索肯定是访问频率最高的页面之一。目前搜索功能是基于数据库的模糊搜索来实现的，存在很多问题
首先，查询效率较低
由于数据库模糊查询不走索引，在数据量较大的时候，查询性能很差。黑马商城的商品表中仅仅有不到9万条数据，基于数据库查询时，搜索接口的表现如图：
改为基于搜索引擎后，查询表现如下：
需要注意的是，数据库模糊查询随着表数据量的增多，查询性能的下降会非常明显，而搜索引擎的性能则不会随着数据增多而下降太多。目前仅10万不到的数据量差距就如此明显，如果数据量达到百万、千万、甚至上亿级别，这个性能差距会非常夸张。
其次，功能单一
数据库的模糊搜索功能单一，匹配条件非常苛刻，必须恰好包含用户搜索的关键字。而在搜索引擎中，用户输入出现个别错字，或者用拼音搜索、同义词搜索都能正确匹配到数据。
综上，在面临海量数据的搜索，或者有一些复杂搜索需求的时候，推荐使用专门的搜索引擎来实现搜索功能。
目前全球的搜索引擎技术排名如下：
初识elasticsearchElasticsearch的官方网站如下：Elasticsearch：官方分布式搜索和 ...
RabbitMQ
微服务一旦拆分，必然涉及到服务之间的相互调用，而目前服务之间调用采用的都是基于OpenFeign的调用。这种调用中，调用者发起请求后需要等待服务提供者执行业务返回结果后，才能继续执行后面的业务。也就是说调用者在调用过程中处于阻塞状态，因此称这种调用方式为同步调用，也可以叫同步通讯。但在很多场景下，需要采用异步通讯的方式，为什么呢？
先来看看什么是同步通讯和异步通讯。如图：
解读：
同步通讯：就如同打视频电话，双方的交互都是实时的。因此同一时刻只能跟一个人打视频电话
异步通讯：就如同发微信聊天，双方的交互不是实时的，你不需要立刻给对方回应。因此你可以多线操作，同时跟多人聊天
两种方式各有优劣，打电话可以立即得到响应，但是却不能跟多个人同时通话。发微信可以同时与多个人收发微信，但是往往响应会有延迟
所以，如果某个业务需要实时得到服务提供方的响应，则应该选择同步通讯（同步调用）
而如果追求更高的效率，并且不需要实时响应，则应该选择异步通讯（异步调用）
初识MQ同步调用之前基于OpenFeign的调用都属于是同步调用，那么这种方式存在哪些问题呢？
举个例子，以余额支付功能为例来分析，首 ...
Redis面试篇
Redis主从单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离
主从集群结构下图就是一个简单的Redis主从集群结构：
搭建主从集群在同一个虚拟机中利用3个Docker容器来搭建主从集群，容器信息如下：
容器名
角色
IP
映射端口
r1
master
192.168.150.101
7001
r2
slave
192.168.150.101
7002
r3
slave
192.168.150.101
7003
启动多个Redis实例利用课前资料提供的docker-compose文件来构建主从集群：
文件内容如下：
123456789101112131415161718version: "3.2"services: r1: image: redis:6.2.7 container_name: r1 network_mode: "host" entrypoint: ["redis-server", "-- ...
Sentinel
在微服务远程调用的过程中，还存在几个问题需要解决
首先是业务健壮性问题：
例如在之前的查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服务时，是不是也会异常？从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息
还有级联失败问题：
还是查询购物车的业务，假如商品服务业务并发较高，占用过多Tomcat连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败
此时查询购物车业务需要查询并等待商品查询结果，从而导致查询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的Tomcat连接占用较多，所有接口的响应时间都会增加，整个服务性能很差， 甚至不可用
依次类推，整个微服务群中与购物车服务、商品服务等有调用关系的服务可能都会出现问题，最终导致整个集群不可用
这就是级联失败问题，或者叫雪崩问题
还有跨服务的事务问题：
比 ...
Seata
分布式事务项目中的下单业务整体流程如下：
由于订单、购物车、商品分别在三个不同的微服务，而每个微服务都有自己独立的数据库，因此下单过程中就会跨多个数据库完成业务。而每个微服务都会执行自己的本地事务：
交易服务：下单事务
购物车服务：清理购物车事务
库存服务：扣减库存事务
整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。最终必须保证整个全局事务同时成功或失败
默认情况下，微服务之间的事务管理是独立的。也就是说，如果某个微服务模块发生了回滚，但此时其他微服务模块是无法知道的，并不会同时进行回滚操作
做一个测试，先进入购物车页面：
目前有4个购物车，然结算下单，进入订单结算页面：
然后将购物车中某个商品的库存修改为0：
然后，提交订单，最终因库存不足导致下单失败：
然后去查看购物车列表，发现购物车数据依然被清空了，并未回滚：
认识Seata解决分布式事务的方案有很多，但实现起来都比较复杂，因此一般会使用开源的框架来解决分布式事务问题。在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在 ...
SpringCloud
认识微服务单体架构单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单
当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式
但随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：
团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支，你绝对会陷入到解决冲突的泥潭之中
系统发布效率低：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时
系统可用性差：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用
微服务架构微服务架构，首先是服务化，就是**将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务**。同时要满 ...