技术杂货铺：Git Fork 同步、Mac 签名绕过、Kafka 消费者组机制

GitHub Fork 项目的持续跟新

git remote -v
git remote add upstream https://github.com/simplezhli/flutter_deer.git
git remote -v
git fetch upstream
git checkout master
git merge upstream/master

# 遇到 fatal: refusing to merge unrelated histories 使用
git merge upstream/main --allow-unrelated-histories

Mac 下载资源网站

Mac 安装特殊dmg 添加数字签名


#苹果定期发布安全补丁，撤销一些“特定”开发人员的证书（数字签名）。运行没有证书的应用程序会导致错误消息并且应用程序意外结束…
#要解决该错误，您需要手动签署应用程序或 禁用 SIP
#您可以使用终端实用程序使用以下命令对应用程序进行签名：  

sudo codesign –force –deep –sign – /Applications/NewApp.app
#请注意，该命令包括应用程序的路径…即在“sign -”之后，您需要放置一个空格并将应用程序拖到终端窗口中。
#您可以使用以下命令对可执行文件进行签名：
sudo codesign –force –sign – /Applications/NewApp.app/Contents/MacOS/NewApp

#按 Enter 键并输入管理员密码。
#在终端中输入密码时不会显示密码，但会输入密码。输入密码后，按 Enter 键。

#准备好！启动应用程序。

#您可以在developer.apple.com或wiki.lazarus.freepascal.org上阅读有关在macOS中添加数字签名的更多信息

Kafka

在 Kafka 中，主题（topic）、分区（partition）、消费者组（consumer group）和消费者（consumer）之间的关系是核心概念之一，它们共同决定了消息的分发和处理方式。以下是这些概念的详细解释和它们之间的关系：

基本概念

主题（Topic）：

主题是 Kafka 中用于组织和分类消息的逻辑容器。每个主题可以看作是一个消息类别或管道。
一个主题可以有多个生产者（producers）向其发送消息，多个消费者（consumers）从中读取消息。

分区（Partition）：

每个主题可以分为多个分区。分区是 Kafka 中存储消息的基本单位。
每个分区是一个有序的、不可变的消息序列。
分区允许 Kafka 实现水平扩展和高吞吐量，因为消息可以并行地写入和读取不同的分区。

消费者组（Consumer Group）：

消费者组是一个逻辑上的消费者集合，它们共同消费一个或多个主题中的消息。
每个消费者组都有一个唯一的组 ID。
消费者组允许多个消费者实例共同消费同一主题，从而实现负载均衡和容错。

消费者（Consumer）：

消费者是一个从 Kafka 主题读取消息的客户端应用程序实例。
每个消费者实例属于一个消费者组。

消费者组和分区的关系

负载均衡：
- 在同一个消费者组内，Kafka 将主题的分区分配给消费者组中的消费者实例。一个分区只能被同一消费者组中的一个消费者实例消费，但不同的消费者组可以并行消费同一个分区。
- 这种机制允许 Kafka 实现负载均衡：当消费者组中的消费者数量小于分区数量时，一些消费者会处理多个分区；当消费者数量大于分区数量时，一些消费者会处于空闲状态。
消费者实例的分配：
- 假设一个主题有 6 个分区（P0, P1, P2, P3, P4, P5），一个消费者组有 3 个消费者（C1, C2, C3）。
- Kafka 会将这 6 个分区分配给这 3 个消费者，例如：
  - C1 可能消费 P0 和 P3
  - C2 可能消费 P1 和 P4
  - C3 可能消费 P2 和 P5
消费者再平衡：
- 当消费者组内的消费者发生变化（例如，一个消费者加入或离开消费者组），Kafka 会触发重新平衡，将分区重新分配给当前的消费者实例。
- 这种再平衡确保每个分区都由消费者组中的一个消费者实例消费。

示例

假设你有一个主题 topicA，这个主题有 4 个分区，消费者组 groupA 有 2 个消费者。

主题 topicA 有分区 P0, P1, P2, P3。
消费者组 groupA 有消费者 C1 和 C2。

