redis 缓存

柔情只为你懂 2022-07-20 15:16 243阅读 0赞

## 我们怎么使用Redis？ ##

公司目前主力开发的产品，是一个典型的平台电商型产品，包含了平台运营方、商家、消费者等角色。

公司提供电商平台，同时负责系统维护和系统保障；商家与公司进行签约后，入驻平台，将商品投放到平台进行展示；平台依据商家签约信息，进行商品与消费者之间的兴趣推荐，消费者通过商品与商家达成消费订单后，平台按单依据签约与商家抽取利润。商家发现日订单分析有了提升后，可能会与平台达成更多的合作。从而演变出了良好的商业发展模式。

平台电商型产品中，非常满足80/20法则(又称为:[帕雷托法则][Link 1]),查询的业务量远远多于写入的业务量，为了提高[TPS][]，降低对数据库的访问。我们也采取常规的做法，选用redis进行缓存常用业务数据。其中典型的就有：1.图片的信息、2.登录后的用户信息、3.全局超时锁、4.验证码。

关于redis的技术选型，其实在我参与产品开发之前就已经完成了，在这个产品里也作为缓存层在使用。产品目前还在雏形孵化阶段，没有考虑太多关于分布式以及高可用的方案，对redis的使用很粗糙，在团队内可能熟悉redis的Developer不多，或者说有空又有耐心还熟悉redis的Developer没有吧？后来与PM的沟通后得知确实如此！

### 缓存图片信息 ###

目前有很多业务在使用该缓存：商品的图片编辑，商家店面形象的图文自我介绍，用户针对订单的图文评价.

这一部分的数据，在产品启动时(没有黑科技，就是在web.xml，自定义listener。)，读取Mysql中的File表，load进redis，数据量约120W条，没有做任何的分库分表处理。

File表的结构如下：

有意思的是，每次产品启动时，读取到的所有File表记录，进行for循环，每一次循环中，访问一次redis。而在产品关闭时，删除redis的key，从而清除缓存？如果数据量愈来愈多，不就像做过山车一样，启动时加载全量数据，使用量飚的很高，关闭时删除全量缓存，使用量逐渐落回低谷(redis有[内存释放机制][Link 2])。对于内存型中间件产品，这样的使用会带来很多的不可靠性。

启动时加载数据到redis时的处理过程,部分为伪码：

这样图片信息缓存的结构看起来是这样:  
[![photos在redis的数据结构示例][photos_redis]][photos_redis]  
实际的情况下，size远大于1000，上文说了约在120w左右，我的这个redis可视化工具(redisclient-win32.x86.2.0)无法获取size这样大的key，报SocketTimeOutException。猜测是向redis获取大key时，无法在一个socket包中写入，造成通讯失败。

以上cacheDao的实现中，没有提供一次批量获取所需的多个图片信息，例如“public MapgetBatchFileInRedis(int\[\] ids)”，甚至在cache interface中都没有提供这样的接口定义。

这样导致在上层逻辑中，出现大量一次性代码。因为调用不集中，给重构带来很大麻烦。

### 缓存登录后的用户信息 ###

在这个产品面向消费者以及商家，都推出了不同的APP。互联网APP为了提高用户体验，以及降低用户登录登出频次(用户的登录/登出操作，对服务器是比较大的开销)，都会对一次登陆成功的用户，默认在一段时间不需要再次登录。即服务器分配Token给APP本地保存，同时服务器保存Token，设置该Token在一段时间不活动后自动失效，APP后续与服务器的通信中，都需要提交该Token鉴权。这是很常规的做法，短时间有效，而且是非关键性小数据，一次写入多次读取，对于服务器来说，没有比memcached或redis更合适的选择了，那为什么没有选择memcached？我个人的猜测是memcached更适合做Object Store Server，而且很重要的redis具有丰富数据结构与[扩容与容灾机制][Link 3]。

用户的第一次登录，服务端进行参数解析，鉴权后，就需要写入2次redis。  
用户的登出接口中，直接是删除当前会话的redis记录。

第一次：写入本次登入的Token与用户信息的关联

第二次：写入本次登入的用户id与24小时内的积分获取信息。

有一个需求定义用户在登录后可以获取积分，但在24小时内的登录只算一次。

那在服务器端的是实现是，用户第一次登录成功后，在redis写入一个与该用户相关的key，并设置24小时后失效，然后再增加积分。用户在24小时内进行第二次登录，先读取redis是否有相关的key，使用exist命令，如果已经有了，就不增加积分了。

