Redis安装、数据结构、线程与微博中的Reids应用实例讲解

一、Redis是什么

Redis是完全开源免费的，用C语言编写，是一个单线程、高性能的（key / value）内存数据库，基于内存运行并支持持久化的nosql数据库。

安装：

1、网路地址安装下载

Installation
From source code
Download, extract and compile Redis with:

$ wget https://download.redis.io/releases/redis-6.2.3.tar.gz
$ tar xzf redis-6.2.3.tar.gz
$ cd redis-6.2.3
$ make & make install
The binaries that are now compiled are available in the src directory. Run Redis with:

$ src/redis-server
You can interact with Redis using the built-in client:

$ src/redis-cli
redis> set foo bar
OK
redis> get foo
"bar"

2、普通下载

# 下载地址：http://redis.io/download
# 安装步骤：
# 安装gcc
yum install gcc

# 把下载好的redis‐5.0.3.tar.gz放在/usr/local文件夹下，并解压
wget http://download.redis.io/releases/redis‐5.0.3.tar.gz
tar xzf redis‐5.0.3.tar.gz
cd redis‐5.0.3

# 进入到解压好的redis‐5.0.3目录下，进行编译与安装
make & make install


# 修改配置
daemonize yes #后台启动
protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
# 需要注释掉bind
#bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户 端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

# 启动服务
src/redis‐server redis.conf

# 验证启动是否成功
ps ‐ef | grep redis

# 进入redis客户端
src/redis‐cli

# 退出客户端
quit

# 退出redis服务：
（1）pkill redis‐server
（2）kill 进程号
（3）src/redis‐cli shutdown

二、Redis数据结构

主要核心数据类型如下：

2.1、String 操作及应用场景

1、String常用命令

2、String应用场景

我们平时在使用redis存储一个对象的时候，一般都是set userId JSON. 存储前将user序列化成json，获取的时候根据userId获取，然后反序列化成对象。这样比较直观和简单，但是存在一些问题，就是不太灵活。

还有一种存储方式是，按照key（对象名:ID:属性）， value（属性内容）去存储，这样数据结构就是：

set user:1:name test
set user:1:money 9999

127.0.0.1:6379> get user:1:money
"9999"
127.0.0.1:6379> get user:1:name
"test"
127.0.0.1:6379>

这样我们就可以直接获取到对象的属性，而且如果某个属性修改的时候，就可以更方便的只对某个属性进行修改了。不过这样的缺点，就是key会比较多。

当key不存在的时候才会设置成功并返回1，key已经存在的话设置失败返回0.

可以使用redis的incrby命令生成分布式系统全局ID，类似于雪花算法。

但是这个命令每次执行就加1，获取到一个新的全局ID。但是如果每次都这样来生成ID，那么redis压力太大了，所以我们可以直接增加1000，想等于一次生成1000个id，然后本机内存中保存加了1000后的这个数，然后在维护一个增长的数字当做ID。如果到达1000，继续去redis生成一个加1000的。目的是减少和redis的交互。

127.0.0.1:6379> incrby orderId 
(error) ERR wrong number of arguments for 'incrby' command
127.0.0.1:6379> incrby orderId 1
(integer) 1
127.0.0.1:6379> get orderId
"1"
127.0.0.1:6379> incrby orderId 1
(integer) 2
127.0.0.1:6379> 
127.0.0.1:6379> get orderId
"2"
127.0.0.1:6379> incrby orderId 100  // 一下增长100个
(integer) 102
127.0.0.1:6379> get orderId
"102"
127.0.0.1:6379>

2.2、Hash 操作及应用场景

1、Hash常用操作

2、Hash应用场景

我们可以使用Hash数据结构来缓存一些对象。但是如果用户表user中有几十万条记录，那么此时redis中会缓存大量的数据。当我们使用hgetall key的时候，一下子可能会返回几十倍的数据，redis可能要执行非常久的时间！这样redis就会直接阻塞其他命令。Redis最怕的就是bug key.

3、Hash数据的优缺点

2.3、List结构

1、常用命令

2、应用场景

