前提

在很早很早之前，写过一篇文章介绍过Redis中的red lock的实现，但是在生产环境中，笔者所负责的项目使用的分布式锁组件一直是Redisson。Redisson是具备多种内存数据网格特性的基于Java编写的Redis客户端框架（Redis Java Client with features of In-Memory Data Grid），基于Redis的基本数据类型扩展出很多种实现的高级数据结构，具体见其官方的简介图：

本文要分析的R(ed)Lock实现，只是其中一个很小的模块，其他高级特性可以按需选用。下面会从基本原理、源码分析和基于Jedis仿实现等内容进行展开。本文分析的Redisson源码是2020-01左右Redisson项目的main分支源码，对应版本是3.14.1。

前提

半年前（2020-06）左右，疫情触底反弹，公司的业务量不断提升，运营部门为了方便短信、模板消息推送等渠道的投放，提出了一个把长链接压缩为短链接的功能需求。当时为了快速推广，使用了一些比较知名的第三方短链压缩平台，存在一些问题：

• 收费贵
• 一些情况下，短链域名在部分第三方平台例如微信会被封杀
• 回源数据没有办法定制处理方案，无法打通整个业务链路进行数据分析和跟踪

基于此类问题，决定自研一个（长链接压缩为）短链接服务，当时刚好同步进行微服务拆分，内部很多微服务需要重新命名，组内的一个妹子说不如就用Github的吉祥物去命名octopus cat（章鱼猫）去命名，但是考虑到版权问题，去掉了她最喜欢的猫，剩下章鱼，以octopus命名：

（项目的描述还打错字了，应该是"短链接"）因为实现的功能并不复杂，初版于2020-06月底就发布。octopus的实现参考了互联网中几篇关于"短链服务实现"浏览量比较高的文章，下面从实现原理、服务实现和部署架构等方面展开谈谈。

前提

这篇文章是基于Linux系统CentOS7搭建Hadoop-3.3.0分布式集群的详细手记。

前提

前面一篇文章已经很详细地介绍了ClickHouse中每种数据类型的定义和基本使用，这篇文章会详细地介绍ClickHouse中的DDL和DML，很多操作区别于传统的DBMS，特别是代价巨大的DELETE和UPDATE操作。接下来开始吧💪💪

一般情况下，笔者建议ClickHouse的关键字全用大写，这样可以更加凸显出自定义的驼峰命名和大写关键字的不同，可读性和可维护性更高

本文使用的ClickHouse服务版本为当前最新的20.10.3.30

前提

前边一篇文章详细分析了如何在Windows10系统下搭建ClickHouse的开发环境，接着需要详细学习一下此数据库的数据定义，包括数据类型、DDL和DML。ClickHouse作为一款完备的DBMS，提供了类似于MySQL（其实有部分语法差别还是比较大的）的DDL与DML功能，并且实现了大部分标准SQL规范中的内容。系统学习ClickHouse的数据定义能够帮助开发者更深刻地理解和使用ClickHouse。本文大纲（右侧分支）👇👇

本文会详细分析ClickHouse目前最新版本（20.10.3.30）支持的所有数据类型。

前提

随着现在业务开展，几个业务系统的数据量开始急剧膨胀。之前使用了关系型数据库MySQL进行了一次数据仓库的建模，发现了数据量上来后，大量的JOIN操作在提高了云MySQL的配置后依然有点吃不消，加之开发了一个基于关系型数据库设计的标签服务，日全量标签数据（无法避免的笛卡尔积）单表超过5000W。目前采取了基于用户ID分段配合多进程处理的方式暂时延缓了性能的恶化，但是考虑到不远将来，还是需要做一个小型的数据平台。Hadoop的那套体系过于庞大，组件过多，硬件和软件的学习成本比较高，不是一朝一夕可以让小团队的所有成员掌握。考虑到这么多因素的前提下，需要调研ClickHouse这项黑科技，看看使用他能不能突围困局。

前提

笔者目前需要搭建数据平台，发现了Windows系统下，Hadoop和Hive等组件的安装和运行存在大量的坑，而本着有坑必填的目标，笔者还是花了几个晚上的下班时候在多个互联网参考资料的帮助下完成了Windows10系统下Hadoop和Hive开发环境的搭建。这篇文章记录了整个搭建过程中的具体步骤、遇到的问题和对应的解决方案。

前提

笔者之前在查找Sentinel相关资料的时候，偶然中找到了Martin Fowler大神的一篇文章《CircuitBreaker》。于是花了点时间仔细阅读，顺便温习一下断路器CircuitBreaker的原理与实现。

前提

在某一次用户标签服务中大量用到异步流程，使用了RabbitMQ进行解耦。其中，为了提高消费者的处理效率针对了不同节点任务的消费者线程数和prefetch_count参数都做了调整和测试，得到一个相对合理的组合。这里深入分析一下prefetch_count参数在RabbitMQ中的作用。

前提

这是一篇憋了很久的文章，一直想写，却又一直忘记了写。整篇文章可能会有点流水账，相对详细地介绍怎么写一个小型的"框架"。这个精悍的胶水层已经在生产环境服役超过半年，这里尝试把耦合业务的代码去掉，提炼出一个相对简洁的版本。

之前写的几篇文章里面其中一篇曾经提到过Canal解析MySQL的binlog事件后的对象如下（来源于Canal源码com.alibaba.otter.canal.protocol.FlatMessage）：

如果直接对此原始对象进行解析，那么会出现很多解析模板代码，一旦有改动就会牵一发动全身，这是我们不希望发生的一件事。于是花了一点点时间写了一个Canal胶水层，让接收到的FlatMessage根据表名称直接转换为对应的DTO实例，这样能在一定程度上提升开发效率并且减少模板化代码，这个胶水层的数据流示意图如下：

要编写这样的胶水层主要用到：

• 反射。
• 注解。
• 策略模式。
• IOC容器（可选）。

项目的模块如下：

• canal-glue-core：核心功能。
• spring-boot-starter-canal-glue：适配Spring的IOC容器，添加自动配置。
• canal-glue-example：使用例子和基准测试。

下文会详细分析此胶水层如何实现。