这部分的业务属于典型案例，浪费内存空间。  
第一个问题，不应该使用长前缀，每个key都需要set进内存，长前缀意味着空间占用，以及效率低下。  
第二个问题，这不是明显可以使用[Sorted Set数据结构][Sorted Set]?，还可以省掉一次exists检查。

虽然redis的TPS很高，但是我们依旧要避免滥用。

## 这次的问题的描述？ ##

测试MM提出在性能测试环境中，有一些API在并发数到250~300时，出现很多报错。

典型报错的接口有

*  分页获取商品列表
 *  用户登录

应用中配置redis连接池上限值是1000，而在redis server端配置maxClients=10000;区区这点并发，就耗尽redis连接池资源了？绝不可能，问题还在更远的地方等着我.

性能测试环境配置

## 如何一步步的解决问题？ ##

在描述问题产生背景时，其实也提到了很多不合理的地方，但*存在即合理*，处在现在的困境，一定有当时的无奈。现在我们一起来总结一下问题所在。

### 对缓存图片的处理存在的问题 ###

*  产品初始化时全量塞入redis/产品停止运行是全量卸掉
 *  产品初始化时塞入redis时，没有做批量操作
 *  对批量获取图片信息不支持，在接口层面就已经没有定义，对于可预见的需求没有进行考虑，这是架构设计的缺陷。
 *  引申：大量的数据，放在一个key里，会出现问题，需要进行水平切分(Sharding)。

#### 方案 ####

1.图片的Id数据在File表采用了*自增长*的方式生成，不会出现重复，并且有顺序。我们可以利用这一点，在产品初始化时，在Mysql数据库File表只查找2个字段：id/url。程序处理时，先写入reids一个key，使用Hash数据结构，isInitIng:photos-true，标明到正在初始化，其他产品节点不需要重复初始化。使用hmset的方式，一次性将多个键值对存入到redis。完成后，修改isInitIng:photos-false。当有了新图片时，先在Mysql数据库File表进行保存，得到这个图片的Id以及url，使用hset加入该图片到redis。如果需要修改某一张图片的url，也可以用hset。这样在产品停止运行时，是不需要删除redis关于图片的数据的。

2.cache层加入新接口，支持批量获取图片信息

对之前循环调用的上层代码进行修改，改为调用批量获取接口。

3.对于单个key承载大量的数据的情况，方案是对key下的values hash key进行分割，使用一定的算法将块状的数据均匀分布在多个key里。给一个[参考链接][Link 4]。

### 对缓存用户登录的处理存在的问题 ###

*  session的存储不合理，每次登陆都会生成一个新的key值
 *  对USER\_ACTIVITY\_CACHE\_KEY在value部分的数据结构不合理，应采用Sorted Set
 *  对USER\_ACTIVITY\_CACHE\_KEY的命名不合适，过长导致空间浪费和效率低下
 *  因采用错误数据结构，USER\_ACTIVITY\_CACHE\_KEY需要进行多一次的exists判断。

#### 方案 ####

session的存储不合理的解决，通过新的key(uid:token)来反向标记uid与token的关系，2个key的超时时间保持一致，例如

在写入SESSION\_CACHE\_KEY时，同时写入到redis，为保证2次写入的原子性，需要使用[redis的事务][redis]。如果支持用户的多设备在线，只需要将key(uid:token)更改为Sorted Set结构。因为不存在资源的争夺，这个事务几乎不会失败。在用户登出时，删除掉当前会话信息以及用户关联的会话信息(同样是使用redis事务)。

注意，单机redis环境下，事务命令被完整的支持。扩展到多机redis协同工作时，如果使用了twemproxy，则事务命令不受支持，无法应用该方案。[查看twemproxy对redis命令的支持情况][twemproxy_redis]。

#### 隐患和思考 ####

redis事务带来的问题，redis的事务设计比较暴力，这给应用层带来了麻烦。

*  Redis的基本事务（basic transaction）需要用到MULTI命令和EXEC命令，这种事务可以让一个客户端在不被其他客户端打断的情况下执行多个命令。和关系数据库那种可以在执行的过程中进行回滚（rollback）的事务不同，在Redis里面，被MULTI命令和EXEC命令包围的所有命令会一个接一个地执行，直到所有命令都执行完毕为止。当一个事务执行完毕之后，Redis才会处理其他客户端的命令。
 *  [Redis 在事务失败时不进行回滚，而是继续执行余下的命令][Redis]

