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、主从同步原理:
- 全量同步时,master执行bgsave将内存中的数据持久化到rdb文件中,然后将此文件传输给slave节点,slave节点加载此文件。
- 增量同步时,只要最坏的情况能被解决,那其余的情况就不用关注了。最坏的情况就是第一个slave第一次建立的连接时立刻就挂了,所以master在第一个slave建立连接后就开始记录所有写操作(只有master能写),命令被记录到repl_backlog文件,同时记录一个值叫offset,用以标识记录长度,记录的写命令越多,offset就越大。slave在执行maste同步多来的写命令时也会记录offset,slave向maste发起数据同步请求时会携带自己的offset,maste拿slave的offset和自己的offset进行比较,就能知道需要给slave进行增量同步的数据是哪些。
- 各个节点在启动时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也采用了分片。