CYK_byte的博客

前面讲到了 生产者消息确认机制 和 消费者消息确认机制，保证了消息传输的可靠性，但是这还不够，试想如果 Broker 突然崩溃，那么所有的 交换机、队列、消息 不就全部都没了（RabbitMQ 以内存为主，硬盘为辅，默认交换机和队列都是非持久化的）. 因此需要持久化机制.a）交换机持久化如果交换机不设置持久化，那么在 rabbitmq 服务重启之后，相关的交换机元数据就会丢失，对一个长期使用的交换机来说，建议设置成持久化的.

RabbitMQ 的 AMQP 协议实现了事务机制，允许开发者保证消息的发送和接收时原子性的，也就是说，要么消息全都发送成功，要么全都发送失败（只与发送方有关）.

为了保证信息 从生产者 发送到 队列，因此引入了生产者的消息确认机制.通过事务机制实现.通过发送确认机制（confirm 和 return）实现.因为事务机制比较消耗性能，在实际工作中用的也不多，因此这里主要介绍confirm 和 return机制来实现发送放的确认.a）confirm 确认模式如上图，confirm 确认模式主要保障于 生产者 到 交换机 的消息可靠性.如果 Exchange成功收到消息，那么 ConfirmCallback 这个回调 ack 参数就为true。

RabbitMQ 的队列在有多个消费者订阅时，默认会通过轮询的机制将消息分发给不同的消费者，但是有些消费者消费速度慢，有些消费者消费速度快，就会导致消费速度慢的消费者影响整个的任务的吞吐量下降例如，公司有1个正式员工和1个实习生，现在有 10 个任务分配平均给他们（各 5 个），而由于实习生干活比较慢，就会导致整个完成任务的吞吐量下降.消息分发机制给 “正式工” 多分一些任务，给 “实习生” 少分一些任务.

为了保证消息从 队列 到 消费者正确消费，那么就引入了消费者消息确认机制.a）消费者在订阅队列时，可以指定 autoAck 参数，根据这个参数设置，消息确认机制分为以下两种（以下讲到的方法和参数来自于 RabbitMQ 原生的 SDK，非 Spring 提供）.自动确认：当 autoAck = true 时，RabbitMQ 会自动把发送出去的消息置为确认，然后不管消费者是否真正的消费这些消息，都会从内存中删除.（适合对消息可靠性要求不高的场景）.

八大排序你忘了吗？

除了单表操作比较耗时外，对于中小型项目而言，频繁的读写操作场景，使用 mongo 就够用了. 甚至都不用上 mq，更甚至有的场景下 redis 性能还不如 mongo...

就是指对服务器请求量做限制，避免因为突发的请求量过多，导致服务器宕机.比如，我们的服务器只能抗住每秒 1000 的请求量，但此时突然有 10000 的请求量来了，那么就需要把你这么大的请求量拦下来，按照服务能够承载的流量去放行，起到一个流控的效果.如何实现呢，就来看看这主流的三种限流算法~

那么当服务消费者要去消费时，就可以从注册中心拉取服务信息. 这个过程也被称为“服务发现”. 但是他这个拉去动作不是每次都要做的（压力太大），而是将拉取到的服务信息缓存到一个列表中，这样接下来的一段时间里，就不用去拉去了，而是直接从缓存列表中拿.因为一个集群中可能包含多个实例，也就是具体的节点信息（例如实例的IP、Port、健康状态），那么 Cluster 这个类中又维护了 两个 Set，分别是临时实例和非临时实例（此处，Eureka 就没有做区分，只有临时实例）.

a）Nacos 的分级存储模型对应到源码中，实际上就是一个多层嵌套Map，key 就是 String 类型的 namespace，而他的 value 又是一个 Map.b）这个第二层的 Map 就表示 group 和 服务了，key 就服务名称，而 value 就是一个服务 service.c）服务实际上就是一个类，由于一个服务往往是有多个集群的，因此在 service 类中又维护了一个 map，key 就是集群名称（例如，上海、广州、杭州...）.d）他的值 cluster 集群也是一个

索引就是一种帮助 mysql 提高查询效率的数据结构.

当使用ObjectMapper.readValue()方法将 JSON 字符串反序列化为AppResult对象时，如果AppResult对象的 data属性是一个泛型（如 Object），那么 Jackson 将无法知道这个属性的确切类型，因此会将其反序列化为一个LinkedHashMap.

RandomLoadBalancer - 随机分配策略(默认)RoundRobinLoadBalancer - 轮询分配策略//这里不用加 @Configuration 注解//将官方提供的 RandomLoadBalancer 注册为Bean@Bean通过 @LoadBalancerClient(value = "服务名", configuration = LoadBalancerConfig.class) 指定负载均衡策略为随机.

a）使用 RabbitMQ 发送消息时，发送消息的类型为 Map，map 里面我 put 了一个 类型，如下图：b）这里有一个前提：我清楚使用 org.springframework.amqp.rabbit.core.RabbitTemplate 来发送消息到 RabbitMQ 队列时，消息的序列化是由 MessageConverter 完成的。

