. 消息可靠性. 生产者确认机制
. 消息持久化（默认就是持久化，了解代码）
. 消费者消息确认
.. none模式
.. auto模式
. 消费者重试机制.. 本地重试（默认的RejectAndDontRequeueRecoverer策略）基于..的auto模式，发送失败的消息会重新放入队列queue中，导致mq反复处理失败的消息，带来过多的压力。因此通过本地重试的方式，将失败的队列进行retry处理（spring），而不是反复放入队列。
在消费者的application.yml文件中配置启动失败重试开关、以及重复的次数：
.. 三个失败策略（RepublishMessageRecoverer实例）在springAMQP中的失败策略有三个，..中是默认的处理方式。对于废弃的消息，如果不希望消息的丢失，可以采用RepublishMessageRecoverer策略。流程图：
消费者中绑定error交换机后（重写失败策略实现），由交换机根据rountingkey（例子中keyD;error）转发到error.queue ...
同步通信与异步通信feign 无法解决的问题假设有一个场景：
客户端发起请求购买商品，此时使用feign的时候，调用链应该如下
客户端 -> 支付服务 -> 订单服务 -> 支付服务 -> 仓储服务 -> 后续服务 -> 支付服务 -> 客户端
可以看到，这条链还是非常长的，而且引发了以下问题：
代码耦合度非常高：
假设在需要加入新的业务需求，那么就需要在支付服务（见下图）中改代码，来一个新需求加一个，非常麻烦。
再来就是业务之间是一个调用一个的链式调用，如果中途有个服务挂了，那么整个项目也就一起挂了。
同步调用非耗时间：
每当有客户发送支付服务的请求，就需要等待订单服务反馈回支付服务后才能继续发送仓储服务的请求，如此反复的把所有业务跑完，非常耗时间。假设回到支付服务再反馈到客户所需时间需要毫秒，也就等于秒中只能处理两个客户，效率非常低。这种接口等待引发的问题甚至导致资源利用率下降，每个接口都需要等待其他业务响应结束才能执行。
资源浪费：
同步调用的时候，调用链中的每个服务都在等待响应，不能释放请求的资源，高并发的场景下会极度的浪费资 ...
后端开发未读
Redis：（三）缓存设计缓存雪崩通常我们为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里，这样后续请求都可以直接命中缓存。
那么，当大量缓存数据在同一时间过期（失效）时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。
对于缓存雪崩问题，我们可以采用两种方案解决。
将缓存失效时间随机打散： 我们可以在原有的失效时间基础上增加一个随机值（比如 到 分钟）这样每个缓存的过期时间都不重复了，也就降低了缓存集体失效的概率。
设置缓存不过期： 我们可以通过后台服务来更新缓存数据，从而避免因为缓存失效造成的缓存雪崩，也可以在一定程度上避免缓存并发问题。
缓存击穿我们的业务通常会有几个数据会被频繁地访问，比如秒杀活动，这类被频地访问的数据被称为热点数据。
如果缓存中的某个热点数据过期了，此时大量的请求 ...
Redis集群搭建一个高可用集群有以下内容：主从复制，哨兵模式，切片集群。
主从复制虽然使用 AOF 和 RDB 可以保证持久化，但是如果单点暴毙了，那么两个持久化文件也就没有意义了。
因此，可以通过集群的方式，避免单点暴毙的问题。通过一主多从的集群方式，保证服务的可使用。
主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。
主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。
也就是说，所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就使得主从服务器的数据是一致的。
注意，主从服务器之间的命令复制是异步进行的。所以，无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。
全量同步：第一次同步
在第一阶段中，如何判断从节点是不是第一次同步？
执行了 replicaof 命令后，图中的.阶段请求数据同步 ...
RedisRedis简介Redis 官方文档：
Redis 是一个开源(BSD 许可)的内存数据结构存储，用作数据库、缓存、消息代理和流引擎。Redis提供数据结构，例如字符串、散列、列表、集合、带范围查询的排序集合、位图、超日志、地理空间索引和流。Redis 内置了复制、Lua 脚本、LRU驱逐、事务和不同级别的磁盘持久性，并通过以下方式提供高可用性 Redis Sentinel 和 Redis Cluster 的自动分区。
使用 Redis 可以对这些类型运行原子操作，例如附加到字符串；增加哈希值；将元素推入列表；计算集交、并、差；或获取排序集中排名最高的成员。为了达到最佳性能，Redis 使用内存中的数据集。根据您的用例，Redis 可以通过定期将数据集转储到磁盘或将每个命令附加到基于磁盘的日志来持久化您的数据。如果您只需要一个功能丰富的网络内存缓存，您也可以禁用持久性。
Redis支持异步复制，具有快速非阻塞同步和自动重新连接以及网络拆分上的部分重新同步。
Redis还包括：
交易
发布;订阅
Lua脚本
生命周期有限的密钥
LRU驱逐密钥
自动故障转移
Redi ...
前言对于sql优化，必须掌握的知识：MySQL：（一）索引底层原理与实现 、MySQL：（二）存储引擎
一、插入数据批量插入&手动事务如果插入的数据是-这个范围，可以使用数据批量插入的方式。那如果是几万条数据呢？那就使用多条数据批量插入语句。如果使用单条插入操作会多次建立与数据库的连接，性能肯定是比一次性连接的批量插入低的。
另外，InnoDB使用的是自动提交事务，每插入一次就自动进行事务的开启和关闭，因此可以手动控制事务，避免事务多次的开启和提交。
最后是主键顺序的问题。InnoDB使用的是B+树和双向链表，而B+树众所周知就是查的快，插入难，会导致页分裂等等问题。B+树如果按照主键顺序进行插入效率会高很多。
主键顺序可参考：
文章：MySQL：（一）索引底层原理与实现 中第四节：InnoDB B+树存储数据结构。
本篇文章第二节
总结一下：
批量插入
手动提交事务
主键按顺序进行插入
load指令ok，下一模块。
如果插入的数据更大，数据来到了几百万的级别，那么使用insert的性能就不高了。
在MySQL中要涉及大量数据插入时，我们选择 ...
为什么要进行分库分表
来解释一下IO瓶颈：
在介绍innodb存储引擎MySQL：（二）存储引擎 | 颓废市民黄先生 (rengoku.top)的时候，曾经说过，内存架构中大部分的组件都分配给了缓存。如果内存不足，缓存就不够，那么就要使用后台线程和磁盘进行io，这样效率就会低
拆分策略
垂直拆分
垂直分表：局限于单个数据库内部，不涉及跨数据库操作。
垂直分库：跨越多个数据库，甚至可能跨越不同的服务器，涉及跨数据库的数据访问和管理。
水平拆分和垂直拆分一样，水平分库会涉及跨数据库，而水平分表不跨数据库。
MyCatmycat详细介绍及实战-CSDN博客
mycat实现分库分表，读写分离。
一、控制反转（IoC）和依赖注入（DI）. 控制反转 Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。
谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对象的创建。
谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。
这里提到的“外部资源”指的是IoC（Inversion of Control，控制反转）容器之外的资源。
为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象（new关键字），也就是正转；而反转则是由容器来帮忙创建及注入依赖对象。
为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。
. 依赖注入. ...
前言MVCC是面试重灾区，网上的内容我发现并不全面，只有生搬硬套下来的原理却不解释过程，让我看的云里雾里。我写这篇MVCC的内容目的是能更好了理解MVCC如何实现，结合一些八股的内容和实际的案例进行介绍，全程干货。
一、什么是MVCC多版本并发控制（MVCCD;Multi-Version Concurrency Control），是一种用来解决读 - 写冲突的无锁并发控制。也就是为事务分配单向增长的时间戳，为每个修改保存一个版本。版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照（复制了一份数据）。mvcc解决的就是读写时的线程安全问题，线程不用去争抢读写锁（读写锁可参考：Java多线程：三、多线程锁、java锁的实现 | 颓废市民黄先生 (rengoku.top)）。
说到读写冲突和多线程并发控制，肯定也会涉及事务的隔离级别，即读未提交（可能脏读），读已提交（不可重复读），可重复读（可能幻读）。
MVCC所提到的读是快照读，也就是普通的select语句。快照读在读写时不用加锁，不过可能会读到历史数据。
还有一种读取数据的方式是当前读，是一种悲观锁的操作。它会对当前 ...
一、存储引擎. InnoDB在MySQL现版本，默认的存储引擎是InnoDB，这个不用多说了，另外常见的还有MyISAM，Memory，CSV等，这里就InnoDB进行介绍。
总结成三个词语就是：事务，外键，行级锁。
. idb文件-表空间文件
*.frm：与表相关的元数据信息都存放在frm文件，包括表结构的定义信息等
*.ibd：InnoDB DATA，表数据，表结构和索引的文件。该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。
要是想查看这个表，直接打开的话是不行的，因为都是二进制文件
可以通过ibdsdi xx.ibd命令来得到json格式的表数据
. 逻辑存储结构
二、架构. 内存架构
buffer pool处理主键索引、二级索引，而change buffer是基于为了减少磁盘io的目的，优化了二级索引处理。
利用哈希索引去做查操作非常的快，而使用b+树的效率和使用hash索引相比就没有那么高，因此在innodb中优化了对buffer pool的查询。如果hash索引更快则建立hash索引，和之前学的一样，和b+树都是一种 ...