我们知道，当我们在微博关注了某个大v之后，他发送的信息我们都能按照时间收到。那么大家可想想，这种带有时间线的消息流功能是怎么实现的呢？

我们如果使用数据库实现的话，当数据量较大的时候，性能是比较低的。

这时候我们可以使用redis的list数据结构来实现。


设计一（PUSH）： 我们可以给每一个用户设置一个消息的list，当这个用户关注的人发了微博之后，就往这个消息list中LPUSH, 这样只要每次查询这个消息list，就能获取到最新的微博。我们还可以使用LRANGE命令去获取该时间段中的消息。LRANGE是从左边去拿去多少个数据。

我们来分析一下存在的问题：
上面的做法是给一个用户设置一个消息list，去接收该用户关注的所有大v的微博。

但是当某个大v发送一条微博之后，关注他的所有用户的消息list中都要去推送这条信息。如果是只有几千个粉丝，这样做是可行的，只是向几千个用户的消息list中去推送。

优化点：

• 我们可以先推送给已经在线的用户，后面再推送给不在线的用户。这样会大大减少并发推送量；

但是如果这个大v有非常多的粉丝呢？需要向几千万个list中去推送信息吗？这一行是否可行？

设计二(PULL)： 我们可以给每个用户设计一个自己已发送微博的list集合，比如那些大v们每个人都有一个自己的微博list。而当他们发布新的微博后，会向这个list集合中添加一个条数据。而如果是这个大v的粉丝的 在线用户，就可以拉取这个集合中的数据，从而获取到新的数据。

缺点：当我上线后，如果我关注了非常多的大v，就需要拉很多的list集合获取数据，还要排序，非常麻烦。

注意： 新浪微博会根据用户的粉丝进行分类，分别使用push或者pull的方式，即不同的用户使用不同的方式，使得优化最大化。

2.4、Set结构

1、常用操作

2、应用场景

抽奖功能可以使用redis的set实现。只需要设置一个set集合,将参与抽奖的用户加到集合中去：

sadd activity:1 user1, user2, user3, user4, user5

然后根据业务，从这些用户中随机取出三个即可：

127.0.0.1:6379> srandmember activity:1 3
1) "user2,"
2) "user5"
3) "user1,"
127.0.0.1:6379> 

如果存在多次抽奖，并且每次中奖的人不再参与第二次抽奖，可以使用选出后删除命令：

127.0.0.1:6379> spop activity:1 3
1) "user1,"
2) "user3,"
3) "user5"

我们知道，微信中的朋友圈动态只有朋友才可见，就可以使用set集合的交集来处理。

【重要】微信微博中的关注模型

我们可以根据商品的品牌吧商品加到相应的集合中，然后使用交集就可以实现聚合功能。当然，这种功能最好还是使用搜索引擎实现。

2.5、ZSet集合

对于热搜我们就可以使用Zset实现。当用户点击开新闻后，我们将分值设置成1，然后执行对应的命令：

ZINCRBY  hotNews:20190819  1  守护香港


127.0.0.1:6379> zscore hotNews:20190819 守护香港
"3"

三、Redis的单线程和高性能

Redis是单线程吗？

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

Redis 单线程为什么还能这么快？

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

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

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

注意，redis不是我们了解的那种，一个连接过来执行命令的时候，其他的连接必须等待这个连接执行完后才开始执行！！！
redis是nio多路复用，比如一个连接发送命令的时候时间比较久，就会去执行其他连接的命令，而不会阻塞。

# 查看redis支持的最大连接数，在redis.conf文件中可修改，# maxclients 10000

127.0.0.1:6379> CONFIG GET maxclients
##1) "maxclients"
##2) "10000"

四、Redis高级命令

keys：

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

127.0.0.1:6379> keys *
1) "hotNews:20190819"
2) "msg:1"
3) "prod:10002"
4) "user:set"
5) "activity:1"
127.0.0.1:6379> 

keys也可以做key的匹配：

127.0.0.1:6379> keys key*
1) "key2"
2) "key:__rand_int__"
3) "key3"
4) "key1"

scan：渐进式遍历键（redis分页）

SCAN cursor [MATCH pattern] [COUNT count]