第一次超时了，进行空回滚（添加 freeze，设置状态为 cancel），第二次又超时了，freeze 不为空，就会进行恢复金额逻辑. 这就出问题了，不能进行恢复金额操作，因此，这里需要进行判断，如果处理过了，直接返回 true 即可.在执行完空回滚之后，try 逻辑的请求阻塞突然通畅，就会去执行资源预留业务，但是资源预留了之后就没有后续了（已经执行过 cancel 中的空回滚了），既没有 cancel，也没有 confirm，业务只执行了一半. 这就是业务悬挂.怎么知道 try 到底有没有执行过呢？

1. 首先前端将用户名和密码发送给后端，后端对用户名和密码校验成功后，会将用户 id 和其他信息作为 payload ，然后将其分别进行 Base64 编码，拼接，最后再签名，形成一个 JWT（Token）. 形成的 JWT 就形同 xxx.yyy.zzz 这种结构的字符串.http 协议是一种无状态的协议，也就意味着当用户第一次通过用户名和密码登录成功以后，下一次再请求的时候，用户还需要再进行登录才行，因为根据 http 协议，我们不能知道是哪个用户发出的请求.

这里不仅仅要实现高可用，还需要实现异地容灾. 异地容灾就是说，如果你整了好几个节点部署起来，全部放到一个机房里面，那么如果这个机房出了故障，就意味着整个集群就完了，所以对于一个大型的集群来讲，都会把这些服务异地部署.问题2：如果我们要实现异地容灾，也就说某一个机房挂了，需要快速的切换到另一个可用的机房，但是这个配置在配置文件中写死了，如果要改配置文件，还需要重启服务器，这是我们不希望看到的，怎么办？进入 seata/bin 目录，运行 seata-server.bat 文件，默认端口为 8091。

TM 看到业务结束了，就会去通知 TC，那么 TC 就会判断是提交还是回滚. 如果分支事务的状态都是成功的，那就可以把第一阶段准备的快照给删了（删快照这个动作是异步的，因为第一阶段都成功了，也提交了，后面的事情就可以用一个线程独立去做，提高了效率）. 如果第一阶段有人失败了，就要基于 undo log 恢复数据，恢复以后这个 log 也就没用了，最后也会删除.2. XA 依赖于数据库的机制来做回滚，而 AT 模式因为已经提交了，就不能回滚，他是通过给自己生成快照的方式来实现数据的恢复.

你在淘宝里买东西的时候，要通过一些信息进行筛选，比如 销量、信誉、价格升序... 这些词一般都是固定一个按钮，点击就会帮你做筛选.

举个例子，你在淘宝上买东西，完成支付以后会进行修改订单状态的业务，与此同时，你还要查看订单，但是 查询 和 修改 都会争抢数据库的锁，产生竞争. 根据业务需求是，优先进行更新订单业务，之后进行用户查询业务，因此当修改订单业务触发阈值时，就需要对查询订单业务进行限流.排队等待这种方式，当请求超过 qps 阈值之后，不会直接抛出异常，而是让多出来的请求先进入到一个队列中进行排队，然后按照阈值允许的时间间隔依次执行，如果队列中所有的请求处理时间加起来刚好等于等待时间，那么，此时新来的请求就会被拒绝.

比如我们的用户做一个商品订单的搜索，因为 es 的搜索能力更强，所以这里使用 es 进行搜索，那么也意味着，es 这边也要有数据，那怎么确保两边都有数据呢？elasticsearch 是面向文档存储的，可以是数据库中的一条商品数据，也可以是订单数据... 这些东西都会被序列化成 json 的格式，存储在 es 中.这里的映射就是对文档字段的约束，比如你的字段名字是什么，数据类型是字符串，还是数字啊. 这就类似于 mysql 中的约束一样.这就相当于是 MySQL 中的表一样，而文档就是表中的每一行数据.

刚刚我们已经知道了 Seata 中三个重要角色，其中 tm 和 rm 是对业务的管理，而 tc 则是脱离业务之外的独立服务，需要协调 tm 和 rm，协调全局事务和分支事务.这里我就来带大家搭建一下 Seata 的 TC 服务.

全文检索的 match 和 multi_match 查询和前面演示的 match_all 调用的 API 基本一致，差别就是查询条件，也就是 query 部分（通过 QueryBuilders 构建的条件不一样）.DSL 语句的构建是通过 HighLevelRestClient 中的 Resource 实现的，其中包含了 查询、排序】分页、高亮等所有功能.其中 query 表示查询的意思，他的查询条件的是由 QueryBuilders 的工具类提供的，包含了各种查询方法.range 查询也是如此.

显然不能，请求来了以后，就要等待 服务d 的响应，因为 服务d 出现故障了以后不能正常返回响应，因此就会阻塞在这里，导致 服务a 内部的业务阻塞在这里. 也就不会释放 tomcat 连接.拿之前的栗子讲，服务a 里有一个业务时访问 服务d 的，然后呢第一次访问时正常的，结果后面两次都出现了故障，这个时候熔断器就会统计这个异常比例是怎么样的. 假设阈值时 50%，而三个请求中，两个都出了问题，肯定超出了阈值，这个时候就会出现熔断，那么在 服务a 内部，访问 服务d 的业务都会被拦截下来，然后快速释放资源.

