redis总结列表

redis--详解
https://zhuanlan.zhihu.com/p/364787132?utm_medium=social&utm_oi=799560701973762048
https://www.jianshu.com/p/4a6cc0c1c7f1
https://www.cnblogs.com/jiarui-zjb/p/12635496.html
https://baijiahao.baidu.com/s?id=1675905732497463340&wfr=spider&for=pc

Redis介绍
1、五种数据类型

字符串（String）、哈希（Map）、列表（List）、集合（Sets）和有序集合（Sorted sets）

2、Redis主从复制

3、Redis持久化

RDB Snapshotting方式持久化（默认方式）

客户端也可以使用save或者bgsave命令通知redis做一次快照持久化

AOF方式持久化

appendonly yes //启用日志追加持久化方式

appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全持久化，不推荐使用。

appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用。

appendfsync no //完全依赖操作系统，性能最好,持久化没保证。

4、Redis虚拟内存

vm-enabled yes 开启虚拟内存功能

vm-swap-file /tmp/redis.swap 交换出来value保存的文件路径/tmp/redis.swapvm-max-memory268435456 redis使用的最大内存上限（256MB），超过上限后 redis开始交换value到磁盘swap文件中。建议设置为系统空闲内存的60 %-80%

vm-page-size 32 每个redis页的大小32个字节

vm-pages 134217728 最多在文件中使用多少个页,交换文件的大小 =（vm-page-size* vm-pages）4 GB

vm-max-threads 8 用于执行value对象换入换出的工作线程数量。0 表示不使用工作线程

5、Redis集群

1. 突破了单一计算机内存限制，可以利用到多个计算机的内存和

2. 通过配置多个计算机来拓展计算能力，解决网络、网卡瓶颈

6、配置文件

指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

Save分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

Redis默认配置文件中提供了三个条件：

save 900 1

save 300 10

save 60 10000

7、Redis的内存回收

1.Redis过期策略:删除过期时间的key值

1.定时过期

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

2.惰性过期

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

3.定期过期

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

2.Redis淘汰策略:内存使用到达maxmemory上限时触发内存淘汰数据

Redis默认情况下就是使用LRU策略算法。

LRU算法(least RecentlyUsed),最近最少使用算法,也就是说默认删除最近最少使用的键。

缓存清理配置

maxmemory用来设置redis存放数据的最大的内存大小，一旦超出这个内存大小之后，就会立即使用LRU算法清理掉部分数据。

Redis数据淘汰策略

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。

3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

8、redis哨兵、复制、集群设计原理

哨兵（sentinal）

哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

1.Redis哨兵主要功能

（1）集群监控：负责监控Redis master和slave进程是否正常工作

（2）消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

（3）故障转移：如果master node挂掉了，会自动转移到slave node上

（4）配置中心：如果故障转移发生了，通知client客户端新的master地址

3.原理：基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

Redis 复制(Replication)

Redis为了解决单点数据库问题，会把数据复制多个副本部署到其他节点上，通过复制，实现Redis的高可用性，实现对数据的冗余备份，保证数据和服务的高度可靠性。

①从数据库向主数据库发送sync(数据同步)命令。

②主数据库接收同步命令后，会保存快照，创建一个RDB文件。

③当主数据库执行完保持快照后，会向从数据库发送RDB文件，而从数据库会接收并载入该文件。

④主数据库将缓冲区的所有写命令发给从服务器执行。

⑤以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库。

Redis 主从复制、哨兵和集群这三个有什么区别

主从模式：备份数据、负载均衡，一个Master可以有多个Slaves。

sentinel发现master挂了后，就会从slave中重新选举一个master。

cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。

sentinel着眼于高可用，Cluster提高并发量。

1.主从模式：读写分离，备份，一个Master可以有多个Slaves。

2.哨兵sentinel：监控，自动转移，哨兵发现主服务器挂了后，就会从slave中重新选举一个主服务器。

