redis采用的是单进程、单线程模型的 kv数据库，由c语言编写，将数据存储在内存里面，读写数据的时候，不会受限于硬盘io的速度限制

redis不使用表，它的数据库不会预定义，不会要求redis对存储的不同数据进行关联 ，所以：性能相对于关系型数据库要高出很多，其存储结构就是键值对，类似于hashmap

redis采用单线程，一般在面对并发场景用多个线程来处理，将io线程和业务线程分开，业务线程使用线程池，避免频繁创建和销毁线程，即便一次请求阻塞，也不会影响到其他请求

redis为什么会反其道而行之？redis单线程结构是说“其主线程是单线程的，主线程包括io事件的处理，以及io对应的相关请求业务的处理，还负责过期键的处理，复制协调，集群协调等等” 这些会被封装成周期性的任务，周期性的处理。避免了多线程里面频繁的上下文切换，锁竞争，使得redis执行起来 效率高

单线程可以处理高并发的请求吗？当然可以了，并发并不是并行。redis使用单线程+io多路复用。多核cpu流行的今天，使用单线程，只用一个核会不会对资源浪费？

不必担心，因为redis早已对相关问题进行验证，首先redis支持的qps相当高，并且qps峰值的时候cpu也并没有跑满，主要问题是网络原因，导致并非不能进一步上升，因此cpu并不是制约瓶颈【可以在多核场景下，启动多个redis实例】。这里提到的单线程是处理网络请求的时候只是单个线程的。。。

一个正式的redisserver肯定不止一个线程，如：持久化的时候，会根据实际情况，以子进程/子线程的方式运行

redis跑在单线程中，所有操作都是按照顺序线性执行的，但是读写操作【等待用户输入/输出】都是阻塞的。所以io操作一般不能直接返回。就会导致整个进程无法对其他用户提供服务，io多路复用就是为解决这个问题而出现的

 

 当使用read/write对某一个文件描述符fd进行读写时，如果当前fd不可读/写，整个redis就不会对其他的操作作出响应

redis采用那个呢？因为redis需要在多个平台运行 ，同时为了最大化的提供效率和性能，会根据编译平台不同选择不同的多路复用函数作为子模块。 

 

 简单动态字符串、

 

 

Hash

List

 Hset【支持交集、并集等】

 

 Sort set

 

 

假如redis里面有一亿个key，有10万个是固定前缀的key，如何将他们全部找不出来 

1. 使用keys 2. 查看总数据

3. 灌入数据

 

4. 查找

 

找出所有以k1打头的key。因为一次返回所有的key，key的数量过大，导致客户端被卡住了。也就是说当redis中key很多的时候，对于内存的消耗和redis服务器都是隐患

这个时候我们可以使用SCAN指令。可以无阻塞的提取出目标的列表，每次执行只会返回少量元素，可以用于生产环境，而不会出现向keys命令带来阻塞的问题

 

 

 

 

 

频道：topic

 

 为了解决这个问题，就需要专业的消息队列了。如：kafka等

 

 

 

 

rdb配置：

 

900s的时候有一次写入就进行备份 

 

当备份进程出错的时候，主进程停止写入，为了保证数据一致性的问题

保存的时候需要压缩，一般不建议开启，避免带来额外的开销

 

  

 

 

 

 

 

开关

写入方式：always[一旦缓存区的内容发生变化，就写入]

ererysec【每隔一秒，写入】推荐

no【交由操作系统决定，一般会等到操作系统满了才开始填充】

 

 

 

 

一个master是用于写操作，其他slave是用于读操作，master/slave代表了一个个独立的redis实例，另外定期的数据备份操作也是选取了其中一个slave完成的。可以最大程度发挥redis的性能，为了支持数据的弱一致性和最终 一致性。 

支持主从同步、从从同步

第一次同步主节点执行bgsave，并同时将后续修改记录到内存buffer，待完成后，将rdb文件全亮同步到从节点里面，从节点完成后就将rdb文件加载到内存中，完成后，再通知主节点，将其间修改及其内存里面的增量数据同步到从节点进行重放

 全量同步完成，后续所有写操作都是在master上完成的，所有读操作都是在slava上进行的。当然了master也可以去读，但是为了提升性能，一般会交由slave去读。

因此用户的写操作，需要及时的扩散到slave里面，保存数据最大程度上的同步

redis的master-slave进程在正常运行期间更新操作，包括写、删、更改等

redis的主从进程在正常运行期间。更新增量同步方式如下：

主从模式的弊端就是不具备高可用性。

当master挂掉后，redis将不能对外提供写入操作