qq_40837310的博客

StringString类型，可以用来存储字符串、整型、浮点型数据、甚至二进制数据（因为redis的String类型是二进制安全的）。常用命令：#设置多个值，原子性。mset aaa 2673 bbb 666#如果key存在，就设置不成功，分布式锁的原理。setnx qingshan #Ex 秒数 或者 PX 毫秒数 设置过期时间#NX（存在不设置）/XX （存在也设置）set key value [expiration EX seconds|PX milliseconds][NX|X

Redisson概述Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subs

背景：缓存一致性的产生原因是为了提高系统的吞吐量，通常会把一些即时性、数据强一致性要求不高的，或者访问量大且更新频率不高（读多写少） 的数据从数据库中读取并放到缓存中，提高系统的IO速度，从而提高吞吐量。这样就会产生一些问题：缓存穿透。缓存雪崩。缓存击穿。缓存一致性问题。缓存穿透只查询一个一定不存在的数据，由于缓存是不命中的，将会去查询数据库，但是数据库也没有此记录，返回null值，并且我们没有将这次查询的null值存入缓存中，这将导致这个不存在的数据每次请求都要去存储层去查询，失去了缓

背景如果我们使用缓存，那样会带来缓存三大问题，缓存穿透、缓存雪崩、缓存击穿。这里针对缓存穿透并使用布隆过滤器解决。缓存穿透就是有心用户利用缓存和数据库都必不存在的数据来发送恶意请求，从而绕过缓存，直接访问数据库，最终导致数据库崩溃的问题。这是一个通用的问题，关键就在于我们怎么知道请求的 key 在我们的数据库里面是否存在，如果数据量特别大的话，我们怎么去快速判断。这个问题是如何在海量元素中（例如 10 亿无序、不定长、不重复）快速判断一个元素是否存在。这个问题涉及两个关键点：海量数据、快速判断。

为什么需要集群和高可用为什么需要主从复制主要是安全性和可用性的考虑，如果只有一个redis服务，一旦服务宕机，那么所有的客户端无法访问，会对业务造成很大影响，另一个是一旦硬件损坏，单机无法恢复，会对数据带来灾难性影响。另一个考虑是性能的提升，主从复制模式，写请求只能由master节点来处理，但是读请求可能用从节点来分担请求，提高效率。可用性、数据安全、性能都可以通过搭建多个 Reids 服务实现。其中有一个是主节点（master），可以有多个从节点(slave)。主从之间通过数据同步，存储完全相同的数

概述Redis所有数据都存在内存中，在某些时候需要对占用的内存空间进行回收，内存回收主要分为两类，一类是key过期，一类是内存使用达到上限，触发内存淘汰。Key过期策略要实现key过期，有几种思路：定时淘汰（主动淘汰）每个设置了过期时间的key都会设置一个定时器，定时时间为key的过期时间，然后key过期了，定时器也正好触发，就会立即清除过期的那个key，该策略可以立即清除过期的数据，对内存很友好，但是因为创建了大量定时器，会占用大量的CPU，从而影响缓存的响应时间和吞吐量。惰性淘汰只有当访问

思路所有响应获取锁的线程都先尝试往redis中创建一个缓存数据，所有线程的key必须相同。使用的是redis的setnx命令。就只有一个线程能够创建成功，创建成功的线程就成功获取锁。没有获取锁的线程就循环去获取锁。获取锁的线程在执行完业务后释放锁，也就是删除该key，然后后面的线程重新获取锁时就会有线程能够获取锁成功。可能出现的问题：假如线程在创建锁以后，出现了异常，走不到释放锁的那一步，那么这个锁就会变成死锁。所以解决方案是给锁（也就是给redis的key加个过期时间，过期了锁还存在的话就

一般配置：如果要用配置文件来启动redis的话，配置文件的路径必须是第一个参数，例如：./redis-server /xxx/xxx/redis.conf。如果要用到计算机存储单位的话，要注意以下：a) 1k = 1000byte.b) 1kb = 1024byte.c) 1M = 10001000byte.d) 1Mb = 10241024byte.e) 1G = 100010...