MyBatis.Redis.+mysql.mycat

MyBatis/Redis/+mysql/mycat

1.Mybatis优缺点

优点：

1、基于 SQL 语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL 写在XML 里，解除 sql 与程序代码的耦合，便于统一管理；提供 XML 标签， 支持编写动态 SQL 语句， 并可重用。

2、与 JDBC 相比，减少了 50%以上的代码量，消除了 JDBC 大量冗余的代码，不需要手动开关连接；

3、很好的与各种数据库兼容（ 因为 MyBatis 使用 JDBC 来连接数据库，所以只要JDBC 支持的数据库MyBatis 都支持）。

4、能够与 Spring 很好的集成；

5、提供映射标签， 支持对象与数据库的 ORM 字段关系映射； 提供对象关系映射标签， 支持对象关

系组件维护。

缺点：

    1、SQL 语句的编写工作量较大， 尤其当字段多、关联表多时， 对开发人员编写SQL 语句的功底有一定要求。

2、SQL 语句依赖于数据库， 导致数据库移植性差， 不能随意更换数据库。

2. MyBatis 中 #{}和 ${}的区别是什么

#{}是预编译处理，${}是字符替换。 在使用 #{}时，MyBatis 会将 SQL 中
的 #{}替换成“?”，配合 PreparedStatement 的 set 方法赋值，这样可以有
效的防止 SQL 注入，保证程序的运行安全。

3.MyBatis 有几种分页方式

分页方式：逻辑分页和物理分页。

逻辑分页： 使用 MyBatis 自带的 RowBounds 进行分页，它是一次性查询很
多数据，然后在数据中再进行检索。

物理分页：自己手写 SQL 分页或使用分页插件 PageHelper，去数据库查询指
定条数的分页数据的形式。

 逻辑分页是一次性查询很多数据，然后再在结果中检索分页的数据。这样
做弊端是需要消耗大量的内存、有内存溢出的风险、对数据库压力较大。
 物理分页是从数据库查询指定条数的数据，弥补了一次性全部查出的所有
数据的种种缺点，比如需要大量的内存，对数据库查询压力较大等问题。

4.说一下 MyBatis 的一级缓存和二级缓存

 一级缓存：基于 PerpetualCache 的 HashMap 本地缓存，它的声明周
期是和 SQLSession 一致的，有多个 SQLSession 或者分布式的环境中
数据库操作，可能会出现脏数据。当 Session flush 或 close 之后，该
Session 中的所有 Cache 就将清空，默认一级缓存是开启的。
 二级缓存：也是基于 PerpetualCache 的 HashMap 本地缓存，不同在
于其存储作用域为 Mapper 级别的，如果多个 SQLSession 之间需要共
享缓存，则需要使用到二级缓存，并且二级缓存可自定义存储源，如
Ehcache。默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类
需要实现 Serializable 序列化接口(可用来保存对象的状态)。
开启二级缓存数据查询流程：二级缓存 -> 一级缓存 -> 数据库。
缓存更新机制：当某一个作用域(一级缓存 Session/二级缓存 Mapper)进行了
C/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。

5. Redis

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。

Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rA5m2mhB-1629621711556)(image/image.png)]

6.Redis优缺点

优点

• 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。

• 支持数据持久化，支持AOF和RDB两种持久化方式。

• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。

• 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

7.Redis为什么这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路 I/O 复用模型，非阻塞 IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

8.Redis持久化

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:

RDB：是Redis DataBase缩写快照

RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

优点：

• 1、只有一个文件 dump.rdb，方便持久化。

• 2、容灾性好，一个文件可以保存到安全的磁盘。

• 3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能

• 4.相对于数据集大时，比 AOF 的启动效率更高。

缺点：

• 1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)

• 2、AOF（Append-only file)持久化方式：是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。

AOF：持久化

AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

优点：

• 1、数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。

• 2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。

• 3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：

• 1、AOF 文件比 RDB 文件大，且恢复速度慢。

• 2、数据集大的时候，比 rdb 启动效率低。

总结：

• AOF文件比RDB更新频率高，优先使用AOF还原数据。

• AOF比RDB更安全也更大

• RDB性能比AOF好

• 如果两个都配了优先加载AOF

9.哨兵模式

entinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。

• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。

• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。

• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。

• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

• 哨兵至少需要 3 个实例，来保证自己的健壮性。

• 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

• 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hifCSqm1-1629621711558)(image/image_1.png)]

10.Redis 主从架构

单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。

如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，

同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，

接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。

slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

缓存雪崩、缓存穿透、缓存击穿