基于此，redis事务会在客户端高并发时，其他客户端命令产生阻塞，而且事务回滚需要应用层自己解决。关于事务无法自动回滚，这在NoSQL领域是常见问题了。

#### redis时间线设计 ####

接下来对用户在24小时内的积分信息的处理进行改进，以及redis不支持对Set内的单个Element进行有效期设置，我们采用Sorted Set结构，结合Score特性和Quartz来达到元素过期被删除的目的。

#### 隐患和思考 ####

在上文给出的代码中，我们做了一定的容错性，每次删除过去1分钟的所有Element，这样Quartz出现故障时，如果在1分钟内得到fixed，影响的数据只限于1分钟内的Element。每1秒钟触发一次Quartz与删除过去1分钟的所有Element，这2个维度的频率需要权衡。

*  过高频率的访问redis是否会有稳定性问题？
 *  删除Element的时间区间过大，是否会影响redis执行效率(时间复杂度:[O(log(N)+M)][O_log_N_M])，导致阻塞？
 *  高频率删除Element，是否会影响redis的RDB与AOF备份，因此造成额外的问题？

借助Quartz还有misfire的隐患，如何保障Quartz在每一秒钟都顺畅执行一次(Once and only once)，这涉及到操作系统、内存的可靠性，这是一个大的命题，我们不过多讨论。

记录一下对这类问题的思考

*  可以对这个计划任务进行多机并行运行。例如：A计划与B计划都处于运行状态，A在奇数秒触发，B在偶数秒触发。进一步降低2秒内misfire的概率。
 *  在Quartz启动Job时，检测到是业务高峰期，另开启一个异步线程，调用cleanExpireUserWithActivity方法，而cleanExpireUserWithActivity需要承受并发，即redis需要对zremrangeByScore命令支持并发，但redis是[单进程单线程模型][Link 5]。
 *  异步线程受制于redis，还可以进行改进，使用队列，如ActiveMQ。调用cleanExpireUserWithActivity逻辑进行调整，将命令序列化后写入到点对点队列，另外使用程序监听队列(即消费者端)，有新命令时取出，这里实际调用cleanExpireUserWithActivity，仅在调用成功后释放命令。
 *  现在问题在于如何保障ActiveMQ的稳定运行了，应该还有改进方案。

按照以上的方案进行重构后，性能得到显著提升，按理论来说稳定性会有提高，因为不具备稳定性测试的条件，没法比较。

## 遇到了一些问题 ##

1.redis一次批量hmset过多时报错  
hmset操作时，对于一次传入参数数量上限有要求。这取决于你的网络环境下，socket一次写入的字节数上限。

在我本机的环境下(应用与redis都在本机，不同端口，redis以默认配置运行)，Maphash的size大于5w左右就会报错。

在这种情况下，必需要将大Map切分成一块块的Map，循环调用hmset

2.持续写redis时遇到rdb问题  
在完成以上方案的改进后，测试人员的用户登录这个接口在进行性能回归测试时，使用gatling配置250个工作线程进行并发，一共完成50w的用户登录后就算是结束，再根据生成的测试报告分析。  
刚开始每次压到20多w的用户登录时，就会报错，redis连接池无连接了。分析代码是配置了testOnBorrow:true，这个配置会在获取到连接后检查该连接的有效性，如果无效就丢弃，即在连接池删掉一个连接。而此时redis因为问题无法执行用户端的任何命令，所以所有连接都被当做无效连接被丢弃？直到连接池空了。

这是因为默认的redis配置是以[RDB的方式][RDB]进行定期存盘，而存盘时，会拒绝所有外部命令的写入(存盘失败后也会拒绝写入)。因为目前在redis的数据都处于可丢，解决方式也相当的粗暴。

执行完以后，重启应用，再压测，呵呵，bug关闭。

## 总结 ##

