前提

UUID是Universally Unique IDentifier的缩写，翻译为通用唯一标识符或者全局唯一标识符。对于UUID的描述，下面摘录一下规范文件A Universally Unique IDentifier (UUID) URN Namespace中的一些描述：

UUID（也称为GUID）定义了统一资源名称命名空间。UUID的长度为128比特，可以保证在空间和时间上的唯一性。

动机：

使用UUID的主要原因之一是不需要集中式管理，其中一种格式限定了IEEE 802节点标识符，其他格式无此限制。可以自动化按需生成UUID，应用于多重不同的场景。UUID算法支持极高的分配速率，每台机器每秒钟可以生成超过1000万个UUID，因此它们可以作为事务ID使用。UUID具有固定大小128比特，与其他替代方案相比，它具有体积小的优势，非常适用于各种排序、散列和存储在数据库中，具有编程易用性的特点。

这里只需要记住UUID几个核心特定：

• 全局时空唯一性
• 固定长度128比特，也就是16字节(1 byte = 8 bit)
• 分配速率极高，单机每秒可以生成超过1000万个UUID（实际上更高）

下面就JDK中的UUID实现详细分析一下UUID生成算法。编写本文的时候选用的JDK为JDK11。

前提

在很早很早之前，写过一篇文章介绍过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中的作用。