淄博企业网站建设哪家好今天的新闻 最新消息
Mysql
mysql事务
共享锁与排他锁
共享锁：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。（读都允许读，但我在读不允许你去改）
排他锁：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。（我在修改数据，别的操作都被禁止）
事务特性
事务四个特性：ACID
- 原子性（Atomicity）：指事务是一个不可分割的最小工作单位，事务中的操作只有都发生和都不发生两种情况
- 一致性（Consistency）：数据库总是从一个一致性的状态转换到另外一个一致性的状态。
- 隔离性（Isolation）：一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
- 持久性（Durability）：一个事务一旦提交成功，它对数据库中数据的改变将是永久性的，接下来的其他操作或故障不应对其有任何影响。
如何实现这些特性
- 原子性：靠Undo log实现，即如果一个事务异常或执行失败后进行回滚
- 当事务对数据库进行修改时，InnoDB会生成对应的 undo log；
- 如果事务执行失败或调用了 rollback，导致事务需要回滚，便可以利用 undo log 中的信息将数据回滚到修改之前的样子。
- undo log 属于逻辑日志，它记录的是sql执行相关的信息。
- 当发生回滚时，InnoDB 会根据 undo log 的内容做与之前相反的工作
- 一致性：事务的最终目的，即需要数据库层面保证，又需要应用层面进行保证，并且MySQL底层通过两阶段提交事务保证了事务持久化时的一致性。
- 隔离性：靠锁和MVCC实现
- 锁：
- 在 InnoDB 事务中，行锁通过给索引上的索引项加锁来实现。
- 只有通过索引条件检索数据，InnoDB才使用行级锁，否则将使用表锁。
- 行级锁定同样分为两种类型：共享锁和排他锁
- 使用Record Lock和Gap Lock（解决幻读）
- MVCC：多版本并发控制
- DB_TRX_ID：事务 ID，是根据事务产生时间顺序自动递增的
- DB_ROLL_PTR：回滚指针，本质上就是一个指向记录对应的undo log的一个指针，InnoDB 通过这个指针找到之前版本的数据
- MVCC在事务开启时会为事务生成一个ID，并且在查询时生成一个快照，能看到当前活跃的事务，然后通过比较快照的生成时间和活跃事务的提交时间进行对比，判断读取哪个版本的数据。
- 锁：
- 持久性：靠Redo log实现
- mysq|修改数据的时候会在redo log中记录一份日志数据，就算数据没有保存成功，只要日志保存成功了，数据仍然不会丢失
- 当一条数据需要更新时,InnoDB会先将数据更新，然后记录redoLog 在内存中，然后找个时间将redoLog的操作执行到磁盘上的文件上。
mysql隔离级别
mysql具有四种隔离级别
| 隔离级别 | 说明 |
|---|---|
| 读未提交 | 一个事务还没提交时，它做的变更就能被别的事务看到 |
| 读已提交 | 一个事务提交之后，它做的变更才会被其他事务看到 |
| 一个事务提交之后，它做的变更才会被其他事务看到 | 一个事务中，对同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。InnoDB默认级别 |
| 串行化 | 事务串行化执行，每次读都需要获得表级共享锁，读写相互都会阻塞，隔离级别最高，牺牲系统并发性。 |
不同的隔离级别是为了解决不同的问题。也就是脏读、幻读、不可重复读。
| 问题 | 说明 |
|---|---|
| 脏读 | 读到了其他事务未提交的数据 |
| 不可重复读 | 在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据出现不一致的情况 |
| 幻读 | 在一个事务中，后续读取的数据，在最开始读取的数据中不存在 |
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交 | 可以出现 | 可以出现 | 可以出现 |
| 读已提交 | 不允许出现 | 可以出现 | 可以出现 |
| 一个事务提交之后，它做的变更才会被其他事务看到 | 不允许出现 | 不允许出现 | 可以出现 |
| 串行化 | 不允许出现 | 不允许出现 | 不允许出现 |
Mysql和MangoDB的比较
Mysql：
- 关系数据库系统，相关信息可能存储在单独的表中，但通过使用关联查询来关联。通过使用这种方式，使得数据重复量被最小化。
- 关系型数据库的最大特点就是事务的一致性
- 为了维护一执行需要消耗大量的性能
MangoDB：
- 少量数据时，数据存在内存中。当内存不够时，只将热点数据放在内存，其他存入磁盘
- 数据存储在类似JSON的文档中，并且文档中每个json串结构可能有所不同
- 使用动态模式，这意味着您可以在不首先定义结构的情况下创建记录，例如字段或其值的类型
- 支持多种存储格式（mysql只支持基本类型）
- 设计了高可用性和可扩展性，并提供了即用型复制和自动分片功能。
- 简化了开发，因为 MongoDB 文档自然映射到现代的面向对象编程语言。使用 MongoDB 可以避免将代码中的对象转换为关系表的复杂对象关系映射（ORM）层。
sql优化
select *浪费资源，减少使用，且不走索引union all比union更快（但是不去重）- 小表驱动大表：大表
in小表 ； 小表exists大表； - 批量插入数据尽量使用
insertBatch，而不是循环（循环会多次请求数据库） - 多使用
limit，减少内存消耗 - 海量数据查询分页，使用条件查询结合
limt size，去替代limit start size - 使用连接查询代替子查询（子查询会为子查询额外创建一个表）
join的表不能太多，否则容易选错索引- 索引不宜太多，因为在增删改查的时候都需要更新索引表（使用联合索引）
- 将
group by后接的having条件适当提到前面的where中
Spring
maven中版本 版本冲突
maven依赖中不允许存在两个不同版本的同名依赖。（添加<exclusion>标签来解决冲突）
Kafka
Kafka和其他消息队列对比
| 对比 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 优先级队列 | 不支持 | 通过建立不同的队列 | 通过建立不同的队列 |
| 延迟队列 | 不支持 | 基于队列的延迟 | 基于队列的延迟 |
| 死信队列 | 不支持 | 支持 | 支持 |
| 消费模式 | pull | pull/push | pull/push |
| 广播模式 | 发布订阅 | 发布订阅 | 点对点 （但可以由交换机实现发布订阅模式） |
| 消息回溯 | offset和timestamp | 按时间回溯 | 不支持 |
| 消息堆积&持久化 | 磁盘堆积：所有消息都存在磁盘 每个partition对应一个或多个segment file | 基于磁盘存储 使用commit Log存储消息（顺序写到文章末尾） 后台异步线程同步到consumerQueue 使用内存映射文件加速消息读取 | 内存堆积（换页操作存储到磁盘） （或使用惰性队列将消息持久化到磁盘） |
| 流量控制 | 支持client和user级别 | 多种维度的流量控制 | 流量控制基于credit-base算法，是内部被动触发的保护机制，作用于生产者层面 |
| 顺序性消息 | 同分区内有序 | Broker消息队列锁（分布式锁） Consumer消息队列锁（本地锁） Consumer消息处理队列消费锁（本地锁） | 无法保证全局有序 |