部分内容整理自：

面试必问：分布式事务六种解决方案 - 知乎 (zhihu.com)
10分钟说透Saga分布式事务 - 云+社区 - 腾讯云 (tencent.com)

1. 事务的ACID

• 原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。
• 一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。
• 隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
• 持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

2. Redis的事务

部分内容整理自：

https://www.cnblogs.com/yiwangzhibujian/p/7047458.html
https://blog.csdn.net/striveb/article/details/95110502
https://mp.weixin.qq.com/s/2OTVJUTLOetYTD4Hpk-hFA
https://juejin.cn/post/6844903663224225806

1. Redis为啥这么快

• 纯内存操作

  • Redis是一个KV内存数据库，它内部构建了一个哈希表，根据指定的KEY访问时，只需要O(1)的时间复杂度就可以找到对应的数据。同时，Redis提供了丰富的数据类型，并使用高效的操作方式进行操作，这些操作都在内存中进行，并不会大量消耗CPU资源，所以速度极快。

    

• 单线程

  • Redis Server是多线程的，只是它的请求处理整个流程是单线程处理的
  • 单线程的方式是无法发挥多核CPU 性能，不过可以通过在单机开多个Redis 实例来完善
  • 优势
    • 没有了多线程上下文切换的性能损耗
    • 没有了访问共享资源加锁的性能损耗
    • 开发和调试非常友好，可维护性高
  • 缺点
    • 单线程处理最大的缺点就是，如果前一个请求发生耗时比较久的操作，那么整个Redis就会阻塞住，其他请求也无法进来，直到这个耗时久的操作处理完成并返回，其他请求才能被处理到。

• 使用IO多路复用技术

  • 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。
  • Redis采用了IO多路复用技术和非阻塞IO，这个技术由操作系统实现提供，Redis可以方便地操作系统的API即可。Redis可以在单线程中监听多个Socket的请求，在任意一个Socket可读/可写时，Redis去读取客户端请求，在内存中操作对应的数据，然后再写回到Socket中。
  • 多路I/O复用模型是利用select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

• 非CPU密集型任务

  • 采用单线程的缺点很明显，无法使用多核CPU。Redis作者提到，由于Redis的大部分操作并不是CPU密集型任务，而Redis的瓶颈在于内存和网络带宽。
  • 如果你觉得单个Redis实例的性能不足以支撑业务，Redis作者推荐部署多个Redis节点，组成集群的方式来利用多核CPU的能力，而不是在单个实例上使用多线程来处理。

2. Redis架构

1. myisam和innodb区别

• myisam是MySQL 5.1以前的默认引擎，支持全文检索、压缩、空间函数等，但是不支持事务和行级锁，所以一般用于有大量查询少量插入的场景来使用，而且myisam不支持外键，并且索引和数据是分开存储的。
• innodb是基于聚簇索引建立的，和myisam相反它支持事务、外键，并且通过MVCC来支持高并发，索引和数据存储在一起。

2. MySQL的索引

• B+树和Hash索引

• B+树是左小右大的顺序存储结构，节点只包含id索引列，而叶子节点包含索引列和数据，这种数据和索引在一起存储的索引方式叫做聚簇索引，一张表只能有一个聚簇索引。假设没有定义主键，InnoDB会选择一个唯一的非空索引代替，如果没有的话则会隐式定义一个主键作为聚簇索引

  

• 非聚簇索引(二级索引)保存的是主键id值，这一点和myisam保存的是数据地址是不同的

  

• 区别
  

3. 覆盖索引和回表

1. MQ解决的问题

• 解耦
  • 不用MQ：要针对各业务方开发，要考虑中断、超时、重试
  • 使用MQ：消息中间件类似一个代理，各业务方的通讯协调均由MQ负责，MQ来实现超时、重试机制
• 异步
  • 不用MQ：长活同步事务，高延时，体验极差
  • 使用MQ：分步异步执行，防止同步阻塞
• 削峰
  • 不用MQ：请求并发，服务器或数据库压力过大，导致宕机
  • 使用MQ：请求并发转串行，MQ来承担压力，平缓输出给服务器或数据库

2. 引入MQ产生的问题

• 可用性
  • MQ挂了，整个系统都不能用
• 复杂性
  • 消息重复：多次生产、多次消费
  • 消息乱序：新数据被旧数据覆盖
  • 消息丢失：漏数据、磁盘满了丢数据
• 一致性
  • 分布式一致性问题，异步的多个事务没有最终都执行或都不执行

3. 常用MQ对比