Redis 这么火,它都解决了哪些问题?

先看一下redis是一个什么东西 。官方简介解释到:
Redis是一个基于BSD开源的项目,是一个把结构化的数据放在内存中的一个存储系统,你可以把它作为数据库,缓存和消息中间件来使用 。同时支持strings,lists,hashes,sets,sorted sets,bitmaps,hyperloglogs和geospatial indexes等数据类型 。它还内建了复制,lua脚本,LRU,事务等功能,通过redis sentinel实现高可用,通过redis cluster实现了自动分片 。以及事务,发布/订阅,自动故障转移等等 。

综上所述,Redis提供了丰富的功能,初次见到可能会感觉眼花缭乱,这些功能都是干嘛用的?都解决了什么问题?什么情况下才会用到相应的功能?那么下面从零开始,一步一步的演进来粗略的解释下 。
1 从0开始
最初的需求非常简单,我们有一个提供热点新闻列表的api:http://api.xxx.com/hot-news,api的消费者抱怨说每次请求都要2秒左右才能返回结果 。
随后我们就着手于如何提升一下api消费者感知的性能,很快最简单粗暴的第一个方案就出来了:为API的响应加上基于HTTP的缓存控制 cache-control:max-age=600 ,即让消费者可以缓存这个响应十分钟 。
如果api消费者如果有效的利用了响应中的缓存控制信息,则可以有效的改善其感知的性能(10分钟以内) 。但是还有2个弊端:第一个是在缓存生效的10分钟内,api消费者可能会得到旧的数据;第二个是如果api的客户端无视缓存直接访问API依然是需要2秒,治标不治本呐 。
2 基于本机内存的缓存
为了解决调用API依然需要2秒的问题,经过排查,其主要原因在于使用SQL获取热点新闻的过程中消耗了将近2秒的时间,于是乎,我们又想到了一个简单粗暴的解决方案,即把SQL查询的结果直接缓存在当前api服务器的内存中(设置缓存有效时间为1分钟) 。后续1分钟内的请求直接读缓存,不再花费2秒去执行SQL了 。
假如这个api每秒接收到的请求时100个,那么一分钟就是6000个,也就是只有前2秒拥挤过来的请求会耗时2秒,后续的58秒中的所有请求都可以做到即使响应,而无需再等2秒的时间 。
其他API的小伙伴发现这是个好办法,于是很快我们就发现API服务器的内存要爆满了 。。。
3 服务端的Redis
在API服务器的内存都被缓存塞满的时候,我们发现不得不另想解决方案了 。最直接的想法就是我们把这些缓存都丢到一个专门的服务器上吧,把它的内存配置的大大的 。然后我们就盯上了redis 。。。至于如何配置部署redis这里不解释了,redis官方有详细的介绍 。随后我们就用上了一台单独的服务器作为Redis的服务器,API服务器的内存压力得以解决 。
3.1 持久化(Persistence)
单台的Redis服务器一个月总有那么几天心情不好,心情不好就罢工了,导致所有的缓存都丢失了(redis的数据是存储在内存的嘛) 。虽然可以把Redis服务器重新上线,但是由于内存的数据丢失,造成了缓存雪崩,API服务器和数据库的压力还是一下子就上来了 。
所以这个时候Redis的持久化功能就派上用场了,可以缓解一下缓存雪崩带来的影响 。redis的持久化指的是redis会把内存的中的数据写入到硬盘中,在redis重新启动的时候加载这些数据,从而最大限度的降低缓存丢失带来的影响 。
3.2 哨兵(Sentinel)和复制(Replication)
Redis服务器毫无征兆的罢工是个麻烦事 。那么怎办办?答曰:备份一台,你挂了它上 。那么如何得知某一台redis服务器挂了,如何切换,如何保证备份的机器是原始服务器的完整备份呢?
这时候就需要Sentinel和Replication出场了 。Sentinel可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能;Replication则是负责让一个Redis服务器可以配备多个备份的服务器 。Redis也是利用这两个功能来保证Redis的高可用的 。此外,Sentinel功能则是对Redis的发布和订阅功能的一个利用 。
3.3 集群(Cluster)
单台服务器资源的总是有上限的,CPU资源和IO资源我们可以通过主从复制,进行读写分离,把一部分CPU和IO的压力转移到从服务器上 。但是内存资源怎么办,主从模式做到的只是相同数据的备份,并不能横向扩充内存;单台机器的内存也只能进行加大处理,但是总有上限的 。
所以我们就需要一种解决方案,可以让我们横向扩展 。最终的目的既是把每台服务器只负责其中的一部分,让这些所有的服务器构成一个整体,对外界的消费者而言,这一组分布式的服务器就像是一个集中式的服务器一样(之前在解读REST的博客中解释过分布式于基于网络的差异:基于网络应用的架构) 。


推荐阅读