在分布式数据库中CAP原理CAP+BASE

CAP

C:Consistency（强一致性）

A:Availability（可用性）

P:Partition tolerance（分区容错性）

注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

经典CAP图

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
最多只能同时较好的满足两个。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

Base

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写：
基本可用（Basically Available）
软状态（Soft state）
最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

分布式+集群简介

分布式系统

分布式系统（distributed system）
由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。

简单来讲：
1分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。

2集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。

数据类型

数据类型	可以存储的值	操作
STRING	字符串、整数或者浮点数	对整个字符串或者字符串的其中一部分执行操作对整数和浮点数执行自增或者自减操作
LIST	列表	从两端压入或者弹出元素对单个或者多个元素进行修剪，只保留一个范围内的元素
SET	无序集合	添加、获取、移除单个元素，检查一个元素是否存在于集合中，计算交集、并集、差集，从集合里面随机获取元素
HASH	包含键值对的无序散列表	添加、获取、移除单个键值对，获取所有键值对，检查某个键是否存在
ZSET	有序集合	添加、获取、删除元素，根据分值范围或者成员来获取元素，计算一个键的排名

Redis字符串(String)

介绍：string 数据结构是简单的 key-value 类型。虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种 简单动态字符串（simple dynamic string，SDS）。相比于 C 的原生字符串，Redis 的 SDS 不光可以保存文本数据还可以保存二进制数据，并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)）,除此之外，Redis 的 SDS API 是安全的，不会造成缓冲区溢出。

常用命令： set,get,strlen,exists,decr,incr,setex 等等。

应用场景： 一般常用在需要计数的场景，比如用户的访问次数、热点文章的点赞转发数量等等。

常用

1585994656165

1585995177785

案例

# 普通字符串的基本操作：
# set/get/del/append/strlen
    
127.0.0.1:6379> set key value #设置 key-value 类型的值
OK
127.0.0.1:6379> get key # 根据 key 获得对应的 value
"value"
127.0.0.1:6379> exists key  # 判断某个 key 是否存在
(integer) 1
127.0.0.1:6379> strlen key # 返回 key 所储存的字符串值的长度。
(integer) 5
127.0.0.1:6379> del key # 删除某个 key 对应的值
(integer) 1
127.0.0.1:6379> get key
(nil)
# 批量设置 :
# mset/mget
127.0.0.1:6379> mset key1 value1 key2 value2 # 批量设置 key-value 类型的值
OK
127.0.0.1:6379> mset key3 value1 key4 value2 # 批量设置 key-value 类型的值，且仅当所有给定 key 都不存在。
OK
127.0.0.1:6379> mget key1 key2 # 批量获取多个 key 对应的 value
1) "value1"
2) "value2"

# 计数器（字符串的内容为整数的时候可以使用）：
# Incr/decr/incrby/decrby,一定要是数字才能进行加减
127.0.0.1:6379> set number 1
OK
127.0.0.1:6379> incr number # 将 key 中储存的数字值增一
(integer) 2
127.0.0.1:6379> get number
"2"
127.0.0.1:6379> decr number # 将 key 中储存的数字值减一
(integer) 1
127.0.0.1:6379> get number
"1"

# 获取设置指定区间范围内的值
# getrange/setrange
127.0.0.1:6379> set keyrange abcd1234
OK
127.0.0.1:6379> GETRANGE keyrange 0 -1 # 获取指定区间范围内的值，类似between......and的关系,从零到负一表示全部
"abcd1234"
127.0.0.1:6379> GETRANGE keyrange 0 2
"abc"
127.0.0.1:6379> get keyrange
"abcd1234"
127.0.0.1:6379> SETRANGE keyrange 1 xxx # 设置指定区间范围内的值，格式是setrange key值 具体值
(integer) 8
127.0.0.1:6379> get keyrange
"axxx1234"

# 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
# getset
127.0.0.1:6379> get lvxiaoyi
"lvxiaoyi"
127.0.0.1:6379> getset lvxiaoyi lvxiaoyi.top
"lvxiaoyi"
127.0.0.1:6379> get lvxiaoyi
"lvxiaoyi.top"

# 过期（默认为永不过期）：
# exprie/setex/ttl
127.0.0.1:6379> expire key  60 # 数据在 60s 后过期
(integer) 1
127.0.0.1:6379> setex key 60 value # 数据在 60s 后过期 (setex:[set] + [ex]pire)
OK
127.0.0.1:6379> ttl key # 查看数据还有多久过期
(integer) 56

Redis列表(List)

常用

1585995221265

1585995238254

案例

1	lpush/rpush/lrange

lpop/rpop

1585995337319

1	lindex，按照索引下标获得元素(从上到下)

通过索引获取列表中的元素 lindex key index

1585995391787

llen

1	lrem key 删N个value

从left往right删除2个值等于v1的元素，返回的值为实际删除的数量
LREM list3 0 值，表示删除全部给定的值。零个就是全部值

1585995452444

1	ltrim key 开始index 结束index，截取指定范围的值后再赋值给key

ltrim：截取指定索引区间的元素，格式是ltrim list的key 起始索引结束索引

1585995502196

1	rpoplpush 源列表目的列表

移除列表的最后一个元素，并将该元素添加到另一个列表并返回

1585995547020

1	lset key index value

1585995592111

1	linsert key before/after 值1 值2

在list某个已有值的前后再添加具体值

1585995639450

Redis集合(Set)

常用

1585995698562

案例

1	sadd/smembers/sismember

1585995735994

1	scard，获取集合里面的元素个数

获取集合里面的元素个数

1585995770747

1	srem key value 删除集合中元素

1585995810071

1	srandmember key 某个整数(随机出几个数)

从set集合里面随机取出2个
如果超过最大数量就全部取出，
如果写的值是负数，比如-3 ，表示需要取出3个，但是可能会有重复值。

1585995855484

1	spop key 随机出栈

1585995884347