1.缓存穿透：指的是缓存中没有数据，mysql中也没有数据，就会一直访问Mysql

    解决：1，在缓存中给这个查询的东西存个null值。2.使用布隆过滤器

2. 缓存击穿：大量访问的时候，由于缓存过期，请求都打击到mysql中

    解决 ：1.加锁。只让一个去mysql访问。2.设置热点数据永不过期

3.缓存雪崩：

解决 ：1.高可用，多添加几台redis,

    2.限流降级

    3.数据预热，先把一些热点数据放到缓存中并设置过期时间

11.Mysql的锁

按锁粒度分类：

1. ⾏锁：锁某⾏数据，锁粒度最⼩，并发度⾼

2. 表锁：锁整张表，锁粒度最⼤，并发度低

3. 间隙锁：锁的是⼀个区间

还可以分为：

1. 共享锁：也就是读锁，

⼀个事务给某⾏数据加了读锁，其他事务也可以读，但是不能写

1. 排它锁：也就是写锁，

⼀个事务给某⾏数据加了写锁，其他事务不能读，也不能写

还可以分为：

1. 乐观锁：并不会真正的去锁某⾏记录，⽽是通过⼀个版本号来实现的

2. 悲观锁：上⾯所的⾏锁、表锁等都是悲观锁

12.Mysql 事务是如何实现的

原子性：通过undo log实现的。每条数据变更都伴随一条undo log日志的生成，当系统发生错误或执行回滚根据undo log做逆向操作
持久性：通过redo log实现的。redo log记录了数据的修改日志。数据持久化到磁盘，先是储存到缓冲池里，然后缓冲池中的数据定期同步到磁盘中，如果系统宕机，可能会丢失数据，系统重启后会读取redo log恢复数据
隔离性：mysql数据库通过MVCC + next-key机制实现了隔离性
一致性：以上3大特性，保障了事务的一致性

隔离性有4个隔离级别，分别是：
read uncommit 读未提交，可能会读到其他事务未提交的数据，也叫做脏读。
用户本来应该读取到id=1的用户age应该是10，结果读取到了其他事务还没有提交的事务，结果读
取结果age=20，这就是脏读。
read commit 读已提交，两次读取结果不一致，叫做不可重复读。
不可重复读解决了脏读的问题，他只会读取已经提交的事务。
用户开启事务读取id=1用户，查询到age=10，再次读取发现结果=20，在同一个事务里同一个查
询读取到不同的结果叫做不可重复读。
repeatable read 可重复复读，这是mysql的默认级别，就是每次读取结果都一样，但是有可能产
生幻读。
serializable 串行，一般是不会使用的，他会给每一行读取的数据加锁，会导致大量超时和锁竞争
的问题。

13.InnoDB存储引擎的锁的算法

Record lock：单个行记录上的锁

Gap lock：间隙锁，锁定一个范围，不包括记录本身

Next-key lock：record+gap 锁定一个范围，包含记录本身

相关知识点：

1. innodb对于行的查询使用next-key lock

2. Next-locking keying为了解决Phantom Problem幻读问题

3. 当查询的索引含有唯一属性时，将next-key lock降级为record key

4. Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生

5. 有两种方式显式关闭gap锁：（除了外键约束和唯一性检查外，其余情况仅使用record lock） A.

将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1

14.ACID靠什么保证的

A原子性由undo log日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的sql
C一致性由其他三大特性保证、程序代码要保证业务上的一致性

I隔离性由MVCC来保证
D持久性由内存+redo log来保证，mysql修改数据同时在内存和redo log记录这次操作，宕机的时候可以从redo log恢复

15,mysql中索引类型及对数据库的性能的影响

普通索引：允许被索引的数据列包含重复的值。
唯一索引：可以保证数据记录的唯一性。
主键：是一种特殊的唯一索引，在一张表中只能定义一个主键索引，主键用于唯一标识一条记录，使用
关键字 PRIMARY KEY 来创建。
联合索引：索引可以覆盖多个数据列，如像INDEX(columnA, columnB)索引。
全文索引：通过建立 倒排索引 ,可以极大的提升检索效率,解决判断字段是否包含的问题，是目前搜索引
擎使用的一种关键技术。可以通过ALTER TABLE table_name ADD FULLTEXT (column);创建全文索引
索引可以极大的提高数据的查询速度。
通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
但是会降低插入、删除、更新表的速度，因为在执行这些写操作时，还要操作索引文件
索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚
簇索引，那么需要的空间就会更大，如果非聚集索引很多，一旦聚集索引改变，那么所有非聚集索引都
会跟着变。

