水煮Redisson

断断续续写了小半年，刚开始也没想写这么多，只是随便写了几篇，技术体系的文章写起来，格式千篇一律，感觉没有什么新意，更谈不上什么美感。现在回头看过去，就像是电器说明书，感觉稍稍有点无聊。

Redis stream的前身disque，是redis作者开发的一个redis module，因为一些原因，在Redis5.0版本被内置为一种全新的数据结构，提供了消息持久化和主备复制功能等。

这里简单介绍一下Geo内核-GeoHash的原理。简单来说，GeoHash将三维的地球模型抽象成一维数据，每个节点代表了一个矩形区域，方便计算附近节点集合和相应的距离。

Redis提供了GEO地理索引的实现，其存储结构本质上来说是一个ZSET，这一点可以从Redisson中的GEO接口看出来【RScoredSortedSetAsync】...

这一章介绍Redisson中的批处理类【RBatch】，功能上类似redis的管道操作，在同一个请求中，发送多条指令，节省网络I/O时间。

这一章节主要研究在Redisson中，是怎么处理一个redis请求的。Redisson的处理核心类是【RedisExecutor】，所有的请求都会走到这里，经由Netty网络框架，与Redis服务交互

看门狗的定义，在之前一个小章节中已经有简单说明，这里不做赘述。但是之前只是说了其与持有时间，等待时间的区别，没有详细介绍，下面我们来进行深入分析，解开迷雾。

前言 联合锁和红锁放在一起来分析，是因为这两种锁实现在Redisson中，关联密切。 红锁 上面getRedLock方法上有@Deprecated注解，说明在Redisson实现中，不推荐使用红锁。

Redis原始指令SETNX，因为其独特的设计，同时满足独占性和超时机制，因此很多从业者利用这些特性来实现分布式锁，但是有很多弊端。

单独设置这一章节，是因为这几个重要参数：waitTime、leaseTime和lockWatchdogTimeout，在后续各种锁的实现中，频繁出现，需要提请弄清楚，否则会带来不小的困扰。

读锁是共享的，写锁是排他的，使用与读多写少的业务场景。 写锁的实现【RedissonWriteLock】，继承自非公平锁...

读锁是共享的，写锁是排他的。 读锁的实现RedissonReadLock，继承自非公平锁RedissonLock，主要重写了下面几个方法...

在分析Redisson分布式锁实现之前，不妨先看看接口定义，可以让源码的阅读更加顺畅，磨刀不误砍柴工。 接口中的方法不多，只有下面这十五个，其中很多看名称就大概知道其功能。

前面介绍Redisson锁的时候，忽略了一个细节，就是在lua脚本中，获取锁的时候，返回的nil，而在lua语义中，nil应该是false或者空，为什么不返回true呢？

在特定场合下，比如开放式的名额申请，如果某一个客户端直到等待超时也获取不到锁，一直不能拿到名额走下一步业务流程，会造成平台不公平的非议。对于类似的情况，需要用公平锁来保障用户的体验和权益。

上一章介绍了分布式锁的基本概念和一些实现方式，其中就有Redis的实现方案。Redisson是Redis官方推荐的Java客户端，Redisson有几种不同锁的实现...

在许多场景下，多个节点需要保持数据的一致性，为了保证这一特性，就诞生了分布式锁这样特殊的产物。 一个分布式锁要产生效果，需要存在三种特性：互斥性，超时机制，可重入。

简介 接上文，redisson也有RingBuffer的实现，采用list的结构来实现,RRingBuffer继承自RQueue接口,使用RRingBuffer的开发人员还可以访问基于队列的方法...

环形缓冲器（ringr buffer），是一种用于表示一个固定尺寸、头尾相连的缓冲区的数据结构，适合缓存数据流。

本文设定的误判率逻辑：在布隆过滤器中写入test0-test100000的数据，然后校验test100000-test200000是否在布隆过滤器中，如果存在，则表示发生了误判。