3.集群：为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。

9、Redis的高并发和快速原因

1.redis是基于内存的，内存的读写速度非常快；

2.redis是单线程的，省去了很多上下文切换线程的时间；

3.redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。

10、为什么Redis是单线程的

1.官方答案

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2.性能指标

关于redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

3.详细原因

1）不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除

一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2）单线程多进程集群方案

单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。

所以单线程、多进程的集群不失为一个时髦的解决方案。

3）CPU消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？

可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。

Redis单线程的优劣势

单进程单线程优势

1. 代码更清晰，处理逻辑更简单
2. 不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
3. 不存在多进程或者多线程导致的切换而消耗CPU

单进程单线程弊端

1. 无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；

11、IO多路复用技术

redis 采用网络IO多路复用技术来保证在多连接的时候， 系统的高吞吐量。

多路-指的是多个socket连接，复用-指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术。

12、Redis高并发快总结

1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。

2. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。

3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。

4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

5. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

13、缓存雪崩

数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。

1.缓存的高可用性

缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

2.缓存降级

可以利用ehcache等本地缓存(暂时支持)，但主要还是对源服务访问进行限流、资源隔离（熔断）、降级等。

当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。

降级的最终目的是保证核心服务可用，即使是有损的。

3.Redis备份和快速预热

1)Redis数据备份和恢复

2)快速缓存预热

4.提前演练

最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。

解决方案:
(一)给缓存的失效时间，加上一个随机值，避免集体失效。
(二)使用互斥锁，但是该方案吞吐量明显下降了。
(三)双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点

I 从缓存A读数据库，有则直接返回

II A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。

III 更新线程同时更新缓存A和缓存B。

14、缓存穿透

缓存穿透是指查询一个一不存在的数据。例如：从缓存redis没有命中，需要从mysql数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

解决思路：

如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。

可以给key设置一些格式规则，然后查询之前先过滤掉不符合规则的Key。

解决方案:
(一)利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试
(二)采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。
(三)提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。

15、缓存并发

这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行。

16、缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。

这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

1、直接写个缓存刷新页面，上线时手工操作下；

2、数据量不大，可以在项目启动的时候自动进行加载；

目的就是在系统上线前，将数据加载到缓存中。

以上就是缓存雪崩、预热、降级等的介绍。

 17、Redis缓存的设计、性能、应用与数据集群同步

• 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O（1）
• 支持丰富数据类型，支持string，list，set，sorted set，hash
• 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
• 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

18、Redis持久化的方式

1.RDB

简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

2.AOF

换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，+持久化–就像memcache一样。

19、Redis常见性能问题和解决方案

1. Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
2. 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
3. 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
4. 尽量避免在压力很大的主库上增加从库
5. 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…。这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

20、Redis的适用场景

1.会话缓存（Session Cache）

最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？

幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

2.队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。

3.全页缓存（FPC）

除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。

再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

4.排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

21、Redis的数据同步方式

无论是主备还是主从都牵扯到数据同步的问题，这也分2种情况：

• 同步方式：当主机收到客户端写操作后，以同步方式把数据同步到从机上，当从机也成功写入后，主机才返回给客户端成功，也称数据强一致性。 很显然这种方式性能会降低不少，当从机很多时，可以不用每台都同步，主机同步某一台从机后，从机再把数据分发同步到其他从机上，这样提高主机性能分担同步压力。 在redis中是支持这杨配置的，一台master，一台slave，同时这台salve又作为其他slave的master。
• 异步方式：主机接收到写操作后，直接返回成功，然后在后台用异步方式把数据同步到从机上。 这种同步性能比较好，但无法保证数据的完整性，比如在异步同步过程中主机突然宕机了，也称这种方式为数据弱一致性。

Redis主从同步采用的是异步方式，因此会有少量丢数据的危险。还有种弱一致性的特例叫最终一致性，这块详细内容可参见CAP原理及一致性模型。

 22、分布式与集群

