Redis数据结构扩展及缓存问题

redis内容扩展

1、Pipeline

Pipeline指的是管道技术，指的是客户端允许将多个请求依次发给服务器，过程中而不需要等待请求的回复，在最后再一并读取结果即可。

管道技术使用广泛，例如许多POP3协议已经实现支持这个功能，大大加快了从服务器下载新邮件的过程。

Redis很早就支持管道（pipeline）技术。(因此无论你运行的是什么版本，你都可以使用管道（pipelining）操作Redis)

注意：使用Pipeline的操作是非原子操作。

2、GEO

Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。
GEOADD locations 116.419217 39.921133 beijin
GEOPOS locations beijin
GEODIST locations tianjin beijin km 计算距离
GEORADIUSBYMEMBER locations beijin 150 km 通过距离计算城市
注意：没有删除命令，它的本质就是zset（type locations）
所以可以使用zrem key member 删除元素
zrange key 0 -1 表示所有 返回指定集合中所有value。

3、HyperLogLog

Redis在2.8.9版本添加了HyperLogLog结构。

Redis HyperLogLog是用来做基数统计的算法，HyperLogLog的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总时固定的，并且很小的。

在Redis里面，每个HyperLogLog键只需要花费12KB内存，就可以计算接近2^64个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明的对比。

PFADD 2022_03_11:test 'yes' 'yes' 'yes' 'yes' 'no'
PFCOUNT 2022_03_11:test 统计有多少不同的值

1. PFADD 2020_03_12:test uuid9 uuid10 uu11
2. PFMERGE 2022_03_11:test 2020_03_12:taibai 合并

注意：本质还是字符串，有容错率，官方数据时0.81%。

4、bitmaps

Bitmaps本身不是一种数据结构， 实际上它就是字符串， 但是它可以对字符串的位进行操作。

Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。
setbit test1 500000 0
getbit test1 500000
bitcount test1
Bitmap本质时string，是一串连续的2进制数字（0或1），每一位所在的位置为偏移（offset）。string（Bitmap）最大长度是512M，所以它们可以表示2^32=4294967296个不同的位。

缓存问题及解决方案

1、缓存粒度控制

通俗来讲，缓存粒度问题就是我们在使用缓存时，是将所有数据缓存还是缓存部分数据？

缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成网络带宽的浪费，可能会造成代码通用性较差等情况，必须学会综合数据通用性、空间占用比、代码维护性 三点评估取舍因素权衡使用。

2、缓存穿透问题

缓存穿透是指查询一个一定不存在的数据，由于缓存不命中，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次都要到存储层去查询，失去了缓存的意义。

可能造成原因：

1. 业务代码自身问题 2. 恶意攻击、爬虫等等。

危害：

对底层数据源压力过大，有些底层数据源不具备高并发性。例如MySQL一般来说单台能够抗1000-QPS就已经很不错了。

解决方案

1. 缓存空对象

public class NullValueResultDO implements Serializable{
	private static final long serialVersionUID = -6550539547145486005L;
}

public class UserMapper{
	UserDAO userDAO;
	LocalCache localCache;

	public UserDO getUser(String userNick){
		Object object = localCache.get(userNick);
		if(object != null){
			if(object instanceof NullValueResultDO){
				return null;
			}
			return (UserDO)object;
		}else{
			User user = userDAO.getUser(userNick);
			if(user != null){
				localCache.put(userNick,user);
			}else{
				localCache.put(userNick, new NullValueResultDO());
			}
			return user;
		}
	}
}

2. 布隆过滤器

3、缓存击穿.热点key重建缓存问题

缓存击穿是指缓存中没有单数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库中取数据，引起数据库压力瞬间增大，造成过大压力。

我们知道，使用缓存，如果获取不到，才会去数据库里获取。但是如果是热点key，访问量非常的大，数据库在重建缓存的时候，会出现很多线程同时重建的情况。因为高并发导致的大量热点key在重建还没完成的时候，不断被重建缓存的过程，由于大量线程都去做重建缓存工作，导致服务器拖慢的情况。

解决方案

1. 互斥锁

public String getKey(String key) {
	String value = redis.get(key);
	if(value == null) {
		// 设置互斥锁的key
		String mutexKey = "mutex:key" + key;
		// 给这个key上一把锁，ex表示只有一个线程能执行，过期时间为180秒
		if(redis.set(mutexKey,"1","ex 180","nx")) {
			value = db.get(key);
			redis.set(key,value);
			redis.delete(mutexKey);
		}else {
			// 其他线程休息100毫秒后重试
			Thread.sleep(100);
			getKey(key);
		}
	}
	return value;
}

互斥锁的优点是思路非常简单，具有一致性，但是互斥锁也有一定的问题，就是大量的线程在等待的问题。存在死锁的可能性。

4、缓存雪崩问题

缓存雪崩是指机器宕机或在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，数据库瞬时压力过重导致雪崩。

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

2：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

3：不同的key，设置不同的过期时间，让缓存实现的失效的时间点尽量均匀。

4：如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。

---