Kafka 可能会这样分配分区：

C1 消费 P0 和 P1
C2 消费 P2 和 P3

如果有一个新的消费者 C3 加入 groupA，Kafka 会触发再平衡，可能重新分配如下：

C1 消费 P0
C2 消费 P1 和 P2
C3 消费 P3

通过这种机制，Kafka 可以实现高吞吐量、负载均衡和高可用性。

重要特性

高吞吐量：由于分区可以并行处理，Kafka 能够处理大量的消息。
负载均衡：通过消费者组和分区的映射，实现消费者的负载均衡。
高可用性：分区和消费者组机制也使得系统在某个消费者故障时能够继续处理消息，保证了系统的高可用性。

这些概念和机制使得 Kafka 成为一个强大而灵活的消息队列系统，适用于各种实时数据流处理场景。如果有更多具体的问题或需要详细示例，请告诉我！

JVM

"Major GC"（也称为 Full GC）和 "Minor GC" 是 Java 虚拟机（JVM）中垃圾回收（Garbage Collection，GC）过程中的两种不同类型的垃圾回收事件。

Minor GC：

Minor GC 是针对新生代（Young Generation）的垃圾回收事件。在 Minor GC 中，JVM 会清理年轻代中不再被引用的对象，并且将仍然存活的对象移动到年老代（Old Generation）或持久代（PermGen/Metaspace）。
Minor GC 的频率通常与应用程序的对象分配速率相关。在活动的应用程序中，Minor GC 可能会更频繁地发生。
Minor GC 的发生通常不会导致应用程序停顿，因为它只涉及新生代的垃圾回收。

Major GC：

Major GC 是针对年老代或持久代的垃圾回收事件。在 Major GC 中，JVM 会清理年老代或持久代中的不再被引用的对象。
Major GC 的发生通常会导致应用程序的停顿，因为它需要遍历整个堆内存来进行垃圾回收，这可能需要一段时间。

对于 Minor GC 和 Major GC 的频率，适当性取决于应用程序的性能要求、堆内存的大小以及 GC 日志中显示的停顿时间。每秒 4-5 次 Minor GC 在某些场景下可能是合理的，但在其他情况下可能会导致性能问题。

问题思考处理:

堆内存大小：检查堆内存的大小是否足够满足应用程序的需求。频繁的 Minor GC 可能意味着堆内存太小，导致对象无法长时间存活在年老代中。
停顿时间：检查每次 Minor GC 的停顿时间。频繁的 Minor GC 可能会增加应用程序的停顿时间，影响用户体验。
对象生命周期：检查应用程序中对象的生命周期。频繁的 Minor GC 可能意味着有大量的短期对象被创建并迅速变为垃圾，这可能需要进一步优化。

JAVA THREAD

JIT Compilation 线程：这些线程负责执行即时编译 (Just-In-Time Compilation) 的任务，将 Java 字节码转换为本地代码以提高执行效率。这些线程通常会以 "JIT Compilation Thread" 开头命名，后面可能跟着一个编号。
GC 线程：这些线程负责执行垃圾回收任务。在提供的列表中，有一个 "GC Worker" 线程，这可能是执行垃圾回收的工作线程。
Finalizer 线程：这个线程负责执行对象的 finalize 方法，以便在对象被垃圾回收之前进行必要的清理工作。
Attach API wait loop 线程：这个线程是 Java Attach API 的等待线程，用于等待与 JVM 的连接请求。
I/O 线程：这些线程通常是用于处理输入/输出操作的，例如 "XNIO-1 I/O-1"、"XNIO-1 I/O-2" 等。
后台任务线程：这些线程可能是用于执行后台任务的，例如 "Common-Cleaner"、"VM Runtime State Listener" 等。
应用程序相关线程：还有一些线程可能是由应用程序代码创建和管理的，例如与数据库连接池相关的 "mysql-cj-abandoned-connection-cleanup"、"HikariPool-1 housekeeper" 等。