scan 参数提供了三个参数，第一个是 cursor 整数值(hash桶的索引值，也成为有表)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(考值，底层遍历的数量不一定)，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。

注意：但是scan并非完美无瑕， 如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键， 这些是我们在开发时需要考虑的。

Info：查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:

Server 服务器运行的环境参数
Clients 客户端相关信息
Memory 服务器运行内存统计数据
Persistence 持久化信息
Stats 通用统计数据
Replication 主从复制相关信息
CPU CPU 使用情况
Cluster 集群信息
KeySpace 键值对统计数量信息

127.0.0.1:6379> info
# Server
redis_version:6.2.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:e6f50df7b731b522
redis_mode:standalone
os:Linux 3.10.0-1062.4.3.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:6183
process_supervised:no
run_id:7101199876de3631f8e2280ff70f8f6f9dfb5f45
tcp_port:6379
server_time_usec:1624877329871892
uptime_in_seconds:4520396
uptime_in_days:52
hz:10
configured_hz:10
lru_clock:14264593
executable:/usr/local/redis/redis-6.2.3/src/redis-server
config_file:/usr/local/redis/redis-6.2.3/redis.conf
io_threads_active:0

# Clients
connected_clients:1
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:56
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0

# Memory
used_memory:875024
used_memory_human:854.52K
used_memory_rss:10436608
used_memory_rss_human:9.95M
used_memory_peak:952832
used_memory_peak_human:930.50K
used_memory_peak_perc:91.83%
used_memory_overhead:830888
used_memory_startup:809968
used_memory_dataset:44136
used_memory_dataset_perc:67.84%
allocator_allocated:986560
allocator_active:1249280
allocator_resident:3485696
total_system_memory:1680240640
total_system_memory_human:1.56G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.27
allocator_frag_bytes:262720
allocator_rss_ratio:2.79
allocator_rss_bytes:2236416
rss_overhead_ratio:2.99
rss_overhead_bytes:6950912
mem_fragmentation_ratio:12.54
mem_fragmentation_bytes:9604312
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:20536
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:3
rdb_bgsave_in_progress:0
rdb_last_save_time:1624876569
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:2334720
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:5
total_commands_processed:119
instantaneous_ops_per_sec:0
total_net_input_bytes:4769
total_net_output_bytes:108736
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:2840
evicted_keys:0
keyspace_hits:46
keyspace_misses:8
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:554
total_forks:6
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:12
dump_payload_sanitizations:0
total_reads_processed:135
total_writes_processed:130
io_threaded_reads_processed:0
io_threaded_writes_processed:0

# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:939ab7a08a1658b7f04289c877fadb8c19bd5712
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:112.135696
used_cpu_user:103.962613
used_cpu_sys_children:0.245312
used_cpu_user_children:0.008715
used_cpu_sys_main_thread:111.981843
used_cpu_user_main_thread:103.960081

# Modules

# Errorstats
errorstat_ERR:count=11
errorstat_WRONGTYPE:count=1

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=8,expires=0,avg_ttl=0
127.0.0.1:6379> 

connected_clients:2 # 正在连接的客户端数量

instantaneous_ops_per_sec:789 # 每秒执行多少次指令

used_memory:929864 # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内 存
used_memory_human:908.07K # Redis分配的内存总量(Kb，human会展示出单位)
used_memory_rss_human:2.28M # 向操作系统申请的内存大小(Mb)（这个值一般是大于used_memory的，因为Redis的内存分配策略会产生内存碎片）
used_memory_peak:929864 # redis的内存消耗峰值(byte)
used_memory_peak_human:908.07K # redis的内存消耗峰值(KB)

maxmemory:0 # 配置中设置的最大可使用内存值(byte),默认0,不限制
maxmemory_human:0B # 配置中设置的最大可使用内存值
maxmemory_policy:noeviction # 当达到maxmemory时的淘汰策略

压测命令

[root@localhost redis-6.2.3]# src/redis-benchmark 

.....
Summary:
  throughput summary: 10656.44 requests per second

理论上可以达到10W。

跟多的设置：

[root@localhost redis-6.2.3]# src/redis-benchmark -h