前面我写了一篇 「使用 Hexo + Gitee 快速搭建属于自己的博客」，很多人问起如果使用 md 写文章，图片如何快速地插入 md 文件中，我们都知道，md 格式与富文本格式不一样，md 的需要插入图片的访问地址，如果图片在本地，那么可以使用图片的本地存放地址，但如果你将 md 文件发给别人之后，图片的链接就失效了，这时我们就需要将图片存放在一个大家都能访问的地方，将这个地方的链接插入 md 文件即可，这就是图床。
但问题又来了，每次插入一张图片，我们总是要先将图片上传到图床，获取链接之后再将链接插入到 md 文件中，这个过程过于繁琐，且每次插入都在做重复的工作，今天我就跟大家分享一下，我是如何使用 PicGo 图床工具高效地解决上面的问题。
本文原创来自我部门框架组核心开发李文龙
先看下发现这个bug的一个背景，但背景中的问题，并非这个bug导致：
最近业务部门的一位开发同事找过来说，自己在使用公司的框架向数据库新增数据时，新增的数据被莫名其妙的回滚了，并且本地开发环境能够复现这个问题。公司的框架是基于SpringBoot+Mybatis整合实现，按道理这么多项目已经在使用了， 如果是bug那么早就应该出现问题。我的第一想法是不是他的业务逻辑有啥异常导致事务回滚了，但是也并没有出现什么明显的异常，并且新增的数据在数据库中是可以看到的。于是猜测有定时任务在删数据。询问了这位同事，得到的答案却是否定的。没有办法，既然能本地复现那便是最好解决了，决定在本地开发环境跟源码找问题。
程序员总会有一些技术文章的输出总结，很多人会选择各大第三方博客平台，但某些第三方博客平台的 UI 简直惨不忍睹，广告巨多，且对 md 格式支持得不够好等等，基于这些原因，我们有足够的理由搭建一套属于我们自己的博客。
我早在 17 年的时候就已经在 GitHub Pages 搭建了一套属于自己的博客，当时使用的 GitHub Pages 官方支持的 JekyII 工具进行部署，体验真的不是很好。后来的 Hexo 比它优秀太多了。现在 Gitee 也推出了自己的 Gitee Pages，由于是 Gitee Pages 的服务器是在国内的，因此访问速度非常快，而 GitHub 在国内的访问速度实在是惨不忍睹，于是我使用了 Hexo 在 Gtiee 搭建部署了另一个博客，下面我将搭建的整个过程总结写下来，也许能够帮助正在使用 Hexo 搭建博客的你。
各类消息中间件对顺序消息实现的做法是将具有顺序性的一类消息发往相同的主题分区中，只需要将这类消息设置相同的 Key 即可，而 Kafka 会在任意时刻保证一个消费组同时只能有一个消费者监听消费，因此可在消费时按分区进行顺序消费，保证每个分区的消息具备局部顺序性。由于需要确保分区消息的顺序性，并不能并发地消费消费，对消费的吞吐量会造成一定的影响。那么，如何在保证消息顺序性的前提下，最大限度的提高消费者的消费能力？
本文将会对 Kafka 消费者拉取消息流程进行深度分析之后，对 Kafka 消费者顺序消费线程模型进行一次实践与优化。
以前我们讨论的消费组，都是 group 的形式，group 可以自动地帮助消费者分配分区，且在发生异常时，还能自定地进行重平衡（Rebalance）。正常来说，group 帮助用户实现自动监听分区消费，但是在用户需要指定分区进行精确消费的场景下，由于 group 的重平衡机制，会打破这种消费方式，这不前段时间某项目就有个需求是这样的：
消息源端有若干个，每个消息源都会产生不同的消息，目标端也有若干个，每个目标端需要消费指定的消息源类型。
最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。
上次跟大家分享的文章「Kafka Producer 异步发送消息居然也会阻塞？」中提到了缓冲池，后面再经过一番阅读源码后，发现了这个缓冲池设计的很棒，被它的设计思想优雅到了，所以忍不住跟大家继续分享一波。
Kafka 一直以来都以高吞吐量的特性而家喻户晓，就在上周，在一个性能监控项目中，需要使用到 Kafka 传输海量消息，在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题，导致生产端发送耗时很大。
是的，你没听错，Kafka Producer 异步发送消息也会发生阻塞现象，那究竟是怎么回事呢？
某天小明处理的一些数据需要传给我这边处理，于是小明在我们的传输媒介上面新增了一个 Map 用于保存这些数据，数据结构如下：
public class Record {
private final Map<String, String> extData = new HashMap<>();
public void setData(String key, String data) {
extData.put(key, data);
}
public String getData(String key) {
return extData.get(key);
}
}
在小明猛如虎的一顿操作之下，告诉我数据已经放在 Record#extData 中了，自己调方法拿就好了，Map 的 Key 值就是 xxx 中的某个值，我一听懵了，我去哪找这个 Key 啊，得多费劲啊，都把我弄哭了。
于是，小明看出了我心里的憋屈，在项目的常量类中将相关的 Key 写成了常量的形式：
public class Constants {
public static final String KEY_1 = "key1";
public static final String KEY_2 = "key2";
public static final String KEY_3 = "key3";
}
于是我又得去找这个常量类中相关的 Key，但是相比之前，情况已经好很多了，把 Key 限定在了某个常量类中的某几个常量中。
但问题来了，只有我和小明知道我们之间的约定，那么如果有另外一个人去获取小明的 extData 数据呢？是不是又得问小明一遍？那小明得多忙啊？而且有些人就懒得问了，直接凭着自己的理解，传一个自己“参悟”得到的 Key 来获取 extData，这时很可能就跟小明给的不一样，导致数据获取不了。
于是小明特地为 extData 这个 Map 的 Key 定义了一个枚举，将 Key 定义到这个枚举上面：
public enum KeyEnum {
KEY_1,
KEY_2,
KEY_3
}
接着在 getter、setter 方法上面将 Key 的类型改成 Key 的枚举类型，在将 extData 的 Map 类型改成 EnumMap ：
public class Record {
private final Map<KeyEnum, String> extData = new EnumMap<>(KeyEnum.class);
public void setData(KeyEnum keyEnum, String data) {
extData.put(keyEnum, data);
}
public String getData(KeyEnum keyEnum) {
return extData.get(keyEnum);
}
}
据说，小明改完之后，终于没人再来打扰他安静写代码了！
DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库（MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。
前段时间我在 K8s 相关文章中有提到过数据同步的项目，该项目就是基于 DataX 内核构建的，由于公司数据同步的需求，还需要在 DataX 原有的基础上支持增量同步功能，同时支持分布式调度，在「使用 K8s 进行作业调度实战分享」这篇文章中已经详细描述其中的实现。
基于我在项目中对 DataX 的实践过程，给大家分享我所理解的 DataX 核心设计原理。