1	smove key1 key2 在key1里某个值作用是将key1里的某个值赋给key2

1585995923634

数学集合类

差集：sdiff

在第一个set里面而不在后面任何一个set里面的项

1585995977625

交集：sinter

1585996002650

并集：sunion

1585996028469

Redis哈希(Hash)

常用

1585996081715

案例

1	hset/hget/hmset/hmget/hgetall/hdel

1585996133004

1585996155149

hlen

1	hexists key 在key里面的某个值的key

1	hkeys/hvals

1585996199153

1	hincrby/hincrbyfloat

1585996228252

hsetnx

不存在赋值，存在了无效

1585996274616

Redis有序集合Zset(sorted set)

常用

1585996334841

1585996352814

案例

1	zadd/zrange

1585996398591

1	zrangebyscore key 开始score 结束score

1585996426257

1585996444249

1	zrem key 某score下对应的value值，作用是删除元素

删除元素，格式是zrem zset的key 项的值，项的值可以是多个zrem key score某个对应值，可以是多个值

1585996502891

1	zcard/zcount key score区间/zrank key values值，作用是获得下标值/zscore key 对应值,获得分数

zcard ：获取集合中元素个数

1585996544615

zcount ：获取分数区间内元素个数，zcount key 开始分数区间结束分数区间

1585996570867

zrank：获取value在zset中的下标位置

1585996602676

zscore：按照值获得对应的分数

1585996632251

1	zrevrank key values值，作用是逆序获得下标值

正序、逆序获得下标索引值

1585996676600

zrevrange

1585996705998

1	zrevrangebyscore key 结束score 开始score

zrevrangebyscore zset1 90 60 withscores 分数是反着来的

1585996748507

三种特殊数据类型

geospatial

Redis 在 3.2 推出 Geo 类型，该功能可以推算出地理位置信息，两地之间的距离。

文档： https://www.redis.net.cn/order/3687.html

借助网站模拟一些数据： http://www.jsons.cn/lngcode/

geoadd 添加地理位置

规则：两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。

有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。当坐标位置超出指定范围时，该命令将会返回一个错误。

1	(error) ERR invalid longitude latitude pair xxx yyy

添加一些模拟数据：

127.0.0.1:6379> geoadd china:city 116.40 39.90 beijing
(integer) 1
127.0.0.1:6379> geoadd china:city 121.47 31.23 shanghai
(integer) 1
127.0.0.1:6379> geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shengzhen
(integer) 2
127.0.0.1:6379> geoadd china:city 120.16 30.24 hangzhou 108.96 34.26 xian
(integer) 2
127.0.0.1:6379>

geopos 获得当前定位坐标值

127.0.0.1:6379> geopos china:city beijing		# 获得指定城市的经纬度
1) 1) "116.39999896287918091"
   2) "39.90000009167092543"
127.0.0.1:6379> geopos china:city shanghai
1) 1) "121.47000163793563843"
   2) "31.22999903975783553"
127.0.0.1:6379>

geodist 获取两个位置之间的距离

单位：

m 表示单位为米。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。

如果用户没有显式地指定单位参数，那么 GEODIST 默认使用米作为单位。

127.0.0.1:6379> geodist china:city beijing shanghai km	# 查看北京和上海直接的直线距离
"1067.3788"
127.0.0.1:6379> geodist china:city beijing chongqing km
"1464.0708"
127.0.0.1:6379>

georedius 以给定的经纬度为中心，找出某一半径内的元素

127.0.0.1:6379> georadius china:city 110 30 1000 km # 以110, 30 这个点为中心，寻找方圆 1000km 的城市
1) "chongqing"
2) "xian"
3) "shengzhen"
4) "hangzhou"
127.0.0.1:6379> georadius china:city 110 30 500 km 
1) "chongqing"
2) "xian"
127.0.0.1:6379> georadius china:city 110 30 500 km withcoord	#  显示他人的定位信息
1) 1) "chongqing"
   2) 1) "106.49999767541885376"
      2) "29.52999957900659211"
2) 1) "xian"
   2) 1) "108.96000176668167114"
      2) "34.25999964418929977"
127.0.0.1:6379> 
127.0.0.1:6379> georadius china:city 110 30 500 km withdist #  显示到中心点的距离
1) 1) "chongqing"
   2) "341.9374"
2) 1) "xian"
   2) "483.8340"
127.0.0.1:6379> georadius china:city 110 30 500 km withdist withcoord count 1  # 指定数量
1) 1) "chongqing"
   2) "341.9374"
   3) 1) "106.49999767541885376"
      2) "29.52999957900659211"
127.0.0.1:6379> georadius china:city 110 30 500 km withdist withcoord count 2
1) 1) "chongqing"
   2) "341.9374"
   3) 1) "106.49999767541885376"
      2) "29.52999957900659211"
2) 1) "xian"
   2) "483.8340"
   3) 1) "108.96000176668167114"
      2) "34.25999964418929977"
127.0.0.1:6379>

GEORADIUSBYMEMBER 找出位于指定元素周围的其他元素

127.0.0.1:6379> georadiusbymember china:city shanghai 1000 km
1) "hangzhou"
2) "shanghai"
127.0.0.1:6379>

geo 底层实现原理其实就是 zset ，可以使用 zset 命令操作 geo

127.0.0.1:6379> zrange china:city 0 -1
1) "chongqing"
2) "xian"
3) "shengzhen"
4) "hangzhou"
5) "shanghai"
6) "beijing"
127.0.0.1:6379> zrem china:city beijing		# 删除一个元素
(integer) 1
127.0.0.1:6379> zrange china:city 0 -1
1) "chongqing"
2) "xian"
3) "shengzhen"
4) "hangzhou"
5) "shanghai"
127.0.0.1:6379>

hyperloglog

基数：数学上集合的元素个数，是不能重复的。

