redis互联网真实应用场景

Redis

1.数据类型（5种）

String、hash、list、set、zset

2.常用命令

2.1 String

分布式锁 SETNX 当别的进程枷锁后 讲不能获得锁

利用INCR来产生分布式序列号，优化策略：一下拿出多个序列号到服务器本地，之后在服务器累加，去完之后再去redis获取

2.2 Hash

hash的结构是K-V（K-V）

redis集群的影响不适合大规模使用

2.3 List列表

Stack = LPUSH + LPOP FILO

2.3.1 List应用场景

微博消息和公众号消息

微博和订阅号的消息列表中，展示的是关注的微博用户和公众号发布的消息，且是按照时间顺序，这就可以利用到redis的List，微博用户（msg-ID 0001）关注了A、B，用户A发布了一个消息（ID 1002），之后用户B发布了一个消息（ID 1001），

当用户登陆后查看属于本人当msg-ID的消息 LRANGE msg-ID 0001 0 4 这样就按照 时间的顺序取得了本人关注列表中发消息的列表

问题是用户如果很多是否会存在性能的瓶颈，实际上可以有很多优化的选择，比如可以先给在线的用户发。

后台可以优化为 push、pull两种模式

2.3.1.1push和pull模式

2.3.1.1.1push 写扩散 （微信）

Push写扩散，为用户A001维护一个msg-ID列表msg- A001，并在列表中记录该用户订阅的用户发布消息（20230401）维护为消息索引（一般为消息ID、类型、发表时间等一些元数据）。当关注的用户发布消息时，发布的消息id会同步到订阅他的用户的msg-ID队列中。
优点：实施性较好（通过网络管道准时推送），读很轻（初始化时仅需要读取自己的inbox即可）
缺点：写很重。每发布一个消息，会导致大量的写操作。当大V动态并发量很高的时候大量动态队列持久化造成磁盘搞IO
优化策略：一般来说，用户发布消息，并不会更新所有followers的订阅列表，仅更新在线followers即可。另外可以设置上限（固定推送用户的上限5000个），设置限流策略，X分钟内完成消息发布，优化存储策略，采用NoSQL等大数据存储方案

2.3.1.1.2 pull 读扩散（微博）

该方式为每个用户维护一个发送列表，记录该用户所有发表过的消息索引。
优点：写很轻，节省空间。用户每发布一条消息，仅需更新自己的outbox。实时性较差（取决于定时轮询时间）
缺点：读操作很重，计算量大。假设你收听了1k用户，则初始化时，需要从1k个用户的outbox拉取消息，然后计算获得最新的n条消息，针对某些大V发布的定时消息，用户在短时间内大量的访问拉取会让服务器出现性能瓶颈

优化策略：利用MQ削峰填谷，遇到恶意的请求直接拒绝，控制轮询的间隔，减少请求的次数，涉及缓存缓存热数据，减少查询的次数，优化查询的效率，增加验证码，分散请求的时间，控制机器人，程序攻击

2.3.1.1.1push+pull 写扩散 + 读扩散（推特）

• 粉丝量小于X，Push模式
• 粉丝量大于X，Pull模式

2.4 set

微信的点赞功能也是运用了set功能的

2.4.1 集合操作

SINTER ： 交集

SUNINO：并集合

SDIFF ：差集

2.4.2 关注模型

2.5zset

3.Redis的单线程和高性能

3.1 Redis是单线程吗?

Redis的单线程主要是指Redis的网络1O和键值对读写是由一个线程来完成的，这也是Redis对外提供键值存储服务的主要流程。但 Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

3.2 Redis单线程为什么还能这么快?

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为Redis是单线程，所以要小心使用Redis指令，对于那些耗时的指令(比如keys，一定要谨慎使用，一不小心就可能会导致Redis卡顿。

3.3 Redis单线程如何处理那么多的并发客户端连接?

Redis的1O多路复用:redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

NIO非阻塞

4.其他高级命令

4.1 keys

全量遍历键，用列出来所有满足特定正则字符串规则的key，当redis数据量比较大时，性能较差，要避免使用

4.2 scan

scan:渐进式遍历键

SCAN cursor[MATCH pattern][COUNTcount
scan参数提供了三个参数，第一个是cursor整数值(hasn桶的索引值)，第二个是key的正则模式，第三个是一次遍历的key的数量(参者
值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor值为0，然后将返回结果中第一个敕数值作为下一次
遍历的cursor。一直遍历到返回的cursor值为0时结束。
注意:但是scan并非完美无瑕，如果在scan的过程中如果有键的变化(增加、删除、修改)，那么遍历效果可能会碰到如下问题:新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键，这些是我们在开发时需要考虑的。

127.0.0.1:6379> scan 0 match key99* count 1000

0 是游标 返回的游标是下次开始的位置 直到再次出现0 找到所有符合规则的值

原因是redis的数据存储的方式是hashmap，先计算hash值再去buket中去寻找匹配的值

新增的如果放到之前的游标的位置 则查不出来，某个buket放的很多 可能rehash 也有可能出新问题