RocketMQ 日志基于 slf4j 实现，支持 Logback、Log4j。如果需要指定日志的配置文件的位置有三种方式：
ROCKETMQ_CLIENT_LOG_CONFIGFILE=<custom-file>rocketmq.client.log.configFile=<customer-file>，作为 JVM 变量，启动时时需要增加 -D 标识，优先级也比环境变量更高System.getProperty() 或者 System,getenv() 得到的，所以可以在程序入口 System.setProperty(“rocketmq.client.log.configFile”, customer_file) 来配置上一篇介绍完了 RocketMQ 消费者的默认实现，现在来瞅一瞅生产者的用法。
同样的，是 DefaultMQProducer，新建实例之后，在使用生产者发送消息之前，需要初始化几个属性：
InstanceName 实例名称RetryTimesWhenSendFailed 重试次数NamesrvAddr结束了对 RocketMQ 组件的初步理解以及配置的简单设定，可以对 RocketMQ 仔细研究一番了。先来看看 RocketMQ 的消费者实现，以及服务端是如何处理消费者客户端的请求，把消息送出去的。
RocketMQ 对于消费者客户端，支持推模型和拉模型。对于推模型，由消息服务端作为主动方，向客户端推送消息（尽管其本质是一个长轮询式的拉模型实现）；而拉模型由客户端主动拉取消息。
RocketMQ 的配置分为两部分，一者是 JVM 的配合，另一者则是对 Broker 应用本身的参数配置。
在初次接触时候，除了 RocketMQ 本身的一些特性，同时也难免会被一些配置给迷惑或者踩坑，这里来看一下通常的配置点。
目前被广泛使用的 MQ 有很多，包括 ActiveMQ，Kafka，RabbitMQ，RocketMQ 等等，它们各有长短。而近期所在项目选择了 RocketMQ 作为消息中间件，此前并未系统地了解研究，所以趁此机会整理了一些笔记和想法。
MyBatis 作为一个目前很常用的持久化框架，有着丰富的拓展。这些拓展功能常常以插件的形式嵌入到 MyBatis 的运作流程之中，而如何制作实现一个插件？MyBatis 已经为大家设计好了，一个 Interceptor 接口，实现它就够了。
Interceptor 接口的拦截目标，是 MyBatis 运作流程中的几个核心组件：
Executor：这是 MyBatis 执行器，控制着所有和数据库交互的操作，也影响着一级缓存。ParameterHandler：参数处理器，在映射参数时候生效。ResultSetHandler：结果集处理器，在处理结果集的时候会用到。StatementHandler：Executor 下层的处理器，同样控制着 SQL 行为，也控制着二级缓存的生效。Docker 镜像是层层分离的，分为只读的底层和可读写的当前层。容器在运行时候如果有文件改动，会自动从含有该文件的底层拷贝并更新在当前层。如果容器在 commit 之前被销毁，那么有这个镜像重新生成的容器是不包含改动的内容的。
在描述 Dockerfile 的时候，对于 RUN，CMD，ENTRYPOINT 三个命令，用法十分相似，功能也差不多，容易让人混用。其实一般来说，三个命令都能完成需要的操作，而差异点常常被一些使用者忽略。这里简单说一下，三个命令的不同之处。
sed 是非常常用的流式处理编辑工具，配合正则表达式可以进行十分效率的文字处理。它通过逐行地将文字读取，暂存进模式空间，通过指定的命令进行处理后，输出至标准输出，直到文件或者说输入的结束。原理十分简单，来学习一下吧。
java.util.concurrent 包中提供了许多易用而有效的工具类，诸如 ReentrantLock，CountDownLatch，Semaphore 等等，给日常的并发编程带来了许多便利。他们都使用了同样的框架来完成基本的同步过程：AbstractQueuedSynchronizer （AQS）来实现基本功能，比如获取资源和释放的步骤。