分布式

缓存数据量不断增加时，单机内存不够使用，需要把数据切分不同部分，分布到多台服务器上。 可在客户端对数据进行分片，数据分片算法详见一致性Hash详解、虚拟桶分片。

集群：至少部署两台Redis服务器构成一个小的集群，主要有2个目的：

• 高可用性：在主机挂掉后，自动故障转移，使前端服务对用户无影响。
• 读写分离：将主机读压力分流到从机上。

可在客户端组件上实现负载均衡，根据不同服务器的运行情况，分担不同比例的读请求压力。

23、redis和数据库双写一致性问题

分析:一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。
回答:首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。

监听数据binlog更新缓存，保障不丢数据

24、redis中支持事务

支持，使用multi开启事务，使用exec提交事务。

redis发布订阅【了解即可】
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

25、MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：

voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

26、Memcache与Redis的区别都有哪些？

1)、存储方式

Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。

Redis有部份存在硬盘上，这样能保证数据的持久性。

2)、数据支持类型

Memcache对数据类型支持相对简单。

Redis有复杂的数据类型。

3)、使用底层模型不同

它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。

Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4），value大小

redis最大可以达到1GB，而memcache只有1MB

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

1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。

3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

28、String典型使用场景

注意：Redis的命令不区分大小写，但是key 严格区分大小写！！！

一、计数

由于Redis单线程的特点，我们不用考虑并发造成计数不准的问题，通过 incrby 命令，我们可以正确的得到我们想要的结果。

二、限制次数

比如登录次数校验，错误超过三次5分钟内就不让登录了，每次登录设置key自增一次，并设置该key的过期时间为5分钟后，每次登录检查一下该key的值来进行限制登录。

29、list 数据类型

典型使用场景

 　　一、栈

　　通过命令 lpush+lpop

　　二、队列

　　命令 lpush+rpop

　　三、有限集合

　　命令 lpush+ltrim

　　四、消息队列

　　命令 lpush+brpop

30、Redis5.0新数据结构-stream
Redis的作者在Redis5.0中，放出一个新的数据结构，Stream。Redis Stream 的内部，其实也是一个队列，每一个不同的key，对应的是不同的队列，每个队列的元素，也就是消息，都有一个msgid，并且需要保证msgid是严格递增的。在Stream当中，消息是默认持久化的，即便是Redis重启，也能够读取到消息。那么，stream是如何做到多播的呢？其实非常的简单，与其他队列系统相似，Redis对不同的消费者，也有消费者Group这样的概念，不同的消费组，可以消费同一个消息，对于不同的消费组，都维护一个Idx下标，表示这一个消费群组消费到了哪里，每次进行消费，都会更新一下这个下标，往后面一位进行偏移。

31、配置文件

①、save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）

　　默认如下配置：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

　　　　当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save ""

　　②、stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

　　③、rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

　　④、rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

　　⑤、dbfilename ：设置快照的文件名，默认是 dump.rdb

　　⑥、dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

　　也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。

32、恢复数据

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

获取 redis 的安装目录可以使用 config get dir 命令

33、设置主从关系

①、通过  info replication 命令查看节点角色

②、选择6380端口和6381端口，执行命令：SLAVEOF 127.0.0.1 6379

②、全量复制

　　通过执行 SLAVEOF 127.0.0.1 6379，如果主节点 6379 以前还存在一些 key，那么执行命令之后，从节点会将以前的信息也都复制过来吗？

　　答案也是肯定的，这里我就不贴测试结果了。

③、主从读写分离

　　主节点能够执行写命令，从节点能够执行写命令吗？这里的原因是在配置文件 6381redis.conf 中对于 slave-read-only 的配置

34、全局key操作

--删
flushdb          --清空当前选择的数据库
del mykey mykey2 --删除了两个 Keys

