精诚所至,我的跳槽之路
天行健，君子以自强不息。 – 《周易·乾·象》
踏出熟悉的公司大门，我回头，知道以后应该不会经常回来，抬手，拍照，朋友圈里，我留下了“莫愁前路无知己，天下谁人不识君”的文字。
再见了，我将拥抱新的生活。再见了，我会有新的工作。
探秘CouchDB之centos下搭建CouchDB
CouchDB 是一个开源的面向文档的数据库管理系统，它具有高度可伸缩性，提供了高可用性和高可靠性。
CouchDB发布于2005年，2008年成为Apache软件基金会项目。CouchDB是一个面向文档的NoSQL数据库。
本系列笔者将记录对CouchDB的学习实战相关内容。
作为本系列第一篇，本文主要介绍如何在centos下搭建CouchDB，以及CouchDB的简单使用。
跟我学RocektMQ之理解长轮询机制
RoceketMQ提供了两种消息消费者，DefaultMQPushConsumer、DefaultMQPullConsumer。我们都知道DefaultMQPullConsumer是基于拉模式的消费，而DefaultMQPushConsumer是基于推模式的消费。我们先简单复习一下推拉模式的概念。
推模式：当服务端有数据立即通知客户端，这个策略依赖服务端与客户端之间的长连接，它具有高实时性、客户端开发简单等优点；同时缺点也很明显，比如：服务端需要感知与它建立链接的客户端，要实现客户端节点的发现，服务端本身主动推送，需要服务端对消息做额外的处理，以便能够及时将消息分发给客户端。
拉模式：客户端主动对服务端的数据进行拉取。客户端拉取数据，拉取成功后处理数据，处理完成再次进行拉取，循环执行。缺点是如果不能很好的设置拉取的频率，时间间隔，过多的空轮询会对服务端造成较大的访问压力，数据的实时性也不能得到很好的保证。
基于对上述两个策略的优缺点的综合考虑，RocketMQ的DefaultMQPushConsumer采用了结合了推拉模式两者优点的长轮询机制，对消息进行消费。这样，既能保证主动权在客户端，还能保证数据拉取的实时性。
本文我们就对RocketMQ的长轮询机制进行分析讲解，从而更好的理解RocketMQ的设计精巧之处。
首先了解一下什么是 长轮询 机制：
跟我学RocketMQ之定时消息源码解析
本文我们单独对RocketMQ的定时消息进行源码解析。
同事务消息类似，RocketMQ定时消息也是通过Topic替换，后台线程异步发送实现的。具体逻辑是通过org.apache.rocketmq.store.schedule.ScheduleMessageService实现的。
定时消息原理概述
在正式进行源码分析之前，我们先从概念上对定时消息做一个较为宏观的认知。
RocketMQ支持指定级别的消息延迟，默认为1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。
RocketMQ消息重试以及定时消息均是通过定时任务实现的。重试消息以及定时消息在存入commitLog之前会判断重试次数，如果大于0，则会将消息的topic设置为SCHEDULE_TOPIC_XXXX。
ScheduleMessageService在实例化之后会对SCHEDULE_TOPIC_XXXX主题下的消息进行定时调度，从而实现定时投递。
TCC-Transaction源码解析之事务补偿
上文中，我们对TCC-Transaction的事务提交阶段主流程进行了详细的解析。上文遗留了一个问题：
如果在事务执行过程中出现了down机、停电、网络异常等情况，事务一致性就无法得到保证，此时应该怎么做？
这个问题在TCC-Transaction框架中是通过定时任务+状态机方式实现的，这种方式也是我们日常开发中经常使用的一种策略。本文，我们对事务恢复主逻辑进行分析，使TCC-Transaction源码解析形成一个闭环。
TCC-Transaction源码解析之事务执行
TCC分布式事务解决方案在开源界的主要实现为Byte-TCC、TCC-Transaction等。其中笔者了解较多并且业界使用率较高的为TCC-Transaction这一实现。
本文，我将带领读者对TCC-Transaction这一分布式事务框架进行一次源码解析，提高自己的阅读源码的能力，也希望能够对读者深入了解TCC-Transaction有所帮助。
源码下载
源码地址为 https://github.com/changmingxie/tcc-transaction，我们关注最新版本1.2.x。
源码下载后导入IDEA中，项目目录结构如下图：
研磨Spring事件机制
Spring提供了应用程序事件特性为开发者提供了事件发布和接收事件的能力，它基于观察者模式实现，对于提升应用逻辑的松耦合很有意义。
本文就如何使用Spring事件机制进行较为详细的总结。
Spring事件概述
- 每一个Spring事件都需要继承ApplicationEvent的类，ApplicationEvent又继承自java.util.EventObject
- Spring中的任何bean都能够通过实现ApplicationListener
接口来监听事件；这里的泛型T就是上面提到的继承了ApplicationEvent的类 - SpringContext会对实现ApplicationListener接口的任意bean进行自动注册
- 发布事件是通过ApplicationEventPublisher.publishEvent方法实现的。应用中一般通过ApplicationContext进行事件发布，ApplicationContext实现了ApplicationEventPublisher接口
- 另一种发布事件的方式是bean实现ApplicationContextAware接口，拿到ApplicationContext实例从而实现事件发布
跟我学RocektMQ之事务消息提交及回查源码解析
跟我学RocketMQ之事务消息存储源码解析
我们接着对RocketMQ的事务消息的存储阶段源码进行解析。
事务消息正式发送阶段
首先接着上文，介绍一下事务消息正式发送阶段。
在DefaultMQProducerlmpl.sendKernelImpl方法中设置消息类型为事务消息：
final String tranMsg = msg.getProperty(MessageConst.PROPERTY_TRANSACTION_PREPARED);
if (tranMsg != null && Boolean.parseBoolean(tranMsg)) {
sysFlag |= MessageSysFlag.TRANSACTION_PREPARED_TYPE;
}
如果消息类型的确是事务消息，则设置sysFlag为事务消息标识== 0x1 << 2。方便broker对消息进行识别。
跟我学RocketMQ之事务消息发送源码解析
接下来我将通过一个小系列对RocketMQ事务消息进行一次较为全面的源码解析，本文主要对事务消息发送进行重点分析。
RocketMQ从4.3.0版本重新开源了事务消息，通过基于两阶段提交方式+定时回查机制，为分布式事务问题提供了新的解决方案。
