读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
支持数据持久化，支持AOF和RDB两种持久化方式。
支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
高性能：
高并发：
1.字符串：redis没有直接使用C语言传统的字符串表示，而是自己实现的叫做简单动态字符串SDS的抽象类型。C语言的字符串不记录自身的长度信息，而SDS则保存了长度信息，这样将获取字符串长度的时间由O(N)降低到了O(1)，同时可以避免缓冲区溢出和减少修改字符串长度时所需的内存重分配次数。 2.链表linkedlist：redis链表是一个双向无环链表结构，很多发布订阅、慢查询、监视器功能都是使用到了链表来实现，每个链表的节点由一个listNode结构来表示，每个节点都有指向前置节点和后置节点的指针，同时表头节点的前置和后置节点都指向NULL。 3.字典hashtable：用于保存键值对的抽象数据结构。redis使用hash表作为底层实现，每个字典带有两个hash表，供平时使用和rehash时使用，hash表使用链地址法来解决键冲突，被分配到同一个索引位置的多个键值对会形成一个单向链表，在对hash表进行扩容或者缩容的时候，为了服务的可用性，rehash的过程不是一次性完成的，而是渐进式的。 4.跳跃表skiplist：跳跃表是有序集合的底层实现之一，redis中在实现有序集合键和集群节点的内部结构中都是用到了跳跃表。redis跳跃表由zskiplist和zskiplistNode组成，zskiplist用于保存跳跃表信息（表头、表尾节点、长度等），zskiplistNode用于表示表跳跃节点，每个跳跃表的层高都是1-32的随机数，在同一个跳跃表中，多个节点可以包含相同的分值，但是每个节点的成员对象必须是唯一的，节点按照分值大小排序，如果分值相同，则按照成员对象的大小排序。 5.整数集合intset：用于保存整数值的集合抽象数据结构，不会出现重复元素，底层实现为数组。 6.压缩列表ziplist：压缩列表是为节约内存而开发的顺序性数据结构，他可以包含多个节点，每个节点可以保存一个字节数组或者整数值。
基于这些基础的数据结构，redis封装了自己的对象系统，包含字符串对象string、列表对象list、哈希对象hash、集合对象set、有序集合对象zset，每种对象都用到了至少一种基础的数据结构。
redis通过encoding属性设置对象的编码形式来提升灵活性和效率，基于不同的场景redis会自动做出优化。不同对象的编码如下：
1.字符串对象string：int整数、embstr编码的简单动态字符串、raw简单动态字符串 2.列表对象list：ziplist、linkedlist 3.哈希对象hash：ziplist、hashtable 4.集合对象set：intset、hashtable 5.有序集合对象zset：ziplist、skiplist
字符串的编码类型
- int：8 个字节的长整型
- embstr：小于等于 39 字节的字符串
- raw：大于 39 字节的字符串
哈希的编码类型
- ziplist：元素个数小于 512，且所有值都小于 64 字节
- hashtable：除上述条件外
列表的编码类型
- ziplist：元素个数小于 512，且所有值都小于 64 字节
- hashtable：除上述条件外
集合的编码类型
- intset：元素个数小于 512，且所有值都是整数
- hashtable：除上述条件外
有序集合的编码类型
- ziplist：元素个数小于 128，且所有值都小于 64 字节
- hashtable：除上述条件外
总结一
总结二
RDB持久化可以手动执行也可以根据配置定期执行，它的作用是将某个时间点上的数据库状态保存到dump.rdb文件中，dump.rdb文件是一个压缩的二进制文件，通过它可以还原某个时刻数据库的状态。由于RDB文件是保存在硬盘上的，所以即使redis崩溃或者退出，只要dump.rdb文件存在，就可以用它来恢复还原数据库的状态。
可以通过SAVE或者BGSAVE来生成RDB文件。
SAVE命令会阻塞redis进程，直到RDB文件生成完毕，在进程阻塞期间，redis不能处理任何命令请求，这显然是不合适的。
BGSAVE则是会fork出一个子进程，然后由子进程去负责生成RDB文件，父进程还可以继续处理命令请求，不会阻塞进程。
AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。
AOF通过追加、写入、同步三个步骤来实现持久化机制。
当AOF持久化处于激活状态，服务器执行完写命令之后，写命令将会被追加append到aof_buf缓冲区的末尾 在服务器每结束一个事件循环之前，将会调用flushAppendOnlyFile函数决定是否要将aof_buf的内容保存到AOF文件中，可以通过配置appendfsync来决定。
always ##aof_buf内容写入并同步到AOF文件
everysec ##将aof_buf中内容写入到AOF文件，如果上次同步AOF文件时间距离现在超过1秒，则再次对AOF文件进行同步
no ##将aof_buf内容写入AOF文件，但是并不对AOF文件进行同步，同步时间由操作系统决定
如果不设置，默认选项将会是everysec，因为always来说虽然最安全（只会丢失一次事件循环的写命令），但是性能较差，而everysec模式只不过会可能丢失1秒钟的数据，而no模式的效率和everysec相仿，但是会丢失上次同步AOF文件之后的所有写命令数据。
优点：
缺点：
一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。
有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。
如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。
定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性过期：惰性删除指的是当我们查询key的时候才对key进行检测，如果已经达到过期时间，则删除。该策略可以最大化地节省CPU资源，却对内存非常不友好。如果这些过期的key没有被访问，那么他就一直无法被删除，而且一直占用内存。
定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。定期删除指的是redis每隔一段时间对数据库做一次检查，删除里面的过期key。由于不可能对所有key去做轮询来删除，所以redis会每次随机取一些key去做检查和删除。
假设redis每次定期随机查询key的时候没有删掉，这些key也没有做查询的话，就会导致这些key一直保存在redis里面无法被删除，这时候就会走到redis的内存淘汰机制。
1.volatile-lru：从已设置过期时间的key中，移出最近最少使用的key进行淘汰 2.volatile-ttl：从已设置过期时间的key中，移出将要过期的key 3.volatile-random：从已设置过期时间的key中随机选择key淘汰 4.allkeys-lru：从key中选择最近最少使用的进行淘汰 5.allkeys-random：从key中随机选择key进行淘汰 6.noeviction：当内存达到阈值的时候，新写入操作报错
定时去清理过期的缓存；
当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
redis通过MULTI、EXEC、WATCH等命令来实现事务机制，事务执行过程将一系列多个命令按照顺序一次性执行，并且在执行期间，事务不会被中断，也不会去执行客户端的其他请求，直到所有命令执行完毕。事务的执行过程如下：
1.服务端收到客户端请求，事务以MULTI开始 2.如果客户端正处于事务状态，则会把事务放入队列同时返回给客户端QUEUED，反之则直接执行这个命令 3.当收到客户端EXEC命令时，WATCH命令监视整个事务中的key是否有被修改，如果有则返回空回复到客户端表示失败，否则redis会遍历整个事务队列，执行队列中保存的所有命令，最后返回结果给客户端
WATCH的机制本身是一个CAS的机制，被监视的key会被保存到一个链表中，如果某个key被修改，那么REDIS_DIRTY_CAS标志将会被打开，这时服务器会拒绝执行事务。
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
事务开始 MULTI
命令入队
事务执行 EXEC
WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
MULTI命令用于开启一个事务，它总是返回OK。MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值 nil 。
通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
UNWATCH命令可以取消watch对所有key的监控。
基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐。
基于主从方案的缺点还是很明显的，假设master宕机，那么就不能写入数据，那么slave也就失去了作用，整个架构就不可用了，除非你手动切换，主要原因就是因为没有自动故障转移机制。而哨兵(sentinel)的功能比单纯的主从架构全面的多了，它具备自动故障转移、集群监控、消息通知等功能。
集群监控：负责监控 redis master 和 slave 进程是否正常工作。
消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。
哨兵至少需要 3 个实例，来保证自己的健壮性。
哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
哨兵可以同时监视多个主从服务器，并且在被监视的master下线时，自动将某个slave提升为master，然后由新的master继续接收命令。整个过程如下：
1.初始化sentinel，将普通的redis代码替换成sentinel专用代码 2.初始化masters字典和服务器信息，服务器信息主要保存ip:port，并记录实例的地址和ID 3.创建和master的两个连接，命令连接和订阅连接，并且订阅sentinel:hello频道 4.每隔10秒向master发送info命令，获取master和它下面所有slave的当前信息 5.当发现master有新的slave之后，sentinel和新的slave同样建立两个连接，同时每个10秒发送info命令，更新master信息 6.sentinel每隔1秒向所有服务器发送ping命令，如果某台服务器在配置的响应时间内连续返回无效回复，将会被标记为下线状态 7.选举出领头sentinel，领头sentinel需要半数以上的sentinel同意 8.领头sentinel从已下线的的master所有slave中挑选一个，将其转换为master 9.让所有的slave改为从新的master复制数据 10.将原来的master设置为新的master的从服务器，当原来master重新回复连接时，就变成了新master的从服务器
sentinel会每隔1秒向所有实例（包括主从服务器和其他sentinel）发送ping命令，并且根据回复判断是否已经下线，这种方式叫做主观下线。当判断为主观下线时，就会向其他监视的sentinel询问，如果超过半数的投票认为已经是下线状态，则会标记为客观下线状态，同时触发故障转移。
通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
每份数据分片会存储在多个互为主从的多节点上
数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
同一分片多个节点间的数据不保持一致性
读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
扩容时时需要需要把旧节点的数据迁移一部分到新节点
hash 算法（大量缓存重建）
一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
redis cluster 的 hash slot 算法
无中心架构，支持动态扩容，对业务透明
具备Sentinel的监控和自动Failover(故障转移)能力
客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
高性能，客户端直连redis服务，免去了proxy代理的损耗
运维也很复杂，数据迁移需要人工干预
只能使用0号数据库
不支持批量操作(pipeline管道操作)
分布式逻辑和存储模块耦合等
透明接入，业务程序不用关心后端Redis实例，切换成本低
Proxy 的逻辑和存储的逻辑是隔离的
代理层多了一次转发，性能有所损耗
redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；
一个 master node 是可以配置多个 slave node 的；
slave node 也可以连接其他的 slave node；
slave node 做复制的时候，不会 block master node 的正常工作；
slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。
主从模式是最简单的实现高可用的方案，核心就是主从同步。主从同步的原理如下：
1.slave发送sync命令到master 2.master收到sync之后，执行bgsave，生成RDB全量文件 3.master把slave的写命令记录到缓存 4.bgsave执行完毕之后，发送RDB文件到slave，slave执行 5.master发送缓存中的写命令到slave，slave执行 
当从库和主库建立MS关系后，会向主数据库发送SYNC命令
主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来
当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis
从Redis接收到后，会载入快照文件并且执行收到的缓存的命令
之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致
槽(slot)
redis通过集群分片的形式来保存数据，整个集群数据库被分为16384个slot，集群中的每个节点可以处理0-16384个slot，当数据库16384个slot都有节点在处理时，集群处于上线状态，反之只要有一个slot没有得到处理都会处理下线状态。通过cluster addslots命令可以将slot指派给对应节点处理。
slot是一个位数组，数组的长度是16384/8=2048，而数组的每一位用1表示被节点处理，0表示不处理，如图所示的话表示A节点处理0-7的slot。
节点
一个redis集群由多个节点node组成，而多个node之间通过cluster meet命令来进行连接，节点的握手过程：
1.节点A收到客户端的cluster meet命令 2.A根据收到的IP地址和端口号，向B发送一条meet消息 3.节点B收到meet消息返回pong 4.A知道B收到了meet消息，返回一条ping消息，握手成功 5.最后，节点A将会通过gossip协议把节点B的信息传播给集群中的其他节点，其他节点也将和B进行握手 
故障转移
如果节点A向节点B发送ping消息，节点B没有在规定的时间内响应pong，那么节点A会标记节点B为pfail疑似下线状态，同时把B的状态通过消息的形式发送给其他节点，如果超过半数以上的节点都标记B为pfail状态，B就会被标记为fail下线状态，此时将会发生故障转移，优先从复制数据较多的从节点选择一个成为主节点，并且接管下线节点的slot，整个过程和哨兵非常类似，都是基于Raft协议做选举。
客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。
代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy
查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。
涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
同时操作多个key,则不能使用Redis事务.
分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set）
当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。
安全特性：互斥访问，即永远只有一个 client 能拿到锁
避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
容错性：只要大部分 Redis 节点存活就可以正常提供服务
1.缓存数据的过期时间设置随机，，避免同时过期，防止同一时间大量数据过期现象发生。
2.一般并发量不是特别多的时候，使用最多的解决方案是加锁排队，限流，避免同时刻大量请求打崩DB。
3.二级缓存，同热key的方案。4.给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力
解决方案：
1.加锁更新，比如请求查询A，发现缓存中没有，对A这个key加锁，同时去数据库查询数据，写入缓存，再返回给用户， 这样后面的请求就可以从缓存中拿到数据了。 2.将过期时间组合写在value中，通过异步的方式不断的刷新过期时间，防止此类现象。也就是设置热点数据永不过期。
直接写个缓存刷新页面，上线时手工操作一下；
数据量不大，可以在项目启动的时候自动进行加载；
定时刷新缓存；
一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
2.提前把热key打散到不同的服务器，降低压力
一个客户端运行了新的命令，添加了新的数据。
Redis检查内存使用情况，如果大于maxmemory的限制， 则根据设定好的策略进行回收。
一个新的命令被执行，等等。
所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下。
Redis是一种基于键值对的NoSQL数据库，它的值主要由string（字符串），hash（哈希），list（列表），set（集合），zset（有序集合）五种基本数据结构构成，除此之外还支持一些其他的数据结构和算法。key都是由字符串构成的，那么这五种数据结构的使用场景有哪些？一起来看看！
一 字符串
字符串类型是Redis最基础的数据结构，字符串类型可以是JSON、XML甚至是二进制的图片等数据，但是最大值不能超过512MB。
1.1 内部编码
Redis会根据当前值的类型和长度决定使用哪种内部编码来实现。
字符串类型的内部编码有3种：
int：8个字节的长整型。 embstr：小于等于39个字节的字符串。 raw：大于39个字节的字符串。
1.2 使用场景
1.2.1 缓存
在web服务中，使用MySQL作为数据库，Redis作为缓存。由于Redis具有支撑高并发的特性，通常能起到加速读写和降低后端压力的作用。web端的大多数请求都是从Redis中获取的数据，如果Redis中没有需要的数据，则会从MySQL中去获取，并将获取到的数据写入redis。
1.2.2 计数
Redis中有一个字符串相关的命令incr key，incr命令对值做自增操作，返回结果分为以下三种情况：
值不是整数，返回错误 值是整数，返回自增后的结果 key不存在，默认键为 0，返回1
比如文章的阅读量，视频的播放量等等都会使用redis来计数，每播放一次，对应的播放量就会加1，同时将这些数据异步存储到数据库中达到持久化的目的。
1.2.3 共享Session
在分布式系统中，用户的每次请求会访问到不同的服务器，这就会导致session不同步的问题，假如一个用来获取用户信息的请求落在A服务器上，获取到用户信息后存入session。下一个请求落在B服务器上，想要从session中获取用户信息就不能正常获取了，因为用户信息的session在服务器A上，为了解决这个问题，使用redis集中管理这些session，将session存入redis，使用的时候直接从redis中获取就可以了。
1.2.4 限速
为了安全考虑，有些网站会对IP进行限制，限制同一IP在一定时间内访问次数不能超过n次。
二 哈希
Redis中，哈希类型是指一个键值对的存储结构。
2.1 内部编码
哈希类型的内部编码有两种：
ziplist（压缩列表）：当哈希类型元素个数小于 hash-max-ziplist-entries配置（默认512个）同时所有值都小于hash-max-ziplist-value配置（默认64字节）时使用。ziplist使用更加紧凑的结构实现多个元素的连续存储，所以比hashtable更加节省内存。hashtable（哈希表）：当ziplist不能满足要求时，会使用hashtable。
2.2 使用场景
由于hash类型存储的是一个键值对，比如数据库有以下一个用户表结构
| id | name | age |
|---|---|---|
| 1 | Java旅途 | 18 |
将以上信息存入redis，用表明:id作为key，用户属性作为值：
hset user:1 name Java旅途 age 18
使用哈希存储会比字符串更加方便直观
三 列表
列表类型用来存储多个有序的字符串，一个列表最多可以存储2^32-1个元素，列表的两端都可以插入和弹出元素。
3.1 内部编码
列表的内部编码有两种：
ziplist（压缩列表）：当哈希类型元素个数小于 list-max-ziplist-entries配置（默认512个）同时所有值都小于list-max-ziplist-value配置（默认64字节）时使用。ziplist使用更加紧凑的结构实现多个元素的连续存储，所以比hashtable更加节省内存。linkedlist（链表）：当ziplist不能满足要求时，会使用linkedlist。
3.2 使用场景
3.2.1 消息队列
列表用来存储多个有序的字符串，既然是有序的，那么就满足消息队列的特点。使用lpush+rpop或者rpush+lpop实现消息队列。除此之外，redis支持阻塞操作，在弹出元素的时候使用阻塞命令来实现阻塞队列。
3.2.2 栈
由于列表存储的是有序字符串，满足队列的特点，也就能满足栈先进后出的特点，使用lpush+lpop或者rpush+rpop实现栈。
3.2.3 文章列表
因为列表的元素不但是有序的，而且还支持按照索引范围获取元素。因此我们可以使用命令lrange key 0 9分页获取文章列表
四 集合
集合类型也可以保存多个字符串元素，与列表不同的是，集合中不允许有重复元素并且集合中的元素是无序的。一个集合最多可以存储2^32-1个元素。
4.1 内部编码
集合类型的内部编码有两种：
intset（整数集合）：当集合中的元素都是整数且元素个数小于 set-max-intset-entries配置（默认512个）时，redis会选用intset来作为集合的内部实现，从而减少内存的使用。hashtable（哈希表）：当intset不能满足要求时，会使用hashtable。
4.2 使用场景
4.2.1 用户标签
例如一个用户对篮球、足球感兴趣，另一个用户对橄榄球、乒乓球感兴趣，这些兴趣点就是一个标签。有了这些数据就可以得到喜欢同一个标签的人，以及用户的共同感兴趣的标签。给用户打标签的时候需要①给用户打标签，②给标签加用户，需要给这两个操作增加事务。
给用户打标签
sadd user:1:tags tag1 tag2
给标签添加用户
sadd tag1:users user:1
sadd tag2:users user:1
使用交集（sinter）求两个user的共同标签
sinter user:1:tags user:2:tags
4.2.2 抽奖功能
集合有两个命令支持获取随机数，分别是：
随机获取count个元素，集合元素个数不变
srandmember key [count]
随机弹出count个元素，元素从集合弹出，集合元素个数改变
spop key [count]
用户点击抽奖按钮，参数抽奖，将用户编号放入集合，然后抽奖，分别抽一等奖、二等奖，如果已经抽中一等奖的用户不能参数抽二等奖则使用spop，反之使用srandmember。
五 有序集合
有序集合和集合一样，不能有重复元素。但是可以排序，它给每个元素设置一个score作为排序的依据。最多可以存储2^32-1个元素。
5.1 内部编码
有序集合类型的内部编码有两种：
ziplist（压缩列表）：当有序集合的元素个数小于
list-max-ziplist-entries配置（默认128个）同时所有值都小于list-max-ziplist-value配置（默认64字节）时使用。ziplist使用更加紧凑的结构实现多个元素的连续存储，更加节省内存。skiplist（跳跃表）：当不满足ziplist的要求时，会使用skiplist。
5.2 使用场景
5.2.1 排行榜
用户发布了n篇文章，其他人看到文章后给喜欢的文章点赞，使用score来记录点赞数，有序集合会根据score排行。流程如下
用户发布一篇文章，初始点赞数为0，即score为0
zadd user:article 0 a
有人给文章a点赞，递增1
zincrby user:article 1 a
查询点赞前三篇文章
zrevrangebyscore user:article 0 2
查询点赞后三篇文章
zrangebyscore user:article 0 2
5.2.2 延迟消息队列
下单系统，下单后需要在15分钟内进行支付，如果15分钟未支付则自动取消订单。将下单后的十五分钟后时间作为score，订单作为value存入redis，消费者轮询去消费，如果消费的大于等于这笔记录的score，则将这笔记录移除队列，取消订单。
总结
在开发中，字符串类型是用的最多的数据类型，导致我们忽视了redis的其他四种数据类型，在具体场景下选择具体的数据类型对提升redis性能有非常大的帮助。redis虽然支持消息队列的实现，但是并不支持ack。所以redis实现的消息队列不能保证消息的可靠性，除非自己实现消息确认机制，不过这非常麻烦，所以如果是重要的消息还是推荐使用专门的消息队列去做。
全部评论