1.在最后一步提到RDB定期存盘，解决方案存在问题，强行关闭，会导致redis中的数据存在丢失风险，在这里建议有条件的，配置redis为1主1从，Master不进行任何形式的存盘，而Slave配置RDB和AOF方式的存盘，双保险。应用只连接Master即可。。注意Slave与Master第一次进行同步时会使用全量复制，对资源会有比较大的消耗，尽量选择在业务平峰期进行。  
引申阅读，Master在这里成为了单点，为了Master的高可用，还有进一步的方案，1个Master下挂2个Slave，其中1个Slave(称为A)负责2种方式的存盘，另一个Slave(称为B)作为Master的热备，在Master故障后，参与到投票，成为新的Master，而B节点切换到A，接受A的增量同步。注意自动failover时，外部需要关闭写入命令。完成failover后，使用ip映射切换，使应用层重新恢复使用，相应的，应用层需要做到一定的容错性。实际生产中，不会要求应用层去做容错性措施，会有各种中间件(twemproxy)自动处理。

2.以上业务中对[redis的16个数据库][redis_16]没有使用好，可以按业务将数据存储到不同数据库，隔离影响。

### 常用命令合集 ###

调试过程中，由于可视化工具对redis支持的不够好，使用了很多redis的命令行，现在我们总结一下吧！  
由于docker的风行，好处多多，我们在测试环境、线上环境也使用了docker/docker-compose

#### docker ####

#### ./redis-cli.sh/info ####

#### set/get ####

#### hset/hmset/hget/hmget ####

#### hlen/keys ####

#### config set/get ####

<table style="margin:0px; width:auto; border-collapse:collapse; border-spacing:0px; border:none; font-size:14px; table-layout:fixed"> 
 <tbody> 
 <tr style="background-color:rgb(249,249,249)"> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; margin-top:0px; margin-bottom:0px; padding:1px 20px 1px 1px; color:rgb(102,102,102); line-height:1.6; font-family:'Input Mono','PT Mono',Consolas,Monaco,Menlo,monospace; border:none; text-align:right; background:rgb(29,31,33)">1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
</pre> </td> 
 <td style="padding:0px; vertical-align:middle; border:none"> <pre style="overflow:auto; margin-top:0px; margin-bottom:0px; padding:1px; color:rgb(197,200,198); line-height:1.6; font-family:'Input Mono','PT Mono',Consolas,Monaco,Menlo,monospace; border:none; background:rgb(29,31,33)">127.0.0.1:6379&gt; config get *
 1) "dbfilename"
 2) "dump.rdb"
 3) "requirepass"
 4) ""
 5) "masterauth"
 6) ""
 7) "unixsocket"
 8) ""
 9) "logfile"
 10) ""
 11) "pidfile"
 12) "/var/run/redis.pid"
 13) "maxmemory"
 14) "512000000"
 15) "maxmemory-samples"
 16) "5"
 17) "timeout"
 18) "0"
 19) "tcp-keepalive"
 20) "0"
 21) "auto-aof-rewrite-percentage"
 22) "100"
 23) "auto-aof-rewrite-min-size"
 24) "67108864"
 25) "hash-max-ziplist-entries"
 26) "512"
 27) "hash-max-ziplist-value"
 28) "64"
 29) "list-max-ziplist-entries"
 30) "512"
 31) "list-max-ziplist-value"
 32) "64"
 33) "set-max-intset-entries"
 34) "512"
 35) "zset-max-ziplist-entries"
 36) "128"
 37) "zset-max-ziplist-value"
 38) "64"
 39) "hll-sparse-max-bytes"
 40) "3000"
 41) "lua-time-limit"
 42) "5000"
 43) "slowlog-log-slower-than"
 44) "10000"
 45) "latency-monitor-threshold"
 46) "0"
 47) "slowlog-max-len"
 48) "128"
 49) "port"
 50) "6379"
 51) "tcp-backlog"
 52) "511"
 53) "databases"
 54) "16"
 55) "repl-ping-slave-period"
 56) "10"
 57) "repl-timeout"
 58) "60"
 59) "repl-backlog-size"
 60) "1048576"
 61) "repl-backlog-ttl"
 62) "3600"
 63) "maxclients"
 64) "10000"
 65) "watchdog-period"
 66) "0"
 67) "slave-priority"
 68) "100"
 69) "min-slaves-to-write"
 70) "0"
 71) "min-slaves-max-lag"
 72) "10"
 73) "hz"
 74) "10"
 75) "cluster-node-timeout"
 76) "15000"
 77) "cluster-migration-barrier"
 78) "1"
 79) "cluster-slave-validity-factor"
 80) "10"
 81) "repl-diskless-sync-delay"
 82) "5"
 83) "cluster-require-full-coverage"
 84) "yes"
 85) "no-appendfsync-on-rewrite"
 86) "no"
 87) "slave-serve-stale-data"
 88) "yes"
 89) "slave-read-only"
 90) "yes"
 91) "stop-writes-on-bgsave-error"
 92) "yes"
 93) "daemonize"
 94) "no"
 95) "rdbcompression"
 96) "yes"
 97) "rdbchecksum"
 98) "yes"
 99) "activerehashing"