--改
move mysetkey 1        --将当前数据库中的 mysetkey 键移入到 ID 为 1 的数据库中
rename mykey mykey1    --将 mykey 改名为 mykey1
renamenx oldkey newkey --如果 newkey 已经存在，则无效
expire mykey 100 --将该键的超时设置为 100 秒
persist mykey    --将该 Key 的超时去掉,变成持久化的键

--查
keys my*     --获取当前数据库中所有以my开头的key
exists mykey --若不存在,返回0;存在返回1
select 0     --打开 ID 为 0 的数据库
ttl mykey    --查看还有多少秒过期，-1表示永不过期，-2表示已过期
type mykey   --返回mykey对应的值的类型

35、 RDB和AOF优缺点

1、RDB的优点

（1）比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

（2）RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。

（3）RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。

（4）RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。

2、RDB缺点

（1）RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。

（2）RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。

3、AOF优点

（1）该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，如果发生灾难，您只可能会丢失1秒的数据。

（2）AOF日志文件是一个纯追加的文件。就算服务器突然Crash，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。

（3）当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。

4、AOF缺点

（1）在相同的数据集下，AOF文件的大小一般会比RDB文件大。

（2）在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。

RDB和AOF建议

（1）官方建议：是同时开启两种持久化策略。因为有时需要RDB快照是进行数据库备份，更快重启以及发生AOF引擎错误的解决办法。（换句话就是通过RDB来多备份一份数据总是好的）

（2） 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

（3）如果选择AOF，只要硬盘许可，应该尽量减少AOF rewrite的频率。因为一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

36、Redis事务

Redis 通过 MULTI 、EXEC、 DISCARD  和 WATCH 四个命令来实现事务功能。

        MULTI ：标记一个事务块的开始。

         EXEC： 执行所有事务块内的命令。

 DISCARD ：取消事务，放弃执行事务块内的所有命令。

WATCH key [key ...] ：监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

注意：
   （1）当遇到执行错误时，redis放过这种错误，保证事务执行完成。（所以说redis的事务并不是保证原子性）
   （2）与mysql中事务不同，在redis事务遇到执行错误的时候，不会进行回滚，而是简单的放过了，并保证其他的命令正常执行。这个区别在实现业务的时候，需要自己保证逻辑符合预期。
   （3）当事务的执行过程中，如果redis意外的挂了。很遗憾只有部分命令执行了，后面的也就被丢弃了。当然如果我们使用的append-only file方式持久化，redis会用单个write操作写入整个事务内容。即是是这种方式还是有可能只部分写入了事务到磁盘。发生部分写入事务的情况 下，redis重启时会检测到这种情况，然后失败退出。可以使用redis-check-aof工具进行修复，修复会删除部分写入的事务内容。修复完后就 能够重新启动了。
37、实现一个分布式限流

用Redis作为限流组件的核心的原理,将用户的IP地址当Key,一段时间内访问次数为value,同时设置该Key过期时间。

比如某接口设置相同IP10秒内请求5次，超过5次不让访问该接口。

1. 第一次该IP地址存入redis的时候，key值为IP地址,value值为1，设置key值过期时间为10秒。
2. 第二次该IP地址存入redis时，如果key没有过期,那么更新value为2。
3. 以此类推当value已经为5时，如果下次该IP地址在存入redis同时key还没有过期，那么该Ip就不能访问了。
4. 当10秒后，该key值过期，那么该IP地址再进来，value又从1开始，过期时间还是10秒，这样反反复复。

38、Redisson实现分布式锁

1、互斥

在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点。

2、防止死锁

在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。

所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。

3、性能

对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。

所以在锁的设计时，需要考虑两点。

1、锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。

2、锁的范围尽量要小。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。

4、重入

我们知道ReentrantLock是可重入锁，那它的特点就是：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用。关于这点之后会做演示。

1、加锁机制

线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis数据库。

2、watch dog自动延期机制

这个比较难理解，找了些许资料感觉也并没有解释的很清楚。这里我自己的理解就是:

