前提

创业小团队,无论选择任何方案,都优先考虑节省成本。关于分布式定时调度框架,成熟的候选方案有XXL-JOBEasy SchedulerLight Task SchedulerElastic Job等等,其实这些之前都在生产环境使用过。但是想要搭建高可用的分布式调度平台,这些框架(无论是否去中心化)都需要额外的服务器资源去部署中心调度管理服务实例,甚至有时候还会依赖一些中间件如Zookeeper。回想之前花过一段时间看Quartz的源码去分析它的线程模型,想到了它可以基于MySQL,通过一个不是很推荐的X锁方案(SELECT FOR UPDATE加锁)实现服务集群中单个触发器只有一个节点(加锁成功的那个节点)能够执行,这样子,就能够仅仅依赖于现有的MySQL实例资源实现分布式调度任务管理。一般来说,有关系型数据保存需求的业务应用都会有自己的MySQL实例,这样子就能几乎零成本引入一个分布式调度管理模块。某个加班的周六下午敲定了初步方案之后,花了几个小时把这个轮子造出来了,效果如下:

前提

近段时间,业务系统架构基本完备,数据层面的建设比较薄弱,因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据(包括保存、更新或者软删除)到一个另一个数据源,持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力,优先调研了Alibaba开源中间件Canal的使用。

这篇文章简单介绍一下如何快速地搭建一套Canal相关的组件。

前提

未来一段时间开发的项目或者需求会大量使用到Redis,趁着这段时间业务并不太繁忙,抽点时间预习和复习Redis的相关内容。刚好看到博客下面的UVPV统计,想到了最近看书里面提到的HyperLogLog数据类型,于是花点时间分析一下它的使用方式和使用场景(暂时不探究HyperLogLog的实现原理)。RedisHyperLogLog数据类型是Redid 2.8.9引入的,使用的时候确保Redis版本>= 2.8.9

前提

最近忙于业务开发、交接和游戏,加上碰上了不定时出现的犹豫期和困惑期,荒废学业了一段时间。天冷了,要重新拾起开始下阶段的学习了。之前接触到的一些数据搜索项目,涉及到请求模拟,基于反爬需要使用随机的User Agent,于是使用Redis实现了一个十分简易的UA池。

前提

最近学习Netty的时候想做一个基于Redis服务协议的编码解码模块,过程中顺便阅读了Redis服务序列化协议RESP,结合自己的理解对文档进行了翻译并且简单实现了RESP基于Java语言的解析。编写本文的使用使用的JDK版本为[8+]

前提

Redis5.x之后,单机、哨兵、集群搭建的难度已经简化。鉴于目前看到太多文章都是复制粘贴以往一些3.x版本的一些内容,所以打算基于当前Redis的最新版本做一次单机、哨兵和集群的搭建,记录一下过程步骤和遇到的问题。编写本文的时间是2019年10月6日(国庆假期…),当前Redis的最新版本为5.0.5。操作系统用的是虚拟机里面安装的CentOS 7。先确定已经安装好Redis服务,可以参考笔者写的前一篇文章:《Redis5.x单机服务搭建手记》。出于书写习惯,本文有可能把哨兵称为SentinelRedis Sentinel、哨兵或者Redis哨兵,这四个名词是等价的。

Redis5.x之后,单机、哨兵、集群搭建的难度已经简化。鉴于目前看到太多文章都是复制粘贴以往一些3.x版本的一些内容,所以打算基于当前Redis的最新版本做一次单机、哨兵和集群的搭建,记录一下过程步骤和遇到的问题。编写本文的时间是2019年10月5日(国庆假期…),当前Redis的最新版本为5.0.5。操作系统用的是虚拟机里面安装的CentOS 7

前提

Lettuce是一个RedisJava驱动包,初识她的时候是使用RedisTemplate的时候遇到点问题Debug到底层的一些源码,发现spring-data-redis的驱动包在某个版本之后替换为LettuceLettuce翻译为生菜,没错,就是吃的那种生菜,所以它的Logo长这样:

m-r-c-l-1

既然能被Spring生态所认可,Lettuce想必有过人之处,于是笔者花时间阅读她的官方文档,整理测试示例,写下这篇文章。编写本文时所使用的版本为Lettuce 5.1.8.RELEASESpringBoot 2.1.8.RELEASEJDK [8,11]超长警告:这篇文章断断续续花了两周完成,超过4万字…