java录音01汇总

java录音01汇总

• RabbitMQ（消息队列）
• • MQ之间的区别:
  • 主要组成
  • 工作模式：5种
  • 路由规则：4种
  • RabbitmQ消息一致性的问题
  • • 消息丢失：
    • • • 生产者
        • 消息队列
        • 消费者
        • 不重复消费：
        • • 可以和redis一起使用
• Redis
• • redis用来做什么？
  • redis的持久化机制
  • • RDB
    • AOF
  • aof的重写机制？
  • • 为什么重写aof可以变小
  • rdb和aof的混合模式：
  • rdb会丢失数据吗？
• Mysql
• • mysql的存储引擎
  • • 俩者的区别：
    • 应用场景
    • 他们俩个的锁一样吗？
    • mysql的优化 (八种)
    • 索引最左匹配原则

RabbitMQ（消息队列）

主要的作用是

解耦

异步

削峰

分布式事务

MQ之间的区别:

ActiveMQ———数据量不大的话可以使用这个

kakafa——与RabbitMQ的不同是 Rabbit是消费完之后队列中的消息就被删除掉，Ka是通过设置expire时间 时间到期之后才删除。 他的压力均摊到各个节点，可以通过增加节点来减少压力

rocketMq（阿里的）——不是开源的 优点：吞吐量大，

主要组成

生产者 交换机 队列 消费者 这四个组成

工作模式：5种

简单模式：1 v 1

work：1 v n 每个消费者获取到的消息唯一（只能有一个收到消息）

订阅: 1 v n （可以有多个收到消息）

路由: 发送的消息到交换机并指定key 消费者将队列绑定到交换机时，需要指定路由key

topic ：同路由模式相似，但是routingkey的匹配是通过通配符决定的，路由模式是相等才匹配
设置交换机类型为Topics即可

路由规则：4种

1.direct —— 根据路由关键字完全匹配队列名

1. 直连

2.fanout —— 发送到所有绑定的队列

2. 群发

3.topic —— 根据路由关键字进行通配符匹配

3. 主题

topic的定义规则：

• 由一些单词用点号.连接（单词可以任意文本，但通常要体现出消息的特征）；
• 支持通配符

*（星号）仅代表一个单词

#（井号）代表任意个单词

• 总长度不能超过255个字节

举例说明：

示例的topic由三段组成：<quick|lazy>.<颜色>.<物种>

a.当路由关键字=“quick.orange.rabbit”，Q1和Q2都接收到消息(规则1&2)；

b.当路由关键字=“lazy.orange.elephant”，Q1和Q2都接收到消息(规则1&3)；

c.当路由关键字=“quick.orange.fox”，Q1接收到消息(规则1)；

d.当路由关键字=“lazy.brown.fox”，Q2接收到消息(规则3)；

e.当路由关键字=“lazy.pink.rabbit”，Q2接收到消息(规则2&3)；消息只会到一次；

f.当路由关键字=“quick.brown.fox”，消息将被丢弃；

g.当路由关键字=“lazy.orange.male.rabbit”，Q2接收到消息(规则3)；

4.headers —— 可看作topic的增强版。路由关键字是一组键值对，通过多组条件组合匹配。

4. 头部

4.

RabbitmQ消息一致性的问题

消息丢失：

生产者

开启事务 成功提交事务

​ 失败重新回滚事务 直到成功提交事务

confirm 开启之后，每次写的消息都会分配一个唯一id（这个id一直到消息删除）ack，如果写入到我们的MQ当中，我们就返回一个OK，如果没能处理就返回一个nack接口（告诉你失败，可以重试了）

为了保证这个时长，我们可以自己去设置一定时间，如果时间内没收到就回调，重新尝试。

消息队列

持久化 ——消息持久化带磁盘当中

​ 队列持久化（创建持久化队列）

​ 消息持久化（发送消息时将消息的deliveryMode设置为2 ）

可以和确认机制联合使用：

只有消息被持久化到磁盘之后，才会通知生产者ack

消费者

手动确认机制（ack机制）

如果MQ等待一段时间后消费者没有发送回来 处理完成的信息 那么MQ默认你还没处理完，这个时候就会把这个消息分配给别的消费者去处理 ，以此来保证消息不会丢

不重复消费：

可以和redis一起使用

给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可

指定唯一ID

Redis

redis用来做什么？

他可以存储一些不经常修改的数据（不直接访问我们的数据库）

这样的设计可以减小我们数据库的压力

redis的持久化机制

RDB

rdb快照:默认五分钟，做一次（二进制）快照（同步到硬盘）

好处：定期备份，可以还原各个阶段

坏处：默认时间内宕机，就会丢失这五分钟的数据

AOF

aof日志：默认每秒持久化一次。（同步到文件/追加命令增加到1个日志文件中）

好处：最多丢失1秒的数据

坏处：体积太大，占用空间大，影响redis的性能

aof的重写机制？

为了解决aof文件越来越大的问题，可以使用我们的aof的重写机制。

可以压缩aof的体积，（越小的aof文件可以更快的被redis加载）

为什么重写aof可以变小

清除了一些无效命令

进程内超时数据不再写入aof（清除 了超时数据）

多条写命令可以合并为批量写命令

rdb和aof的混合模式：

优点：既能快速备份又能避免大量数据丢失
缺点：RDB是压缩格式，AOF在读取它时可读性教差

rdb会丢失数据吗？

会

Mysql

mysql的存储引擎

Mylsam

innodb

俩者的区别：

MyIsam 不支持事务和外键 非计数

innodb 支持事务默认的存储 数据和索引放在同一种表中

• MyISAM是非事务安全型的，而InnoDB是事务安全型的。
• MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
• MyISAM支持全文类型索引，而InnoDB不支持全文索引。
• MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
• MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
• InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablename type=innodb）。

应用场景

• MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。（查询）

• InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。（增加修改）

他们俩个的锁一样吗？

（1）myisam只支持表锁：
● 共享锁（读锁、s锁）：其他线程操作可以读，但不能写。
● 排他锁（写锁、x锁） ：其他线程操作不能读取，也不能写。

（2）InnoDB 支持行锁和表锁，默认行锁（基于索引实现，需用事务操作）：
● 共享锁（读锁、s锁）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
● 排他锁（写锁、x锁）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁，同时也会阻止同一行的update操作（update操作会自动加锁）。

mysql的优化 (八种)

1. 选取最适用的字段属性 （提高效率可以尽量把字段设置为not null）(文本字段可以定义为enum类型来提高效率)
2. 使用连接（join）代替子查询 （有些时候这样更快，效率更高）
3. 使用联合（Union）代替手动创建的临时表（会话结束，删除临时表但联合表是把多个查询语句连接下来）
4. 事务（要么语句块中每条语句都操作成功，要么都失败/保证一致性和完整性）
5. 锁定表
6. 使用外键
7. 使用索引
8. 优化查询语句

sql优化

整体慢，可以考虑做集群（加宽带，主从复制）

个别sql慢（慢sql）首先可以考虑慢查询日志，把查询比较慢的sql，记录到日志中，然后根据每条数据进行分析优化。

分析sql:

去掉无关的表或者字段

可以简单拆分成多个sql查询，看能否提供效率

执行解释计划explain sql ；分析索引是否合理，那些地方影响了查询效率。针对性的去分析解决。

比如：like 双边匹配查询，函数，is null 等都会造成索引失效 ，导致全表查询。

索引最左匹配原则

最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、%like)就会停止匹配。

联合索引 abc 创建了一个组合索引 现在使用bc来查 我可以用到组合索引吗？