在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(不设置默认30秒），这样的目的主要是防止死锁的发生。

3、可重入加锁机制

Redisson可以实现可重入加锁机制的原因，我觉得跟两点有关：

1、Redis存储锁的数据类型是 Hash类型
2、Hash数据类型的key值包含了当前线程信息。

5、Redis分布式锁的缺点

Redis分布式锁会有个缺陷，就是在Redis哨兵模式下:

客户端1 对某个master节点写入了redisson锁，此时会异步复制给对应的 slave节点。但是这个过程中一旦发生 master节点宕机，主备切换，slave节点从变为了 master节点。

这时客户端2 来尝试加锁的时候，在新的master节点上也能加锁，此时就会导致多个客户端对同一个分布式锁完成了加锁。

这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。

缺陷在哨兵模式或者主从模式下，如果 master实例宕机的时候，可能导致多个客户端同时完成加锁。

 39、缓存穿透

缓存穿透是指查询一个缓存和数据库不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。

1) 验证拦截

接口层进行校验，如鉴定用户权限，对ID之类的字段做基础的校验，如id<=0的字段直接拦截。

2) 布隆过滤器

我们可以提前将真实正确的商品id，添加到过滤器当中，每次再进行查询时，先确认要查询的id是否在过滤器当中，如果不在，则说明id为非法id，则不需要进行后续的查询步骤了。

布隆过滤器是一种比较独特数据结构，有一定的误差。布隆过滤器的特点就是 如果它说不存在那肯定不存在，如果它说存在，那数据有可能实际不存在。

它最大的优点就是性能高，空间占用率及小。

3) 缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

40、redis五种数据结构使用场景

redis五种数据结构使用场景

一、String(字符串)

(1) 存储一些配置数据

(2) 缓存对象

(3) 数据统计

(4) 时间内限制请求次数

(5) 订单号(全局唯一)

(6) 分布式session

二、Hash(哈希)

(1) Redisson分布式锁

(2) 购物车列表

(3) 缓存对象

三、List(列表)

(1) 消息队列

四、set(集合)

(1) 抽奖活动  存储某活动中中奖的用户ID ，因为有去重功能，可以保证同一个用户不会中奖两次。

(2) 点赞  保证一个用户只能点一个赞。key 可以是某某文章、微信朋友圈的文章id

(3) 好友人脉  key 可以是 用户id

五、zset(有序集合)

1. 排行榜(商品销量，视频评分，用户游戏分数)

2. 新闻热搜。

41、主从复制原理

(1) 全量同步

(2) 增量同步

(3) 部分同步

2、主从模式的优缺点

优点

• 做到读写分离，提高服务器性能。Salve可以分载Master的读操作压力，当然写服务依然必须由Master来完成;

• 当Master节点服务挂了，可以让Slave变成Master节点继续提供服务;

缺点

• 在主从模式中，一旦Master节点由于故障不能提供服务，需要人工将Slave节点晋升为Master节点，同时还要通知应用方更新Master节点地址。显然，多数业务场景都不能接受这种故障处理方式;

• redis的Master节点和Slave节点中的数据是一样的，降低的内存的可用性,而且存储能力也有限。

• 主从复制写还都是在Master节点,所以写的压力并没有减少。

42、哨兵模式

哨兵模式，由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Master节点和Slave节点，并在被监视的Master节点进入下线状态时，自动将下线Master服务器

属下的某个Slave节点升级为新的Master节点。但是呢，一个哨兵进程对Redis节点进行监控，就可能会出现问题（单点问题），因此，可以使用多个哨兵来进行监控Redis节点，

sentinel是一种特殊的redis实例，它不存储数据，只对集群进行监控。

1、哨兵主要工作任务

任务1：每个哨兵节点每 10 秒会向Master节点和Slave节点发送 info 命令获取最拓扑结构图，哨兵配置时只要配置对Master节点的监控即可，通过向Master节点发送info，