100) "yes"
101) "repl-disable-tcp-nodelay"
102) "no"
103) "repl-diskless-sync"
104) "no"
105) "aof-rewrite-incremental-fsync"
106) "yes"
107) "aof-load-truncated"
108) "yes"
109) "appendonly"
110) "no"
111) "dir"
112) "F:\\Redis"
113) "maxmemory-policy"
114) "noeviction"
115) "appendfsync"
116) "everysec"
117) "save"
118) "jd 900 jd 300 jd 60"
119) "loglevel"
120) "verbose"
121) "client-output-buffer-limit"
122) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
123) "unixsocketperm"
124) "0"
125) "slaveof"
126) ""
127) "notify-keyspace-events"
128) ""
129) "bind"
130) ""
127.0.0.1:6379&gt; config set save ""
OK
</pre> </td> 
 </tr> 
 </tbody> 
</table>

#### flushdb/flushall ####

## 扩展阅读 ##

*  redis删除有序集合部分过期元素：[http://caozm.blog.51cto.com/1118764/1389168][http_caozm.blog.51cto.com_1118764_1389168]
 *  节约内存：Instagram的Redis实践：[http://blog.nosqlfan.com/html/3379.html][Link 4]
 *  redis持久化机制：[http://shanks.leanote.com/post/Untitled-55ca439338f41148cd000759-22][RDB]
 *  Redis事务的分析及改进：[https://segmentfault.com/a/1190000002594059][https_segmentfault.com_a_1190000002594059]
 *  redis 多数据库：[https://www.ttlsa.com/redis/redis-database/][redis_16]
 *  利用Sorted Set数据结构，为元素设置有效期：[http://stackoverflow.com/questions/7577923/redis-possible-to-expire-an-element-in-an-array-or-sorted-set][http_stackoverflow.com_questions_7577923_redis-possible-to-expire-an-element-in-an-array-or-sorted-set]
 *  redis的Slave选举与优先级：[https://segmentfault.com/a/1190000002685515][https_segmentfault.com_a_1190000002685515]
 *  利用代理中间件实现大规模Redis集群：[http://www.imooc.com/article/4343][http_www.imooc.com_article_4343]

[Link 1]: https://zh.wikipedia.org/wiki/%E5%B8%95%E9%9B%B7%E6%89%98%E6%B3%95%E5%88%99
[TPS]: http://www.ha97.com/5095.html
[Link 2]: http://wangneng-168.iteye.com/blog/2100379
[photos_redis]: /images/20220720/14349d4413884e83b7ac5d3366b02684.png
[Link 3]: http://www.cnblogs.com/EE-NovRain/p/3268476.html
[Sorted Set]: https://redis.readthedocs.org/en/2.4/sorted_set.html
[Link 4]: http://blog.nosqlfan.com/html/3379.html
[redis]: https://redis.readthedocs.org/en/2.4/transaction.html
[twemproxy_redis]: https://github.com/twitter/twemproxy/blob/master/notes/redis.md
[Redis]: http://redisdoc.com/topic/transaction.html
[O_log_N_M]: http://redisdoc.com/sorted_set/zrevrangebyscore.html
[Link 5]: http://www.blogjava.net/caojianhua/archive/2013/01/28/394847.html
[RDB]: http://shanks.leanote.com/post/Untitled-55ca439338f41148cd000759-22
[redis_16]: https://www.ttlsa.com/redis/redis-database/
[http_caozm.blog.51cto.com_1118764_1389168]: http://caozm.blog.51cto.com/1118764/1389168
[https_segmentfault.com_a_1190000002594059]: https://segmentfault.com/a/1190000002594059
[http_stackoverflow.com_questions_7577923_redis-possible-to-expire-an-element-in-an-array-or-sorted-set]: http://stackoverflow.com/questions/7577923/redis-possible-to-expire-an-element-in-an-array-or-sorted-set
[https_segmentfault.com_a_1190000002685515]: https://segmentfault.com/a/1190000002685515
[http_www.imooc.com_article_4343]: http://www.imooc.com/article/4343