Skip to content

Commit aef46ea

Browse files
20241014
1 parent 1a595da commit aef46ea

File tree

3 files changed

+21
-5
lines changed

3 files changed

+21
-5
lines changed

_posts/2023-07-06-redis.md

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -200,9 +200,13 @@ redis 4.0 后部分命令开始使用多线程。
200200

201201
Redis 集群**无法保证强一致性**,选择了高可用和分区容忍,即AP。
202202

203-
将不同的数据分布在不同的节点中,分布的规则采用**一致性哈希算法**。指将数据映射到一个首尾相连的哈希环上,如果增加或者移除一个节点,仅影响该节点在哈希环上顺时针相邻的后继节点,其它数据也不会受到影响。共有16384个哈希槽。
203+
将不同的数据分布在不同的节点中,分布的规则采用**哈希槽算法**。共有 16384 (2^14)个哈希槽。
204+
205+
### 不使用一致性哈希算法的原因
206+
- 一致性哈希环是顺时针映射,优先考虑的是**最少的节点数据发生数据迁移**
207+
- 哈希槽是静态映射的,优先考虑的问题是**数据均匀分布**,根据不同机器的性能,可以手动分配不同的哈希槽数量到不同机器上
208+
204209

205-
一致性哈希算法存在节点分布不均匀的问题。解决方法:引入虚拟节点,将数据映射至虚拟节点而不是真实节点,虚拟节点和真实节点又存在一层映射关系。
206210

207211
### 请求转发
208212

_posts/2023-08-11-springboot.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -82,6 +82,18 @@ Prototype(原型)对象和单例对象的区别:
8282
- 缓存中可以快速获得
8383

8484

85+
## 拦截器与过滤器
86+
87+
### 不同点
88+
1. 过滤器基于函数回调,拦截器基于 Java 的反射机制
89+
2. 过滤器依赖于 tomcat 容器,拦截器是 spring 组件,并不依赖于 tomcat,因此先执行过滤器,再执行拦截器
90+
3. 过滤器几乎可以对所有进行容器的请求起作用,拦截器只会对 controller 中的请求起作用
91+
92+
### 使用场景
93+
1. 过滤器:登陆校验、权限检查、性能监控
94+
2. 拦截器:接口限流
95+
96+
8597
[容器注册组件的四种方式](https://juejin.cn/post/6989944803874062366)
8698
1. @Configuration + @Bean,注意,使用这种注册方法 Spring 会通过 CGLIB 来增强这个类,会判断是否实例已经存在,多次调用只会生成一个实例,意味着在@Configuration中的@Bean生成的是单例;相比之下,在@Component类中使用@Bean注解时,并不会有这种增强的行为。也就是说,当你在@Component类中调用一个@Bean方法时,实际上就是直接调用这个方法,并且每次调用都会创建一个新的 Bean,也就是说是生成多实例。
8799
2. @ComponentScan + @Component

_posts/2023-08-25-kafka-vs-rocketmq.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -160,9 +160,9 @@ RocketMQ 的消费重试是基于**延迟消息**实现的,在消息消费失
160160

161161
![](https://rocketmq.apache.org/zh/assets/images/transflow-0b07236d124ddb814aeaf5f6b5f3f72c.png)
162162

163-
二阶段:第一阶段发送 prepared 消息,接着执行本地事务,第二阶段发送 commit 或 rollback 的消息
164-
165-
定时回查:定时遍历 commitlog 中的半事务消息
163+
本质是两阶段协议 + 补偿机制(事务回查)实现的
164+
- 二阶段:第一阶段发送 prepared 消息,接着执行本地事务,第二阶段发送 commit 或 rollback 的消息。
165+
- 定时回查:定时遍历 commitlog 中的半事务消息
166166

167167
如果事务正常执行,则 commit 该消息,如果抛出异常,则 rollback。对于消费消息失败,RocketMQ 会尝试重新消费,直到被加入死信队列中为止。在重试的过程中有可能产生重复的消息,所以对于消费端来说要确保**消费幂等**
168168

0 commit comments

Comments
 (0)