SpringCloud

1、SpringGateWay采用的是WebFlux，因为和SpringMVC相比，它是非阻塞的，能提高吞吐量

2、过滤器比拦截器先执行，所以可以在网关服务的过滤器里进行登录token校验，在各个业务服务里的拦截器里进行token解析，将用户信息存入线程上下文

3、现有gateway模块和common模块，gateway模块创建了拦截器，参考上边的2，common模块创建了拦截器，进行token解析，将用户信息存入线程上线文，但由于业务模块多，都需要，所以在common模块声明拦截器，然后所有业务模块引入common。创建拦截器需要实现WebMvcConfigurer接口，所以common需要引入spring-mvc依赖，但gateway模块使用的是异步非阻塞的webflux，不需要mvc，且需要common中的其他东西，而业务模块都需要mvc，所以需要将common中引入的spring-mvc依赖的<scope>设为provided，这样gateway模块就不会引入mvc了。同时需要在声明的拦截器上加注入条件@ConditionalOnClass(DispatcherServlet.class)，否则gateway服务启动报错，会提示找不到WebMvcConfigurer。同时gateway模块包路径是com.lhy.gateway.xxxx，而自定义拦截器在common模块的com.lhy.common.config包下，引用common的项目的启动类是扫描不到此自定义拦截器的，所以可以通过在common模块下的resource/META-INF下添加spring.factories的方式注册自定义拦截器，其他模块在使用common时，也会扫描到common模块的spring.factories文件，实在是太妙了。为什么引入common的gateway模块没有引入spring-mvc依赖，没有DispatcherServlet这个类时，@ConditionalOnClass(DispatcherServlet.class)这行代码不会爆红导致gateway启动失败呢？这是因为编译器只检查语法是否正确，而不关心运行时条件是否满足，@ConditionalOnClass就是来判断DispatcherServlet是否存来决定是否创建Bean的，所以DispatcherServlet不存在时当然不能报错了，语义如此，在Springboot底层jar的各种自动装配类里经常见到@ConditionalOnClass(DispatcherServlet.class)爆红的，但是不影响运行。

3、Nacos管理配置时，通过本地的bootstrap.yaml文件启动时，都会加载哪些配置文件，他们之间内容的覆盖优先级是什么,

# 配置文件分为3类：shared-configs，extension-configs，${spring.application.name}-{spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
# 其中{spring.profiles.active}可为空"-"号为自动消失,优先级从左往右依次降低，bootstrap.yaml和本地的application.yaml（前者比后者低）都比Nacos低

要实现nacos配置热更新，创建properties配置类的方式要比@RefreshScope+@Value更好

。详情参考

4、如果您有一个使用了@ConfigurationProperties的配置类，并且您希望其他Bean能够使用这个配置类中的配置值，并且这些值能够动态地响应配置中心的变化，那么您应该在那些依赖这个配置类配置值的Bean上使用@RefreshScope。而配置类本身则应该被Spring管理为一个Bean（通常通过@Component或@Configuration与@Bean方法结合使用），但不需要（也不推荐）被标注为@RefreshScope

5、交换机只转发消息，不存储消息，投递失败则消息丢失。

6、RabbitMQ使用的可靠性要从三个方面来看：生产者的可靠性、MQ的可靠性、消费者的可靠性。

7、在使用Docker创建Redis容器时要用Host，不要用默认的bridge模式

8、redis实例在创建时，都会又自己的master_replid，当建立了主从关系后，master节点的master_replid不会变，salve节点的master_replid的值会变为master节点的master_replid。master以此来判断salve是否是第一次来建立🔗，slave的master_replid和自己的不一致，说明是第一次，则进行全量同步，否则进行增量同步。

9、主从同步原理：

1. 全量同步时，master执行bgsave将内存中的数据持久化到rdb文件中，然后将此文件传输给slave节点，slave节点加载此文件。
2. 增量同步时，只要最坏的情况能被解决，那其余的情况就不用关注了。最坏的情况就是第一个slave第一次建立的连接时立刻就挂了，所以master在第一个slave建立连接后就开始记录所有写操作（只有master能写），命令被记录到repl_backlog文件，同时记录一个值叫offset，用以标识记录长度，记录的写命令越多，offset就越大。slave在执行maste同步多来的写命令时也会记录offset，slave向maste发起数据同步请求时会携带自己的offset，maste拿slave的offset和自己的offset进行比较，就能知道需要给slave进行增量同步的数据是哪些。
3. 各个节点在启动时master_replid的值都是自己的，当通过slave of建立主从关系时，会携带offset和master_replid，master_replid和主节点的master_replid相同，且offset为-1（没写过数据的默认-1）则说明需要全量同步，否则增量同步。全量同步时，master执行bgsave将内存数据写入rdb文件，然后和自己的offset一起传给从节点，从节点清理内存加载rdb文件，再此期间，master会把自己收到的写命令保存到replication_buffer中，当从节点加载完rdb后，主节点将replication_buff里的命令同步给子节点，子节点执行命令并对自己的offset做相应移动。增量同步时，从节点对比子节点传来的offset后从自己的repl_backlog_buffer中取出相差的命令传输给子节点。repl_backlog_buffer是在master启动时就开始记录写命令，是所用子节点共用的，用于增量同步时比较相差的命令，是环形的，满了的话会从头开始覆盖。replication_buffer是子节点第一次连接时创建，由于每个节点连接的时间各不相同，所以主节点会为每个第一次连接的子节点创建replication_buffer，用以记录主节点在bgsave期间、rdb传输到子节点期间、子节点加载rdb文件期间收到的写命令，发给子节点以保证主从offset值一致。子节点故障时，主节点的repl_backlog_buffer持续存入写命令，由于repl_backlog_buffer是环形设计，当写满时会从头开始覆盖继续写，当主节点从子节点的后边超过去时，则超过的这一部门所覆盖的上一圈的数据丢失，这种情况也会触发全量同步。

10、学习Redis要从三方面入手：主从结构（主从同步问题）、哨兵模式（主从自动切换）、集群分片（单独一个主节点进行海量数据存储、高并发写会扛不住）。这个集群分片就是将数据分成分，然后建立多个主节点，分别存一份，ES也采用了分片。