新版本的OpenFeign把ribbon移除了，正常使用应该引入LoadBalancer依赖 1 OpenFeign使用(1) 整合openfeign依赖 1234<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-ope

nacos2.x已不支持ribbon，使用nacos2.x需要手动引入LoadBalancer 1 手写随机负载均衡算法12345678910111213@Resourceprivate RestTemplate restTemplate;//通过restTemplate访问随机一个url地址@RequestMapping("/test")public String loadb

1. 过期策略1.1 立即过期(主动淘汰)每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好，但是会占用大量CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。 1.2 惰性过期(被动淘汰)只有当访问一个key时，才会判断该key是否已经过期，过期则清除。该策略可以最大化的节省CPU资源，却对内存非常不友好。极端情况下可能出现大

总结起来主要有三点：1.纯内存结构。2.请求处理单线程。3.多路复用机制 1 原因1.1 内存KV结构的内存数据库，时间复杂度是O(1)。 1.2 单线程这里说的单线程其实指的是处理客户端的请求是单线程的，可以把它叫做主线程。从4.0版本之后，还引入了一些线程处理其他的事情，比如清理脏数据，无用连接的释放，大key的删除。 ​ 把处理请求的主线程设置成单线程有什么好处呢？ ​ 1.没

1 为什么要用事务Redis的单个命令是原子性的（比如get set mget mset），要么成功要么失败，不存在并发干扰的问题。如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就必须要依赖redis的功能特性来实现了。 Redis提供了事务的功能，可以把一组命令一起执行。Redis的事务有3个特点： 按进入队列的顺序执行。 不会受到其他客户端的请求的影响 事务不能嵌套

1 通信协议Redis监听默认6379的端口号，可以通过TCP方式建立连接。服务端约定了一种特殊的消息格式，每个命令都是以\r\n（CRLF回车+换行）结尾。这种编码格式之前在AOF文件中见到了，叫做Redis Serialization Protocol（RESP，redis序列化协议），发消息或者相应消息需要按这种格式编码，接受消息需要按这种格式解码，redis设计这种格式的原因：容易实现，

如果要实现redis数据的分片，有三种方案。 第一种是在客户端实现相关的逻辑，例如用取模或者一致性哈希对key进行分片，查询和修改都先判断key的路由。 第二种是把做分片处理的逻辑抽取出来，运行一个独立的代理服务，客户端连接到这个代理服务，代理服务做请求的转发。 第三种就是基于服务端实现。 1 客户端Sharding-ShardedJedisRedisTemplate就是对jedis的封装。 J

1 redis定位与特性1.1 SQL与NoSQL​ 大部分时候，我们都会首先考虑用关系型数据库来存储我们的数据，比如SQLServer，Oracle，MySQL 等等。关系型数据库的特点： ​ 1.它以表格的形式，基于行存储数据，是一个二维的模式。 ​ 2.它存储的是结构化的数据，数据存储有固定的模式（scheme），数据需要适应表结构。 ​ 3.表与表之间存在关联（Re

1 列表的局限通过队列的rpush和blpop可以实现消息队列（队尾进队头出），没有任何元素可以弹出的时候，连接会被阻塞。但是基于list实现的消息队列，不支持一对多的消息分发，相当于只有一个消费者。 2 发布订阅模式除了通过list实现消息队列之外，Redis还提供了发布订阅的功能 2.1 订阅频道消息的生产者和消费者是不同的客户端，连接到同一个redis的服务。通过什么对象把生产者和消费者关联

redis支持集群的架构。集群的节点有主节点和从节点之分，主节点叫master，从节点叫slave。slave会通过复制的技术，自动同步master的数据。 1 主从复制配置Redis的主从配置非常的简单，只需要在配置文件里面添加一行配置就可以了。例如一主多从，186是主节点，在每个slave节点的redis.conf配置文件增加一行: 1replicaof 192.168.44.186 637