UV（Unique visitor）：是指通过互联网访问、浏览这个网页的自然人。访问的一个电脑客户端为一个访客，一天内同一个访客仅被计算一次。

Redis 2.8.9 版本更新了 hyperloglog 数据结构，是基于基数统计的算法。

hyperloglog 的优点是占用内存小，并且是固定的。存储 2^64 个不同元素的基数，只需要 12 KB 的空间。但是也可能有 0.81% 的错误率。

这个数据结构常用于统计网站的 UV。传统的方式是使用 set 保存用户的ID，然后统计 set 中元素的数量作为判断标准。但是这种方式保存了大量的用户 ID，ID 一般比较长，占空间，还很麻烦。我们的目的是计数，不是保存数据，所以这样做有弊端。但是如果使用 hyperloglog 就比较合适了。

127.0.0.1:6379> pfadd mykey a b c d e f g h i j	# 创建第一组元素
(integer) 1
127.0.0.1:6379> PFCOUNT mykey					# 统计 mykey 基数
(integer) 10
127.0.0.1:6379> PFADD mykey2 i j z x c v b n m  # 创建第二组元素
(integer) 1
127.0.0.1:6379> PFCOUNT mykey2					# 统计 mykey2 基数
(integer) 9
127.0.0.1:6379> PFMERGE mykey3 mykey mykey2		# 合并两组 mykey mykey2 => mykey3
OK
127.0.0.1:6379> PFCOUNT mykey3
(integer) 15
127.0.0.1:6379>

bitmap 位图

bitmap就是通过最小的单位bit来进行0或者1的设置，表示某个元素对应的值或者状态。一个bit的值，或者是0，或者是1；也就是说一个bit能存储的最多信息是2。

bitmap 常用于统计用户信息比如活跃粉丝和不活跃粉丝、登录和未登录、是否打卡等。

这里使用一周打卡的案例说明其用法：

127.0.0.1:6379> setbit sign 0 1		# 周一打卡了
(integer) 0
127.0.0.1:6379> setbit sign 1 0		# 周二未打卡
(integer) 0
127.0.0.1:6379> setbit sign 2 0		# 周三未打卡
(integer) 0
127.0.0.1:6379> setbit sign 3 1
(integer) 0
127.0.0.1:6379> setbit sign 4 1
(integer) 0
127.0.0.1:6379> setbit sign 5 1
(integer) 0
127.0.0.1:6379> setbit sign 6 0
(integer) 0
127.0.0.1:6379>

查看某一天是否打卡：

127.0.0.1:6379> GETBIT sign 3
(integer) 1
127.0.0.1:6379> GETBIT sign 6
(integer) 0
127.0.0.1:6379>

统计：统计打卡的天数

1
2
3

127.0.0.1:6379> BITCOUNT sign
(integer) 4
127.0.0.1:6379>

谈下你对 Redis 的了解？

简单来说 Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的 ，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。

另外，Redis 除了做缓存之外，也经常用来做分布式锁，甚至是消息队列。

Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务、持久化、Lua 脚本、多种集群方案。

说一下 Redis 和 Memcached 的区别和共同点

现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！不过，了解 Redis 和 Memcached 的区别和共同点，有助于我们在做相应的技术选型的时候，能够做到有理有据！

共同点 ：

都是基于内存的数据库，一般都用来当做缓存使用。
都有过期策略。
两者的性能都非常高。

区别：

Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。
Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而 Memecache 把数据全部存在内存之中。
Redis 有灾难恢复机制。 因为可以把缓存中的数据持久化到磁盘上。
Redis 在服务器内存使用完之后，可以将不用的数据放到磁盘上。但是，Memcached 在服务器内存使用完之后，就会直接报异常。
Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 目前是原生支持 cluster 模式的。
Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。 （Redis 6.0 引入了多线程 IO ）
Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。
Memcached 过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。

相信看了上面的对比之后，我们已经没有什么理由可以选择使用 Memcached 来作为自己项目的分布式缓存了。

缓存数据的处理流程

如果⽤户请求的数据在缓存中就直接返回。
缓存中不存在的话就看数据库中是否存在。
数据库中存在的话就更新缓存中的数据。
数据库中不存在的话就返回空数据。

为什么要⽤ Redis/为什么要⽤缓存

高性能 ：

我们设想这样的场景：

假如用户第一次访问数据库中的某些数据的话，这个过程是比较慢，毕竟是从硬盘中读取的。但是，如果说，用户访问的数据属于高频数据并且不会经常改变的话，那么我们就可以很放心地将该用户访问的数据存在缓存中。

这样有什么好处呢？ 那就是保证用户下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。

不过，要保持数据库和缓存中的数据的一致性。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：

一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g），但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。

QPS（Query Per Second）：服务器每秒可以执行的查询次数；

由此可见，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高了系统整体的并发。

Redis 一般都有哪些使用场景？

Redis 适合的场景

缓存：减轻 MySQL 的查询压力，提升系统性能；

分布式锁 ：通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下，我们都是基于 Redisson 来实现分布式锁。相关阅读：《分布式锁中的王者方案 - Redisson》。