16.负载均衡算法、类型

1、轮询法
将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2、随机法
通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。
3、源地址哈希法
源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
4、加权轮询法
不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
5、加权随机法
与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。
6、最小连接数法
最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

类型：
DNS 方式实现负载均衡
硬件负载均衡：F5 和 A10
软件负载均衡：
Nginx 、 HAproxy 、 LVS 。其中的区别：
Nginx ：七层负载均衡，支持 HTTP、E-mail 协议，同时也支持 4 层负载均衡；
HAproxy ：支持七层规则的，性能也很不错。OpenStack 默认使用的负载均衡软件就是
HAproxy；
LVS ：运行在内核态，性能是软件负载均衡中最高的，严格来说工作在三层，所以更通用一些，适用各种应用服务。

17.分布式架构下，Session 共享有什么方案

方案

1、采用无状态服务，抛弃session

2、存入cookie（有安全风险）
3、服务器之间进行 Session 同步，这样可以保证每个服务器上都有全部的 Session 信息，不过当服务器数量比较多的时候，同步是会有延迟甚至同步失败；
4、 IP 绑定策略
使用 Nginx （或其他复杂均衡软硬件）中的 IP 绑定策略，同一个 IP 只能在指定的同一个机器访问，但是这样做失去了负载均衡的意义，当挂掉一台服务器的时候，会影响一批用户的使用，风险很大；
5、使用 Redis 存储
把 Session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：

• 实现了 Session 共享；
  * 可以水平扩展（增加 Redis 服务器）；
  服务器重启 Session 不丢失（不过也要注意 Session 在 Redis 中的刷新/失效机制）；
  不仅可以跨服务器 Session 共享，甚至可以跨平台（例如网页端和 APP 端）。

18.Mycat

-  一个彻底开源的，面向企业应用开发的大数据库集群
-  支持事务、ACID、可以替代MySQL的加强版数据库
-  一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
-  一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
-  结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
-  一个新颖的数据库中间件产品

基于心跳的自动故障切换，支持读写分离，支持MySQL主从，以及galera cluster集群

19。Mycat原理

Mycat的原理中最重要的一个动词是“拦截 ”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。

当Mycat收到一个SQL时，会先解析这个SQL，查找涉及到的表，然后看此表的定义，如果有分片规则，则获取到SQL里分片字段的值，并匹配分片函数，得到该SQL对应的分片列表，然后将SQL发往这些分片去执行，最后收集和处理所有分片返回的结果数据，并输出到客户端。以select * from Orders where prov=?语句为例，查到prov=wuhan，按照分片函数，wuhan返回dn1，于是SQL就发给了MySQL1，去取DB1上的查询结果，并返回给用户。

如果上述SQL改为select * from Orders where prov in (‘wuhan’,‘beijing’)，那么，SQL就会发给MySQL1与MySQL2去执行，然后结果集合并后输出给用户。但通常业务中我们的SQL会有Order By 以及Limit翻页语法，此时就涉及到结果集在Mycat端的二次处理，这部分的代码也比较复杂，而最复杂的则属两个表的Jion问题，为此，Mycat提出了创新性的ER分片、全局表、HBT（Human Brain Tech)人工智能的Catlet、以及结合Storm/Spark引擎等

20.Mycat应用场景

Mycat发展到现在，适用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是几个典型的应用场景：
-   单纯的读写分离，此时配置最为简单，支持读写分离，主从切换；
-   分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片；
-   多租户应用，每个应用一个库，但应用程序只连接Mycat，从而不改造程序本身，实现多租户化；
-   报表系统，借助于Mycat的分表能力，处理大规模报表的统计；
-   替代Hbase，分析大数据；
-   作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择；
-   Mycat长期路线图；
-   强化分布式数据库中间件的方面的功能，使之具备丰富的插件、强大的数据库智能优化功能、全面的系统监控能力、以及方便的数据运维工具，实现在线数据扩容、迁移等高级功能；
-   进一步挺进大数据计算领域，深度结合Spark Stream和Storm等分布式实时流引擎，能够完成快速的巨表关联、排序、分组聚合等 OLAP方向的能力，并集成一些热门常用的实时分析算法，让工程师以及DBA们更容易用Mycat实现一些高级数据分析处理功能。
-   不断强化Mycat开源社区的技术水平，吸引更多的IT技术专家，使得Mycat社区成为中国的Apache，并将Mycat推到Apache
基金会，成为国内顶尖开源项目，最终能够让一部分志愿者成为专职的Mycat开发者，荣耀跟实力一起提升。