jedis

什么是redis？ Redis是一种可基于内存亦可持久化的日志型、Key-Value数据库，支持的存储类型非常丰富，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。（具体介绍请参照百度百科） 为什么快？  纯ANSI C编写。  所有数据均存放在内存中，当然不包括持久化。  不依赖第三方类库，没有像memcached那样使用libevent。  Redis多样的数据结构，每种结构只做自己爱做的事，当然比数据库只有Table，MongogoDB只有JSON一种结构快了。 Redis支持的功能：  所有数据都在内存中。  五种数据结构：String / Hash / List / Set / Ordered Set。  数据过期时间支持。  不完全的事务支持。  服务端脚本：使用Lua Script编写，作用类似存储过程。  PubSub：捞过界的消息一对多发布订阅功能，起码Redis-Sentinel在使用它。  持久化：支持定期导出内存的RDB与 记录写操作日志的Append Only File两种模式。  Replication：Master-Slave模式，Master可连接多个只读Slave。  Fail-Over：Redis

转载地址: https://juejin.im/post/5ba0a098f265da0adb30c684 前言 在实际项目开发过程中，相信很多人都有用到过 redis 这个NoSQL,这篇文章就详细讲讲springboot如何整合 redis Redis 简介 简单介绍下Redis： Redis是一个开源的使用 ANSI C语言编写，支持网络，可基于内存也可持久化的日志型，Key-Value数据库，并提供了多种语言的 API ,相比 Memcached 它支持存储的类型相对更多 (字符，哈希，集合，有序集合，列表等)，同时Redis是线程安全的。 Redis 连接池简介 在后面 springboot 整合 redis 的时候会用到连接池，所以这里先来介绍下 Redis中的连接池: 客户端连接 Redis 使用的是 TCP协议，直连的方式每次需要建立 TCP连接，而连接池的方式是可以预先初始化好客户端连接，所以每次只需要从 连接池借用即可 ，而借用和归还操作是在本地进行的，只有少量的并发同步开销，远远小于新建TCP连接的开销。另外，直连的方式无法限制 redis客户端对象的个数，在极端情况下可能会造成连接泄漏，而连接池的形式可以有效的保护和控制资源的使用。 下面以Jedis客户端为例，再来总结下 客户端直连方式和连接池方式的对比 优点 缺点 直连 简单方便，适用于少量长期连接的场景

JedisPoolConfig config = new JedisPoolConfig(); //连接耗尽时是否阻塞, false报异常,ture阻塞直到超时, 默认true config.setBlockWhenExhausted( true ); //设置的逐出策略类名, 默认DefaultEvictionPolicy(当连接超过最大空闲时间,或连接数超过最大空闲连接数) config.setEvictionPolicyClassName( "org.apache.commons.pool2.impl.DefaultEvictionPolicy" ); //是否启用pool的jmx管理功能, 默认true config.setJmxEnabled( true ); //MBean ObjectName = new ObjectName("org.apache.commons.pool2:type=GenericObjectPool,name=" + "pool" + i); 默 认为"pool", JMX不熟,具体不知道是干啥的...默认就好. config.setJmxNamePrefix( "pool" ); //是否启用后进先出, 默认true config.setLifo( true ); //最大空闲连接数, 默认8个 config.setMaxIdle( 8 );