在分布式系统下的一个业务，跨越了多个服务和数据库，每个防毒物都可以任务是一个分支事务，分布式事务就是要保证，所有分支事务最终状态一致，要么大家都成功，要么大家都失败.而分布在事务出现了问题，就是因为各个分之事务之间是相互隔离，感知不到的，因此就导致无法回滚，进一步导致没法保证一致性.

第一次是根据用户输入的内容的词条，去找到对应的文档 id.第二次是拿着文档 id 来找文档.这样的查询效率，相比于正向索引中搜索 包含手机关键字的 数据，一行一行去查找就要快的多了.倒那么这里也能够看出，排索索引为什么是倒排了，因为正向索引中，得一行一行找，找到匹配的放到结果集中，而倒排索引就是反过来，基于词条创建索引，搜多的时候，就是根据词找到对应的文档（正向索引就是根据文档来找词）.

全网最详细的缩容操作！

lua 语言特别轻量（实现一个 lua 解释器，消耗的体积非常小），可以使用 lua 编写一些逻辑，把这个脚本上传到 redis 服务器上，然后就可以让客户端来控制 redis 执行上述脚本了.最重要的一点就是，redis 执行一个 lua 脚本，就相当于在 redis 上执行一个命令一样，是原子的. 并且 redis 官方文档中也明确说，lua 就属于是 事务 的替代方案.例如前面的 “买票” 案例.elsereturn 0end;

广义的集群：只要你是多个机器，构成的分布式系统，都可以成为是一个 “集群”，也就是说，之前所讲的 主从结构、哨兵模式，也可以称为是一个 “广义的集群”.狭义的集群：这个说的就是 redis 提供的集群模式. 这个集群模式之下，主要就是解决，存储空间不足的问题.

4 种可靠性保证

当前阶段，由于我只有一个 云服务器，搞分布式系统就比较麻烦，而实际工作中，一般是通过多个主机的方式来搭建集群的.因此这里我会 基于 docker、docker-compose（容器编排） 来搭建 redis 集群.

想要知道什么是死信交换机，先来看看什么是死信（dead letter）~消费者使用 basic.reject 或 basic.nack 声明消费失败，并且消息的 requeue 参数设置为 false（消息不重新加入到队列中）.消息设置了过期时间，到了时间没有被消费掉.要投递的队列消息堆积满了（队列设置了最大消息数目），最早的消息可能会成为死信（LRU 算法淘汰的消息）.

缓存可以理解为，将常用的数据从放到一个访问速度更快的的地方，方便更快的随时读取.也就是说，速度快的设备，可以作为速度慢的设备的缓存，加快读取速度。

对于传统的队列来讲，如果没有开启消息持久化，所有接收到的消息都是放在内存里面的，目的就是为了加快消息投递的速度，这也是 RabbitMQ 的一个很优势——响应速度快.但是他也带来了一个问题，RabbitMQ 设置了一个内存预警值（内存存储的上限，默认是 40%），如果在消息堆积的情况下，很容易就到达这个预警值，此时，RabbitMQ 就会处于一个暂停状态，会阻止生产者投递消息进来，然后把内存中的一部分消息清理出来，刷出到磁盘中，这动作也叫 “page out”

Redis Sentinel 是⼀个分布式架构，其中包含若干个 Sentinel 节点（哨兵）和 Redis 数据节点，这两种结点之间的哨兵机制，是通过独立的进程来体现的，和 redis-server 是不同进程！redis-sentinel 不负责存储数据，只是对其他的 redis-server 进程起到监控的效果.

list 的内部结构类似于 “双端队列”（deque），元素是有序的，并且允许元素重复，因此头插和尾插的效率很高，可以当作一个 栈 / 队列 来使用，约定最左侧元素下标是 0，并且是是支持负数下标.

RedisTemplate 是把 Redis 的方法，分成了几个类别来进行组织，和原生的 Redis 命令有一定的差异~ 作者的初心是希望通过上述封装，让接口看起来更简单，但在我看来，并没有达成，反而因为与 Redis 原生命令差异，提高了使用者的学习成本.之前使用 Jedis 是通过 Jedis 对象里的各种方法来操作 redis 的，此处 Spring 则是通过 SpringRedisTemplate 来操作 redis.

redis 中的 set 就是一个集合，集合就是把一些关联的数据放在一起，我们把集合中的元素叫 member

疑问：redis 虽然是单线程，为啥效率这么高？速度这么快呢？你为啥使用 redis 呢？注意，我们无论比较的是哪一个特性，都是以 mysql、oracle、sql server 作为参照的~那么主要有以下几个方面~

redis 中最关键的五个数据类型 String、List、Hash、Set、Zset 应用最广泛，同时 redis 也推出了额外的 5 个数据类型，他们分别是针对特殊场景才进行的应用的.