准备环境

本次我选择的环境是 7.X 中目前最新的 7.17 版本，代码下载下来之后，需要关注的文件有以下三个：

• CONTRIBUTING.md
• gradle.properties
• gradle-wrapper.properties

CONTRIBUTING.md 中的 Contributing to the Elasticsearch codebase部分详细说明了需要的 JDK 版本，

在上一次的《从回收算法理解JVM》 中只是简单的提到了分区 GC，本篇文章针对 G1 做了进一步的总结，并解释了无停顿 GC 的部分实现原理

提到 JVM 的话大家会想到什么呢？是它的内存区域划分，各种 GC 收集器？又或者是垃圾回收算法？常见的 JVM 参数？

这些问题可能大家已经耳熟能详了。但大家是否有思考过为什么会有多种回收算法，他们分别适应什么样的场景，有什么优劣性质。他们是如何解决跨代引用，如何处理业务线程与 GC 线程的并发等等。本篇文章会从回收算法入手，逐个分析这些问题。

1.Kafka是什么？

kafka 是一款由 scala 语言编写的，基于 ”发布/订阅“ 模式的高性能消息中间件。它的组成部分包括了 provider、consumer、partition（分区）、topic（主题）、broker（节点）几个。

在 kafka 中，topic 与 partition 之间是一对多的关系，一条消息只会发送到一个特定的 topic 中，随后根据 kafka 的负载均衡策略，分配到不同的 partition 中（每一个 partition 中的数据是有序的），而 partition 又分可以分为 主分区、副本分区，用于实现多个机器上的分布式存储，以此实现了高可用。

kafka 的常见应用场景有两种，一种是当做常规的消息中间件来使用，另一种是作为流处理技术使用它的 kafka stream（未使用过）

1.消息队列的应用场景：

• 解耦：将不同的系统之间解耦开来，比如说我有一个上游的订单系统，订单完成之后，我需要操作 A库存系统、B用户系统 来进行扣库存、增加会员积分等等操作。现在 A,B 子系统都需要来对接我的执行结果。不解耦的话，需要在订单的代码里编码来执行。如果 A,B 发生需求变更的话就会改动订单系统的代码。而使用消息队列之后，就不需要关心下游系统的具体逻辑了，由 A,B 自行通过订阅的方式来进行逻辑处理。
• 异步：（事件驱动）同步执行流程时间长，或者说用户并不关心邮件发送成不成功，只要购买成功就可以了。
• 削峰（限流）：这个只有在大并发场景才会用到，如果我的请求非常多，那么我可能会把请求先放到消息队列中，去排一下队，避免把应用直接压垮。这里其实会牵扯到有关联性其它问题，比如说：
  阅读全文 »