2024-01-11

_posts/2022-06-21-java.md

@@ -39,11 +39,10 @@ pin: true
 JMM 旨在提供一个统一的可参考的规范，屏蔽平台内存访问差异性。这个规范为读写共享变量时如何与内存交互提供了规则和保证。
 
 关键概念包括：
-- 主内存：表示所有线程都可以访问的共享内存。它由堆（用于对象分配）和方法区（包含类和方法信息）组成。
-- 线程内存：每个线程都有自己的内存区域，称为线程栈。它存储局部变量、方法调用和部分结果。
+- 主内存：表示所有线程都可以访问的共享内存。线程不能直接读写主内存中的变量。
+- 工作内存：每个线程都有自己的工作内存，线程的工作内存保存了该线程用到的变量和主内存的副本拷贝，线程对变量的操作都在工作内存中进行。当一个线程修改了自己工作内存中的变量时，它必须把这个变量的最新值写回到主内存中，以便其他线程可以看到这个最新的值。
 - 共享变量：这些变量可以被多个线程访问。它们可以是实例变量或静态变量。
 
-每个线程都有自己的工作内存，线程的工作内存保存了该线程用到的变量和主内存的副本拷贝，线程对变量的操作都在工作内存中进行。线程不能直接读写主内存中的变量。
 
 JMM 为处理共享变量定义了三个特征（多线程中的概念）：
 - 可见性：当一个线程修改共享变量的值，其他线程能够立即知道被修改了。当变量被 volatile 修饰时，这个变量被修改后会立刻刷新到主内存，当其它线程需要读取该变量时，会去主内存中读取新值。但普通变量读取的仍是旧值。

_posts/2022-06-22-mysql.md

@@ -252,4 +252,19 @@ WAL 核心：将随机写（磁盘的写操作是随机IO，耗性能）转变
 2. 异步调用。增删改服务和搜索服务分别通过MQ进行发送和监听消息，有效降低业务的耦合度，但较为依赖MQ的性能；
 3. binlog监听。给MySQL开启binlog功能，搜索服务基于canal监听binlog变化，但开启binlog会增加数据库负担、同时实现复杂度较高。
 
-但也有异步调用和binlog监听结合在一起的[例子](https://github.com/Scoefield/syncMySqlToES)，用canal作slave节点。
+但也有异步调用和binlog监听结合在一起的[例子](https://github.com/Scoefield/syncMySqlToES)，用canal作slave节点。
+
+## 分库/分表
+
+分为 **水平切分（又称为 Sharding）** 和 **垂直切分**。
+
+### 切分策略
+- 范围切分，例如每一千万条数据一张表
+- 哈希切分，对分表键进行哈希运算，主流方法
+- 映射表，将分表键和数据库表对映射关系记录在表上
+
+### 分布式ID
+
+![](https://pic4.zhimg.com/80/v2-0ca4a4125b1cbda69cfa972b1e568ffb_1440w.webp)
+
+建议使用雪花算法，其中**序列号一直保持递增，不会因为时间戳的不同而归零**，防止被猜测上下文ID。

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

@@ -26,7 +26,6 @@ pin: false
 
 6. 消费者群组：一个消费者组可以消费多个 Topic 的消息，组内的消费者只能订阅相同的 Topic 和相同的 tag且 Tag 顺序相同。详见[订阅关系一致](https://help.aliyun.com/zh/apsaramq-for-rocketmq/cloud-message-queue-rocketmq-4-x-series/use-cases/subscription-consistency)。支持[两种消费方式](https://juejin.cn/post/7089788861915594766)：集群消费（默认）和广播消费。集群消费，相同消费者群组的消费者平摊消息，便于负载均衡；广播消费，相同消费者群组的每个消费者接收全量的消息，适合并行处理的场景。
 
-7. 
 
 ## 消息队列的三大作用
 - 解耦
@@ -103,6 +102,16 @@ pin: false
 
 如果事务正常执行，则 commit 该消息，如果抛出异常，则 rollback。对于消费消息失败，RocketMQ 会尝试重新消费，直到被加入死信队列中为止。在重试的过程中有可能产生重复的消息，所以对于消费端来说要确保**消费幂等**！
 
+## 消息堆积
+
+原因可能是以下三种：
+1. 生产远超预期
+2. 消息接收和持久化出现故障
+3. 消费能力下降
+4. 程序问题
+
+处理堆积的消息：建立临时的 topic（扩容），转发堆积的消息
+
 
 ## 服务发现
 - Kafka 使用 ZooKeeper，但新版本使用内嵌的KRaft替代了ZooKeeper
@@ -120,3 +129,34 @@ pin: false
 
 解决方法：要满足局部有序，只需要在发消息的时候指定Partition Key，Partition Key相同的消息会放在同一个Partition。
 
+## RocketMQ 如何保证消息的顺序性
+
+全局有序：对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。
+局部有序：对于指定的一个 Topic，所有消息根据 hashKey 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。
+
+实现消息有序性从三个方面：
+
+1. 生产者生产顺序消息：生产者将消息路由到特定分区
+2. Broker 保存顺序消息：保证生产者顺序生产即可
+3. 消费者顺序消费消息：设置 consumeMode 为 ORDERLY
+
+## RocketMQ 负载策略
+1. 平均负载策略，MessageQueue 总数量除以消费者数量并求余数，前余数个数个消费者增加一个 MessageQueue 的消费
+
+![](https://s6.51cto.com/oss/202203/14/e9f849a39832efee7e833607029c85de3880c4.png)
+
+2. 循环分配策略：循环顺序遍历消费者
+
+![](https://s4.51cto.com/oss/202203/14/760652913a6c25afb83877fa3352da05c6e9dc.png)
+
+3. 指定机房分配策略
+
+![](https://s6.51cto.com/oss/202203/14/62b8d0b98e057beb80d026b5a578de36fe376c.png)
+
+4. 机房就近分配策略
+
+![](https://s2.51cto.com/oss/202203/14/522866530333cbe9bc6074464633c81b3a1775.png)
+
+5. 一致性哈希算法策略
+
+![](https://s9.51cto.com/oss/202203/14/d6a9910256e2acc868e4012618187f853c8a3c.png)