获取Slave节点的信息，并当有新的Slave节点加入时可以马上感知到

任务2，每个哨兵节点每隔 2 秒会向redis 数据节点的指定频道上发送该哨兵节点对于Master节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解

其它哨兵节点的信息及对Master节点的判断，其实就是通过消息publish 和subscribe 来完成的；

任务3，每隔 1 秒每个哨兵会向Master节点、Slave节点及其余哨兵节点发送一次ping 命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

哨兵模式的优缺点

优点

1. 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
2. 主从可以自动切换，系统更健壮，可用性更高。

缺点

1. 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。
2. 还要多维护一套哨兵模式，实现起来也变的更加复杂增加维护成本。
3. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

43、脑裂导致数据丢失

脑裂 也就是说，某个 Master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master 还运行着。此时哨兵可能就会认为 master 宕机了，然后开启

选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 Master ，也就是所谓的脑裂。

此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的 master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave

挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了。

2) 如果解决脑裂问题

Redis 已经提供了两个配置项来限制Master库的请求处理，分别是 min-slaves-to-write 和 min-slaves-max-lag。　(2.8以后改为min-replicas-to-write 和 min-replicas-max-lag ）

min-slaves-to-write 1
min-slaves-max-lag 10

如上两个配置：要求至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒，如果超过 1 个 slave，数据复制和同步的延迟都超过了 10 秒钟，那么这个时候，master 就

不会再接收任何请求了。

这样一配置的话，就算你的Master库是假故障，那它在假故障期间也无法响应哨兵心跳，也不能和Slave库进行同步，自然也就无法和Slave库进行 ACK 确认了。原Master库就

会被限制接收客户端请求，客户端也就不能在原Master库中写入新数据了。

当然这个配置做不到让数据一点也不丢失，而是让数据尽可能的少丢失。

44、Cluster集群模式

Redis的集群模式本身没有使用一致性hash算法，而是使用slots插槽。

它实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。 

一个Redis Cluster由多个Redis节点构成，节点组内部分为主备两类节点，对应master和slave节点。两者数据准实时一致，通过异步化的主备复制机制来保证。

一个节点组有且只有一个master节点，同时可以有0到多个slave节点，在这个节点组中只有master节点对用户提供些服务，读服务可以由master或者slave提供。如上图中，

包含三个master节点以及三个master对应的slave节点，一般一组集群至少要6个节点才能保证完整的高可用。

其中三个master会分配不同的slot（表示数据分片区间），当master出现故障时，slave会自动选举成为master顶替Master节点继续提供服务。

1、集群的一些特点

1. redis cluster模式采用了无中心节点的方式来实现，每个Master节点都会与其它Master节点保持连接。节点间通过gossip协议交换彼此的信息，同时每个Master节点又有

一个或多个Slave节点；

2. 客户端连接集群时，直接与redis集群的每个Master节点连接，根据hash算法取模将key存储在不同的哈希槽上；

3. 在集群中采用数据分片的方式，将redis集群分为16384个哈希槽。如下图所示，这些哈希槽分别存储于三个Master节点中：

• Master1负责0~5460号哈希槽
• Master2负责5461~10922号哈希槽
• Master3负责10922~16383号哈希槽

2、Master节点故障处理方式

redis 集群中Master节点故障处理方式与哨兵模式较为相像，当约定时间内某节点无法与集群中的另一个节点顺利完成ping消息通信时，则将该节点标记为主观下线状态，同时

将这个信息向整个集群广播。

如果一个节点收到某个节点失联的数量达到了集群的大多数时，那么将该节点标记为客观下线状态，并向集群广播下线节点的fail消息。然后立即对该故障节点进行主从切换。

等到原来的Master节点恢复后，会自动成为新Master节点的Slave节点。如果Master节点没有Slave节点，那么当它发生故障时，集群就将处于不可用状态。

3、扩容问题

在cluster中我们如何动态上线某个节点呢。当集群中加入某个节点时，哈希槽又是如何来进行分配的？当集群中加入新节点时，会与集群中的某个节点进行握手，该节点会把集群

内的其它节点信息通过gossip协议发送给新节点，新节点与这些节点完成握手后加入到集群中。

然后集群中的节点会各取一部分哈希槽分配给新节点，如下图：

• Master1负责1365-5460
• Master2负责6827-10922
• Master3负责12288-16383
• Master4负责0-1364,5461-6826,10923-12287

4、关于 gossip协议

有关gossip协议这里需要单独解释下

在整个redis cluster架构中，如果出现以下情况

• 新加入节点
• slot迁移
• 节点宕机
• slave选举成为master

5、gossip的优缺点

优点: gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新有一定的延时，降低了压力； 去中心化、可扩展、

容错、一致性收敛、简单。 由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

缺点: 元数据更新有延时可能导致集群的一些操作会有一些滞后。 消息的延迟 ， 消息冗余 。

45、分布式锁Jedis与Redisson对比

概况对比

Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

Jedis中的方法调用是比较底层的暴露的Redis的API，也即Jedis中的Java方法基本和Redis的API保持着一致，了解Redis的API，也就能熟练的使用Jedis。而Redisson中的方法则是进行比较高的抽象，每个方法调用可能进行了一个或多个Redis方法调用。

46、缓存需要考虑的一些细节

使用缓存，可以降低耗时，提供系统吞吐性能。但是，使用缓存，会存在数据一致性的问题。

1、几种缓存使用模式

• Cache-Aside Pattern，旁路缓存模式
• Read-Through/Write-Through（读写穿透）
• Write- behind （异步缓存写入）

二、缓存穿透
1、原理
缓存穿透`：指查询一个一定不存在的数据，由于缓存不命中时，需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。”
缓存穿透一般都是这几种情况产生的：业务不合理的设计、业务/运维/开发失误的操作、黑客非法请求攻击。如何避免缓存穿透呢？

2、解决办法
一般有三种方法。
如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。
如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）
使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。

三、缓存雪崩
1、原理
缓存雪崩：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。”
2、解决办法
缓存雪奔一般是由于大量数据同时过期造成的，对于这个原因，可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。
Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。

四、缓存机击穿
1、原理
缓存击穿：指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。”
缓存击穿看着有点像缓存雪崩，其实它两区别是，缓存雪奔是指数据库压力过大甚至down机，缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是在于击穿针对某一热点key缓存，雪奔则是很多key。
2、解决方法
解决方案就有两种：
使用互斥锁方案。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。
“永不过期”。是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间。

五、缓存热Key
1、原理
在Redis中，我们把访问频率高的key，称为热点key。如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。
2、解决方法
如何解决热key问题？
Redis集群扩容：增加分片副本，均衡读流量；
对热key进行hash散列，比如将一个key备份为key1,key2……keyN，同样的数据N个备份，N个备份分布到不同分片，访问时可随机访问N个备份中的一个，进一步分担读流量；
使用二级缓存，即JVM本地缓存,减少Redis的读请求。

六、缓存容量内存考虑
1、评估容量，合理利用
如果我们使用的是Redis，而Redis的内存是比较昂贵的，我们不要什么数据都往Redis里面塞，一般Redis只缓存查询比较频繁的数据。同时，我们要合理评估Redis的容量，也避免频繁set覆盖，导致设置了过期时间的key失效。
如果我们使用的是本地缓存，如guava的本地缓存，也要评估下容量。避免容量不够。
2、Redis的八种内存淘汰机制
为了避免Redis内存不够用，Redis用8种内存淘汰策略保护自己~

volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰；
allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰。
volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。
allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰；
volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据。
allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰；
noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。
3、不同的业务场景，Redis选择适合的数据结构**
排行榜适合用zset
缓存用户信息一般用hash
消息队列，文章列表适用用list
用户标签、社交需求一般用set
计数器、分布式锁等一般用String类型

47、twemproxy explore

twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器，非常具有应用价值。但是当使用比较多的时候，就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。 搜索了不少的开源代理项目，知乎实现的python分片客户端。node的代理中间层，还有各种restfull的开源代理。

• RedBrige

  • C + epoll实现的一个小的webserver
  • redis自身执行lua脚本的功能来执行redis命令
  • 访问时在url中带上lua脚本文件的名字，直接调用执行该lua脚本
  • 本质是通过http协议远程执行lua脚本

• Webdis

  • libevent, http-parser...实现的小型web服务器
  • C 语言实现，通过unix-socket,TCP调用redis命令。
  • 访问方法： /cmd/key/arg0,arg1,... 实质是对redis命令的简单变换

• redis-proxy

  • 使用node写的redis代理层。
  • 支持主从节点的失败处理（可以仔细研究）
  • 测试后发现性能为原生的1/3

• twemproxy

  • 支持失败节点自动删除

    • 可以设置重新连接该节点的时间
    • 可以设置连接多少次之后删除该节点
    • 该方式适合作为cache存储

  • 支持设置HashTag

    • 通过HashTag可以自己设定将两个KEYhash到同一个实例上去。

  • 减少与redis的直接连接数

    • 保持与redis的长连接
    • 可设置代理与后台每个redis连接的数目

  • 自动分片到后端多个redis实例上

    • 多种hash算法（部分还没有研究明白)
    • 可以设置后端实例的权重

  • 避免单点问题

    • 可以平行部署多个代理层.client自动选择可用的一个

  • 支持redis pipelining request

  • 支持状态监控

    • 可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
    • 可设置监控信息刷新间隔时间

  • 高吞吐量

    • 连接复用，内存复用。
    • 将多个连接请求，组成reids pipelining统一向redis请求。

Redis 的 Java 客户端#

Redis 官方推荐的 Java 客户端有Jedis、lettuce 和 Redisson。

1. Jedis

Jedis 是老牌的 Redis 的 Java 实现客户端，提供了比较全面的 Redis 命令的支持，其官方网址是：http://tool.oschina.net/uploads/apidocs/redis/clients/jedis/Jedis.html。

优点：

• 支持全面的 Redis 操作特性（可以理解为API比较全面）。

缺点：

• 使用阻塞的 I/O，且其方法调用都是同步的，程序流需要等到 sockets 处理完 I/O 才能执行，不支持异步；
• Jedis 客户端实例不是线程安全的，所以需要通过连接池来使用 Jedis。

2. lettuce

lettuce （[ˈletɪs]），是一种可扩展的线程安全的 Redis 客户端，支持异步模式。如果避免阻塞和事务操作，如BLPOP和MULTI/EXEC，多个线程就可以共享一个连接。lettuce 底层基于 Netty，支持高级的 Redis 特性，比如哨兵，集群，管道，自动重新连接和Redis数据模型。lettuce 的官网地址是：https://lettuce.io/

优点：

• 支持同步异步通信模式；
• Lettuce 的 API 是线程安全的，如果不是执行阻塞和事务操作，如BLPOP和MULTI/EXEC，多个线程就可以共享一个连接。

3. Redisson

Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的 Java 常用对象，还提供了许多分布式服务。其中包括( BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson 提供了使用Redis 的最简单和最便捷的方法。Redisson 的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。Redisson的官方网址是：https://redisson.org/

优点：

• 使用者对 Redis 的关注分离，可以类比 Spring 框架，这些框架搭建了应用程序的基础框架和功能，提升开发效率，让开发者有更多的时间来关注业务逻辑；
• 提供很多分布式相关操作服务，例如，分布式锁，分布式集合，可通过Redis支持延迟队列等。

缺点：

• Redisson 对字符串的操作支持比较差。

4. 使用建议

结论：lettuce + Redisson