我们知道，在 Java 编程过程中，如果打开了外部资源（文件、数据库连接、网络连接等、redis)，我们必须在这些外部资源使用完毕后，手动关闭它们。 因为外部资源不由 JVM 管理，无法享用 JVM 的垃圾回收机制，如果我们不在编程时确保在正确的时机关闭外部资源，就会导致外部资源泄露，紧接着就会出现文件被异常占用，数据库连接过多导致连接池溢出**等诸多很严重的问题。 JDK7 之前的资源关闭方式 /** * jdk7以前关闭流的方式 * */ public class CloseResourceBefore7 { private static final String FileName = "file.txt"; public static void main(String[] args) throws IOException { FileInputStream inputStream = null; try { inputStream = new FileInputStream(FileName); char c1 = (char) inputStream.read(); System.out.println("c1=" + c1); } catch (IOException e) { e.printStackTrace(); } finally { if

ZooKeeper分布式锁的实现原理 在分布式解决方案中，Zookeeper是一个分布式协调工具。当多个JVM客户端，同时在ZooKeeper上创建相同的一个临时节点，因为临时节点路径是保证唯一，只要谁能够创建节点成功，谁就能够获取到锁。没有创建成功节点，就会进行等待，当释放锁的时候，采用事件通知给客户端重新获取锁资源。如果请求超时直接返回给客户端超时，重新请求即可。 代码实现 为了更好的展现效果，我这里设置每个线程请求需要1s，请求超时时间为30s。 首先我们先写一个测试类，模拟多线程多客户端请求的情况： public class ZkLockTest implements Runnable { private ZkLock zkLock = new ZkDistributedLock(); public void run() { try { if (zkLock.getLock((long)30000,null)) { System.out.println("线程:" + Thread.currentThread().getName() + ",抢购成功:" + System.currentTimeMillis()); } else { System.out.println("线程:" + Thread.currentThread().getName() + "

什么是分布式锁 要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 1.线程锁 主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。 2.进程锁 为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。 3.分布式锁 当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。 分布式锁的由来 在传统单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。 但是在分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁的由来。 当多个进程不在同一个系统中，就需要用分布式锁控制多个进程对资源的访问。 分布式锁的特点 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件： **1、互斥性：**任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。 **2、安全性：*

redis 支撑许多言语的客户端。在官方网站上有支撑的一切的 [redis 客户端列表]。 　　因为往常运用 java 作为开发言语，所以这儿描绘一下怎样通过 java 来联接和操作 redis 服务器。在官方文档中， Java 推荐的 redis 客户端是 Jedis ，这儿我们也用这个客户端对 redis 服务器进行操作。 　　引进依托 　　首要我们建立一个 maven 工程，在工程的 pom.xml 文件中参加 Jedis 的依托引证。为了便当查验，还参加了 Junit 依托。文件内容如下。 　　 　　 　　xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 　　xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 　　4.0.0 　　com.x9710.common 　　redis-util 　　1.0-SNAPSHOT 　　 　　 　　commons-logging 　　commons-logging 　　1.1.1 　　 　　 　　log4j 　　log4j 　　1.2.17 　　 　　 　　redis.clients 　　jedis 　　2.9.0 　　 　　 　

一、什么是Redis？ 这两年对于 NoSQL(not only SQL) 的使用已经越加频繁，所以对于Redis是什么我们也不会太过陌生。简单来说，Redis就是一个开源的，Key-Value数据库。它的存在主要是为了减少对SQL的读取，来提高服务器响应时间，典型的空间换时间策略。 二、Redis的安装与命令 这个太多，请看官网： https://redis.io/ 教程： http://www.runoob.com/redis/redis-tutorial.html 三、简单Java项目中的引用测试 1、导入Jar包： jedis-2.9.0.jar 、commons-pool2-2.5.0.jar 2、测试： package redis; import java.util.HashMap; import java.util.Iterator; import java.util.List; import java.util.Map; import java.util.Set; import org.junit.Test; import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisPool; import redis.clients.jedis.JedisPoolConfig; public class

Redis 集群的历史 Redis 在 3.0 前一般有两种集群方案，一是 proxy（Twemproxy、Codis），二是使用 Sentinel(哨兵）。 通过 Sentinel 是一种使用哨兵来达到高可用的方案，而 proxy 是用于在前置上进行 sharding 用代理给后端的 redis 集群的方案，达到负载均衡的方案，在单个分片的 redis 中作主从。 因为本文要重点讲解的不是 3.0 前的方案，因此说的比较粗略。 Redis3.0 提供了官方的 Redis cluster 机制支持。主要通过内部无中心的多个节点来达到集群、高可用的作用。下面是 Redis Cluster 的架构图： Redis Cluster 的重要机制 sharding 由 Redis cluster 根据 client 调用 redis 的 key 进行 hash 取模得到一个 code，根据这个 code 放到 16384 个 slot 中。在以上的架构图中 slot1 组、slot2 组、slot3 组服务器中分别是对应的差不多 1/3 的 slot。这样就得到了根据 key 的 shading。 说到 sharding 就会说到怎么进行扩容和缩容，redis cluster 也提供了工具进行迁移。 不过由于不是一致性 hash，所以涉及到迁移数据的节点数会多于一致性 hash