限流：一般是通过 Redis + Lua 脚本的方式来实现限流。相关阅读：[《我司用了 6 年的 Redis 分布式限流器，可以说是非常厉害了！》。

消息队列 ：Redis 自带的 list 数据结构可以作为一个简单的队列使用。Redis5.0 中增加的 Stream 类型的数据结构更加适合用来做消息队列。它比较类似于 Kafka，有主题和消费组的概念，支持消息持久化以及 ACK 机制。

复杂业务场景 ：通过 Redis 以及 Redis 扩展（比如 Redisson）提供的数据结构，我们可以很方便地完成很多复杂的业务场景比如通过 bitmap 统计活跃用户、通过 sorted set 维护排行榜。

排行榜：利用 Redis 的 SortSet （有序集合）实现；
计算器/限速器：利用 Redis 中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等。这类操作如果用 MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个 API 的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；
好友关系：利用集合的一些命令，比如求交集、并集、差集等。可以方便解决一些共同好友、共同爱好之类的功能；
Session 共享：Session 是保存在服务器的文件中，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用 Redis 保存 Session 后，无论用户落在那台机器上都能够获取到对应的 Session 信息。

Redis 不适合的场景

数据量太大、数据访问频率非常低的业务都不适合使用 Redis，数据太大会增加成本，访问频率太低，保存在内存中纯属浪费资源。

Redis 为什么是单线程的？

官方 FAQ 表示，因为 Redis 是基于内存的操作（不需要磁盘io的等待），CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽（等待网络数据）。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了，毕竟采用多线程会有很多麻烦。

在单核cpu的情况下：

https://www.cnblogs.com/aspirant/p/11704530.html

正常的操作单线程是快于多线程的。因为有线程上下文的切换，而线程上下文的切换的时间是能够大约执行5000多条指令。

那么多线程适用于什么场景呢，适用于有io的场景，因为io操作，这个使用主要在等待磁盘的寻址，这个时候cpu就属于空闲的状态下不能充分的利用cpu的资源，所以我们可以使用多线程充分利用cpu的资源。

Redis 为什么这么快？

1.完全基于内存，绝大部分请求是纯粹的内存操作，非常快速；

2.数据结构简单，对数据操作也简单；

3.采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4.使用多路 I/O 复用模型，非阻塞 IO。

什么是缓存穿透？怎么解决？

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

解决办法

1.缓存空对象：如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存空对象带来的问题：

1
2
3

1.空值做了缓存，意味着缓存中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

2.缓存和存储的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如:过期时间设置为 5分钟，如果此时存储添加了这个数据，那此段时间就会出现缓存和存储数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2.布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

什么是缓存雪崩？该如何解决？

如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。

解决办法

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

2.数据预热：可以通过缓存 reload 机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀；

3.做二级缓存，或者双缓存策略：Cache1 为原始缓存，Cache2 为拷贝缓存，Cache1 失效时，可以访问 Cache2，Cache1 缓存失效时间设置为短期，Cache2 设置为长期。

4.在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。

缓存穿透，缓存击穿，缓存雪崩解决方案分析

前言
设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。

缓存穿透
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案
有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

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

解决方案
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案
1.使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。在redis2.6.1之前版本未实现setnx的过期时间，所以这里给出两种版本代码参考：

//2.6.1前单机版本锁

String get(String key) {  
   String value = redis.get(key);  
   if (value  == null) {  
    if (redis.setnx(key_mutex, "1")) {  
        // 3 min timeout to avoid mutex holder crash  
        redis.expire(key_mutex, 3 * 60)  
        value = db.get(key);  
        redis.set(key, value);  
        redis.delete(key_mutex);  
    } else {  
        //其他线程休息50毫秒后重试  
        Thread.sleep(50);  
        get(key);  
    }  
  }  
}

怎么保证缓存和数据库数据的一致性？

如题，现在很多架构都采用了Redis+MySQL来进行存储，但是由于多方面的原因，总会导致Redis和MySQL之间出现数据的不一致性.

例如如果一个事务执行失败回滚了，但是如果采取了先写Redis的方式，就会造成Redis和MySQL数据库的不一致，再比如说，一个事务写入了MySQL，但是此时还未写入Redis，如果这时候有用户访问Redis，则此时就会出现数据不一致。

为了解决这些问题，本文将着重讨论，如何保证MySQL和Redis之间存在一个合理的数据一致性方案。

1.分别处理

针对某些对数据一致性要求不是特别高的情况下，可以将这些数据放入Redis，请求来了直接查询Redis，例如近期回复、历史排名这种实时性不强的业务。而针对那些强实时性的业务，例如虚拟货币、物品购买件数等等，
则直接穿透Redis至MySQL上，等到MySQL上写入成功，再同步更新到Redis上去。这样既可以起到Redis的分流大量查询请求的作用，又保证了关键数据的一致性。

2.高并发情况下

此时如果写入请求较多，则直接写入Redis中去，然后间隔一段时间，批量将所有的写入请求，刷新到MySQL中去；如果此时写入请求不多，则可以在每次写入Redis，都立刻将该命令同步至MySQL中去。这两种方法有利有弊，需要根据不同的场景来权衡.

3.基于订阅binlog的同步机制

阿里巴巴的一款开源框架canal，提供了一种发布/ 订阅模式的同步机制，通过该框架我们可以对MySQL的binlog进行订阅，这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，
Redis再根据binlog中的记录，对Redis进行更新。值得注意的是，binlog需要手动打开，并且不会记录关于MySQL查询的命令和操作。
其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。
而canal正是模仿了slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。
如下图就可以看到Slave数据库中启动了2个线程，一个是MySQL SQL线程，这个线程跟Matser数据库中起的线程是一样的，
负责MySQL的业务率执行，而另外一个线程就是MySQL的I/O线程，这个线程的主要作用就是同步Master 数据库中的binlog，达到数据备份的效果。而binlog就可以理解为一堆SQL语言组成的日志。

Redis 持久化有几种方式？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。Redis 提供了两种持久化方式：RDB（默认）和 AOF。

RDB

RDB 是 Redis DataBase 的缩写。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即 Snapshot 快照存储，对应产生的数据文件为 dump.rdb，通过配置文件中的 save 参数来定义快照的周期。核心函数：rdbSave（生成 RDB 文件）和 rdbLoad（从文件加载内存）两个函数。

AOF

AOF 是 Append-only file 的缩写。Redis会将每一个收到的写命令都通过 Write 函数追加到文件最后，类似于 MySQL 的 binlog。当 Redis 重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。每当执行服务器（定时）任务或者函数时，flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作：

WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件；

SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

RDB 和 AOF 的区别：

1	1.AOF 文件比 RDB 更新频率高，优先使用 AOF 还原数据；2.AOF比 RDB 更安全也更大；3.RDB 性能比 AOF 好；4.如果两个都配了优先加载 AOF。

Redis 怎么实现分布式锁？

Redis 为单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对 Redis 的连接并不存在竞争关系。Redis 中可以使用 SETNX 命令实现分布式锁。一般使用 setnx(set if not exists) 指令，只允许被一个程序占有，使用完调用 del 释放锁。

Redis 淘汰策略有哪些？

volatile-lru：从已设置过期时间的数据集（server. db[i]. expires）中挑选最近最少使用的数据淘汰；
volatile-random：从已设置过期时间的数据集（server. db[i]. expires）中任意选择数据淘汰。
allkeys-lru：从数据集（server. db[i]. dict）中挑选最近最少使用的数据淘汰。
allkeys-random：从数据集（server. db[i]. dict）中任意选择数据淘汰。
volatile-ttl：从已设置过期时间的数据集（server. db[i]. expires）中挑选将要过期的数据淘汰。
no-enviction（驱逐）：禁止驱逐数据。

Redis的原子性如何保证

对于Redis而言，命令的原子性指的是：一个操作不可再分，操作要么执行要么不执行，Redis之所以是原子的，是因为Redis是单线程的。

Redis所有单个命令的执行都是原子的，Redis是实现事务的原理：

1.批量操作在发送EXEC（执行）命令前被放入队列缓存；

2.收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令都不会被执行；

3.在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

Redis 有哪些架构模式讲讲各自的特点

单机版

特点：简单

问题：

1、内存容量有限 2、处理能力有限 3、无法高可用。

主从复制

Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步给从服务器，从而一直保证主从服务器的数据相同。

特点：

1、master/slave 角色

2、master/slave 数据相同

3、降低 master 读压力在转交从库

问题：

无法保证高可用

没有解决 master 写的压力

哨兵

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点：

1、保证高可用

2、监控各个节点

3、自动故障迁移

缺点：主从模式，切换需要时间丢数据

没有解决 master 写的压力

集群（proxy 型）

Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

特点：1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins

2、支持失败节点自动删除

3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

缺点：增加了新的 proxy，需要维护其高可用。

failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

集群（直连型）

从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

特点：

1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。

2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。

4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本

5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。

缺点：

1、资源隔离性较差，容易出现相互影响的情况。

2、数据通过异步复制,不保证数据的强一致性

使用过Redis做异步队列么，你是怎么用的？有什么缺点？

一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

缺点：

在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

能不能生产一次消费多次呢？

使用pub/sub主题订阅者模式，可以实现1:N的消息队列。

进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

案例

先订阅后发布后才能收到消息，

1 可以一次性订阅多个，SUBSCRIBE c1 c2 c3

2 消息发布，PUBLISH c2 hello-redis

3 订阅多个，通配符， PSUBSCRIBE new

4 收取消息， PUBLISH new1 redis2015

Redis如何存储复杂的数据？

复杂数据存储

一般的数据存储，就是一个key对应一个简单字符串，可以要想向mysql一样，保存或者获取某一列的所有值呢，
例如,用户表结构为

id	name	age
1	张三	19
2	李四	23

这种情况一般可以利用json存储或者是hash

json存储

redis 127.0.0.1:6379> set charmtest:user:1 '{"name":"张三","age":"19"}'OKredis 127.0.0.1:6379> set charmtest:user:2 '{"name":"李四","age":"23"}'OKredis 127.0.0.1:6379> get charmtest:user:1"{"name":"张三","age":"19"}"redis 127.0.0.1:6379> get charmtest:user:2"{"name":"李四","age":"23"}"

hash存储

1	redis 127.0.0.1:6379:0>hset 'charmhash:user:1' name '张三'"1"redis 127.0.0.1:6379:0>hset 'charmhash:user:1' age 19"1"

获取数据

1	redis 127.0.0.1:6379:0>hget 'charmhash:user:1' name"张三"redis 127.0.0.1:6379:0>hget 'charmhash:user:1' age"19"

Redis的过期策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。

过期策略通常有以下三种

定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

Redis底层数据结构

1.简单动态字符串

　　第一篇文章我们就说过 Redis 是用 C 语言写的，但是对于Redis的字符串，却不是 C 语言中的字符串（即以空字符’\0’结尾的字符数组），它是自己构建了一种名为简单动态字符串（simple dynamic string,SDS）的抽象类型，并将 SDS 作为 Redis的默认字符串表示。

SDS 定义：

struct sdshdr{   //记录buf数组中已使用字节的数量   //等于 SDS 保存字符串的长度   int len;   //记录 buf 数组中未使用字节的数量   int free;   //字节数组，用于保存字符串   char buf[];}

　　用SDS保存字符串 “Redis”具体图示如下：

　　　　　　　　　图片来源：《Redis设计与实现》

　我们看上面对于 SDS 数据类型的定义：

　　1、len 保存了SDS保存字符串的长度

　　2、buf[] 数组用来保存字符串的每个元素

　　3、free j记录了 buf 数组中未使用的字节数量

　　上面的定义相对于 C 语言对于字符串的定义，多出了 len 属性以及 free 属性。为什么不使用C语言字符串实现，而是使用 SDS呢？这样实现有什么好处？

①、常数复杂度获取字符串长度

　　由于 len 属性的存在，我们获取 SDS 字符串的长度只需要读取 len 属性，时间复杂度为 O(1)。而对于 C 语言，获取字符串的长度通常是经过遍历计数来实现的，时间复杂度为 O(n)。通过 strlen key 命令可以获取 key 的字符串长度。

②、杜绝缓冲区溢出

　　我们知道在 C 语言中使用 strcat 函数来进行两个字符串的拼接，一旦没有分配足够长度的内存空间，就会造成缓冲区溢出。而对于 SDS 数据类型，在进行字符修改的时候，会首先根据记录的 len 属性检查内存空间是否满足需求，如果不满足，会进行相应的空间扩展，然后在进行修改操作，所以不会出现缓冲区溢出。

③、减少修改字符串的内存重新分配次数

　　C语言由于不记录字符串的长度，所以如果要修改字符串，必须要重新分配内存（先释放再申请），因为如果没有重新分配，字符串长度增大时会造成内存缓冲区溢出，字符串长度减小时会造成内存泄露。

　　而对于SDS，由于len属性和free属性的存在，对于修改字符串SDS实现了空间预分配和惰性空间释放两种策略：

　　1、空间预分配：对字符串进行空间扩展的时候，扩展的内存比实际需要的多，这样可以减少连续执行字符串增长操作所需的内存重分配次数。

　　2、惰性空间释放：对字符串进行缩短操作时，程序不立即使用内存重新分配来回收缩短后多余的字节，而是使用 free 属性将这些字节的数量记录下来，等待后续使用。（当然SDS也提供了相应的API，当我们有需要时，也可以手动释放这些未使用的空间。）

④、二进制安全

　　因为C字符串以空字符作为字符串结束的标识，而对于一些二进制文件（如图片等），内容可能包括空字符串，因此C字符串无法正确存取；而所有 SDS 的API 都是以处理二进制的方式来处理 buf 里面的元素，并且 SDS 不是以空字符串来判断是否结束，而是以 len 属性表示的长度来判断字符串是否结束。

⑤、兼容部分 C 字符串函数

　　虽然 SDS 是二进制安全的，但是一样遵从每个字符串都是以空字符串结尾的惯例，这样可以重用 C 语言库<string.h> 中的一部分函数。

⑥、总结

一般来说，SDS 除了保存数据库中的字符串值以外，SDS 还可以作为缓冲区（buffer）：包括 AOF 模块中的AOF缓冲区以及客户端状态中的输入缓冲区。后面在介绍Redis的持久化时会进行介绍。

2.链表

　　链表是一种常用的数据结构，C 语言内部是没有内置这种数据结构的实现，所以Redis自己构建了链表的实现。

链表定义：

　　通过多个 listNode 结构就可以组成链表，这是一个双端链表，Redis还提供了操作链表的数据结构：

typedef struct listNode{    
    //前置节点    
    struct listNode *prev;    
    //后置节点    
    struct listNode *next;    
    //节点的值    
    void *value; 
}listNode

typedef struct list{   
    //表头节点   
    listNode *head;   
    //表尾节点   
    listNode *tail;   
    //链表所包含的节点数量   
    unsigned  long len;   
    //节点值复制函数   
    void (free) (void *ptr);   
    //节点值释放函数   
    void (free) (void *ptr);   
    //节点值对比函数   
    int (*match) (void *ptr,void *key);
}list;

　　Redis链表特性：

　　①、双端：链表具有前置节点和后置节点的引用，获取这两个节点时间复杂度都为O(1)。

　　②、无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问都是以 NULL 结束。　　

　　③、带链表长度计数器：通过 len 属性获取链表长度的时间复杂度为 O(1)。

　　④、多态：链表节点使用 void* 指针来保存节点值，可以保存各种不同类型的值。

3.字典

　　字典又称为符号表或者关联数组、或映射（map），是一种用于保存键值对的抽象数据结构。字典中的每一个键 key 都是唯一的，通过 key 可以对值来进行查找或修改。C 语言中没有内置这种数据结构的实现，所以字典依然是 Redis自己构建的。

　　哈希表结构定义：

typedef struct dictht{   
    //哈希表数组   
    **table;   
    //哈希表大小   
    unsigned long size;   
    //哈希表大小掩码，用于计算索引值   
    //总是等于 size-1  
    unsigned long sizemask;   
    //该哈希表已有节点的数量   
    unsigned long used; 
}dictht

　　哈希表是由数组 table 组成，table 中每个元素都是指向 dict.h/dictEntry 结构，dictEntry 结构定义如下：

typedef struct dictEntry{   
    //键   
    void *key;   
    //值   
    union{     
        void *val;     
        uint64_tu64;     
        int64_ts64;   
    }v;   
    //指向下一个哈希表节点，形成链表  
    struct dictEntry *next;
}dictEntry

　　key 用来保存键，val 属性用来保存值，值可以是一个指针，也可以是uint64_t整数，也可以是int64_t整数。

　　注意这里还有一个指向下一个哈希表节点的指针，我们知道哈希表最大的问题是存在哈希冲突，如何解决哈希冲突，有开放地址法和链地址法。这里采用的便是链地址法，通过next这个指针可以将多个哈希值相同的键值对连接在一起，用来解决****哈希冲突****。

　　①、哈希算法：Redis计算哈希值和索引值方法如下：

#1、使用字典设置的哈希函数，计算键 key 的哈希值hash = dict->type->hashFunction(key);#2、使用哈希表的sizemask属性和第一步得到的哈希值，计算索引值index = hash & dict->ht[x].sizemask;

　②、解决哈希冲突：这个问题上面我们介绍了，方法是链地址法。通过字典里面的 *next 指针指向下一个具有相同索引值的哈希表节点。

　③、扩容和收缩：当哈希表保存的键值对太多或者太少时，就要通过 rerehash(重新散列）来对哈希表进行相应的扩展或者收缩。具体步骤：

　　　　　　1、如果执行扩展操作，会基于原哈希表创建一个大小等于 ht[0].used*2n 的哈希表（也就是每次扩展都是根据原哈希表已使用的空间扩大一倍创建另一个哈希表）。相反如果执行的是收缩操作，每次收缩是根据已使用空间缩小一倍创建一个新的哈希表。

　　　　　　2、重新利用上面的哈希算法，计算索引值，然后将键值对放到新的哈希表位置上。

　　　　　　3、所有键值对都迁徙完毕后，释放原哈希表的内存空间。

　④、触发扩容的条件：

　　　　　　1、服务器目前没有执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于1。

　　　　　　2、服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于5。

　　　　ps：负载因子 = 哈希表已保存节点数量 / 哈希表大小。

⑤、渐近式 rehash

　　　　什么叫渐进式 rehash？也就是说扩容和收缩操作不是一次性、集中式完成的，而是分多次、渐进式完成的。如果保存在Redis中的键值对只有几个几十个，那么 rehash 操作可以瞬间完成，但是如果键值对有几百万，几千万甚至几亿，那么要一次性的进行 rehash，势必会造成Redis一段时间内不能进行别的操作。所以Redis采用渐进式 rehash,这样在进行渐进式rehash期间，字典的删除查找更新等操作可能会在两个哈希表上进行，第一个哈希表没有找到，就会去第二个哈希表上进行查找。但是进行增加操作，一定是在新的哈希表上进行的。

4.跳跃表

　　跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其它节点的指针，从而达到快速访问节点的目的。具有如下性质：

　　1、由很多层结构组成；

　　2、每一层都是一个有序的链表，排列顺序为由高层到底层，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点；

　　3、最底层的链表包含了所有的元素；

　　4、如果一个元素出现在某一层的链表中，那么在该层之下的链表也全都会出现（上一层的元素是当前层的元素的子集）；

　　5、链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的同一个链表节点；

　　Redis中跳跃表节点定义如下：

typedef struct zskiplistNode {   
    //层   
    struct zskiplistLevel{     
        //前进指针      
        struct zskiplistNode *forward;      
        //跨度      
        unsigned ***\*int\**** span;   
    }level[];    
    //后退指针   
    struct zskiplistNode *backward;   
    //分值   double score;   
    //成员对象   
    robj *obj; 
} zskiplistNode

　　多个跳跃表节点构成一个跳跃表：

typedef struct zskiplist{   
    //表头节点和表尾节点   
    structz skiplistNode *header, *tail;   
    //表中节点的数量   
    unsigned long length;   
    //表中层数最大的节点的层数   
    int level; 
}zskiplist;

　　①、搜索：从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找，也就是和当前层的下一层的节点的下一个节点进行比较，以此类推，一直找到最底层的最后一个节点，如果找到则返回，反之则返回空。

　　②、插入：首先确定插入的层数，有一种方法是假设抛一枚硬币，如果是正面就累加，直到遇见反面为止，最后记录正面的次数作为插入的层数。当确定插入的层数k后，则需要将新元素插入到从底层到k层。

③、删除：在各个层中找到

包含指定值的节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。

5.整数集合

　　整数集合（intset）是Redis用于保存整数值的集合抽象数据类型，它可以保存类型为int16_t、int32_t 或者int64_t 的整数值，并且保证集合中不会出现重复元素。

typedef struct intset{   
    //编码方式   
    uint32_t encoding;   
    //集合包含的元素数量   
    uint32_t length;   
    //保存元素的数组   
    int8_t contents[]; 
}intset;

　　定义如下：

　　整数集合的每个元素都是 contents 数组的一个数据项，它们按照从小到大的顺序排列，并且不包含任何重复项。

　　length 属性记录了 contents 数组的大小。

　　需要注意的是虽然 contents 数组声明为 int8_t 类型，但是实际上contents 数组并不保存任何 int8_t 类型的值，其真正类型有 encoding 来决定。

　①、升级

　　当我们新增的元素类型比原集合元素类型的长度要大时，需要对整数集合进行升级，才能将新元素放入整数集合中。具体步骤：

　　1、根据新元素类型，扩展整数集合底层数组的大小，并为新元素分配空间。

　　2、将底层数组现有的所有元素都转成与新元素相同类型的元素，并将转换后的元素放到正确的位置，放置过程中，维持整个元素顺序都是有序的。

　　3、将新元素添加到整数集合中（保证有序）。

　　升级能极大地节省内存。

②、降级

　　整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态。

6.压缩列表

　　压缩列表（ziplist）是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。

压缩列表的原理：压缩列表并不是对数据利用某种算法进行压缩，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。

　　压缩列表的每个节点构成如下：

　　①、previous_entry_ength：记录压缩列表前一个字节的长度。previous_entry_ength的长度可能是1个字节或者是5个字节，如果上一个节点的长度小于254，则该节点只需要一个字节就可以表示前一个节点的长度了，如果前一个节点的长度大于等于254，则previous length的第一个字节为254，后面用四个字节表示当前节点前一个节点的长度。利用此原理即当前节点位置减去上一个节点的长度即得到上一个节点的起始位置，压缩列表可以从尾部向头部遍历。这么做很有效地减少了内存的浪费。

　　②、encoding：节点的encoding保存的是节点的content的内容类型以及长度，encoding类型一共有两种，一种字节数组一种是整数，encoding区域长度为1字节、2字节或者5字节长。

　　③、content：content区域用于保存节点的内容，节点内容类型和长度由encoding决定。

7.总结

　　大多数情况下，Redis使用简单字符串SDS作为字符串的表示，相对于C语言字符串，SDS具有常数复杂度获取字符串长度，杜绝了缓存区的溢出，减少了修改字符串长度时所需的内存重分配次数，以及二进制安全能存储各种类型的文件，并且还兼容部分C函数。

　　通过为链表设置不同类型的特定函数，Redis链表可以保存各种不同类型的值，除了用作列表键，还在发布与订阅、慢查询、监视器等方面发挥作用（后面会介绍）。

　　Redis的字典底层使用哈希表实现，每个字典通常有两个哈希表，一个平时使用，另一个用于rehash时使用，使用链地址法解决哈希冲突。

　　跳跃表通常是有序集合的底层实现之一，表中的节点按照分值大小进行排序。

　　整数集合是集合键的底层实现之一，底层由数组构成，升级特性能尽可能的节省内存。

　　压缩列表是Redis为节省内存而开发的顺序型数据结构，通常作为列表键和哈希键的底层实现之一。

高并发的系统如何保证幂等性

一、什么是幂等性

幂等概念来自数学，表示N次变换和1次变换的结果是相同的。这里讨论在某些场景下，客户端在调用服务没有达到预期结果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。

HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

这里需要关注几个重点：

幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
网络超时等问题，不是幂等的讨论范围。

幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。

二、什么情况下需要幂等

业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况。

在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：

用户在APP上连续点击了多次提交订单，后台应该只产生一个订单；
向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。
很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生多次改变，将服务设计成幂等。

三、幂等VS防重

重复提交的情况，和服务幂等的初衷是不同的。重复提交是在第一次请求已经成功的情况下，人为的进行多次操作，导致不满足幂等要求的服务多次改变状态。而幂等更多使用的情况是第一次请求不知道结果（比如超时）或者失败的异常情况下，发起多次请求，目的是多次确认第一次请求成功，却不会因多次请求而出现多次的状态变化。

四、什么情况下需要保证幂等性

以SQL为例，有下面三种场景，只有第三种场景需要开发人员使用其他策略保证幂等性：

SELECT col1 FROM tab1 WHER col2=2，无论执行多少次都不会改变状态，是天然的幂等。
UPDATE tab1 SET col1=1 WHERE col2=2，无论执行成功多少次状态都是一致的，因此也是幂等操作。
UPDATE tab1 SET col1=col1+1 WHERE col2=2，每次执行的结果都会发生变化，这种不是幂等的。

五、为什么要设计幂等性服务

幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价。满足幂等服务的需要在逻辑中至少包含两点：

首先去查询上一次的执行状态，如果没有则认为是第一次请求
在服务改变状态的业务逻辑前，保证防重复提交的逻辑

六、幂等的不足

幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，是否有必要，需要根据具体场景具体分析，因此除了业务上的特殊要求外，尽量不提供幂等的接口。

增加了额外控制幂等的业务逻辑，复杂化了业务功能；
把并行执行的功能改为串行执行，降低了执行效率。

七、保证幂等策略

幂等需要通过唯一的业务单号来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。

下面以支付为例，在不考虑并发的情况下，实现幂等很简单：①先查询一下订单是否已经支付过，②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

八、防重复提交策略

上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单：把查询和变更状态操作加锁，将并行操作改为串行操作。

1、乐观锁

如果只是更新已有的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。例如：
UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version#

不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。（从网上找了一张图片很能说明乐观锁，引用过来，出自Mybatis对乐观锁的支持）

2、防重表

使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。可以看出防重表作用是加锁的功能。

防重复提交流程

3、分布式锁

这里使用的防重表可以使用分布式锁代替，比如Redis。订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。相比去重表，将放并发做到了缓存中，较为高效。思路相同，同一时间只能完成一次支付请求。

分布式锁

4、token令牌

这种方式分成两个阶段：申请token阶段和支付阶段。

第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。

第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。

实际上这里的token是一个信物，支付系统根据token确认，你是你妈的孩子。不足是需要系统间交互两次，流程较上述方法复杂。

Token机制

5、支付缓冲区

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐。不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。

Redis 如何做内存优化？

尽量使用 Redis 的散列表，把相关的信息放到散列表里面存储，而不是把每个字段单独存储，这样可以有效的减少内存使用。比如将 Web 系统的用户对象，应该放到散列表里面再整体存储到 Redis，而不是把用户的姓名、年龄、密码、邮箱等字段分别设置 key 进行存储。

Redis 常见的性能问题有哪些？该如何解决？

主服务器写内存快照，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以主服务器最好不要写内存快照。 Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，主从库最好在同一个局域网内。

在分布式数据库中CAP原理CAP+BASE

CAP

经典CAP图

Base

分布式+集群简介

数据类型

Redis字符串(String)

常用

案例

Redis列表(List)

常用

案例

Redis集合(Set)

常用

案例

数学集合类

差集：sdiff

交集：sinter

并集：sunion

Redis哈希(Hash)

常用

案例

Redis有序集合Zset(sorted set)

常用

案例

zcard ：获取集合中元素个数

zcount ：获取分数区间内元素个数，zcount key 开始分数区间 结束分数区间

zrank： 获取value在zset中的下标位置

zscore：按照值获得对应的分数

三种特殊数据类型

geospatial

hyperloglog

bitmap 位图

谈下你对 Redis 的了解？

说一下 Redis 和 Memcached 的区别和共同点

缓存数据的处理流程

为什么要⽤ Redis/为什么要⽤缓存

Redis 一般都有哪些使用场景？

Redis 适合的场景

Redis 不适合的场景

Redis 为什么是单线程的？

Redis 为什么这么快？

什么是缓存穿透？怎么解决？

解决办法

什么是缓存雪崩？该如何解决？

解决办法

缓存穿透，缓存击穿，缓存雪崩解决方案分析

怎么保证缓存和数据库数据的一致性？

1.分别处理

2.高并发情况下

3.基于订阅binlog的同步机制

Redis 持久化有几种方式？

RDB

AOF

RDB 和 AOF 的区别：

Redis 怎么实现分布式锁？

Redis 淘汰策略有哪些？

Redis的原子性如何保证

Redis 有哪些架构模式讲讲各自的特点

单机版

主从复制

哨兵

集群（proxy 型）

集群（直连型）

使用过Redis做异步队列么，你是怎么用的？有什么缺点？

能不能生产一次消费多次呢？

案例

Redis如何存储复杂的数据？

复杂数据存储

json存储

hash存储

获取数据

Redis的过期策略

Redis底层数据结构

1.简单动态字符串

①、常数复杂度获取字符串长度

②、杜绝缓冲区溢出

③、减少修改字符串的内存重新分配次数

④、二进制安全

⑤、兼容部分 C 字符串函数

zcount ：获取分数区间内元素个数，zcount key 开始分数区间结束分数区间

zrank：获取value在zset中的下标位置