Redis的各项功能解决了哪些问题？

先看一下Redis是一个什么对象。官方简介表明到：

Redis是一个基于BSD开源的项目，是一个把布局化的数据放在内存中的一个存储体系，你可以把它作为数据库，缓存和动静中间件来行使。同时支持strings，lists，hashes，sets，sorted sets，bitmaps，hyperloglogs和geospatial indexes等数据范例。它还内建了复制，lua剧本，LRU，事宜等成果，通过redis sentinel实现高可用，通过redis cluster实现了自动分片。以及事宜，宣布/订阅，自动妨碍转移等等。

综上所述，Redis提供了富厚的成果，首次见到也许会感受目眩凌乱，这些成果都是干嘛用的?都办理了什么题目?什么环境下才会用到响应的成果?那么下面从零开始，一步一步的演进来大致的表明下。

1 从零开始

最初的需求很是简朴，我们有一个提供热门消息列表的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的博客中表明过漫衍式于基于收集的差别：基于收集应用的架构)。

在Redis官方的漫衍式方案出来之前，有twemproxy和codis两种方案，这两个方案总体上来说都是依靠proxy来举办漫衍式的，也就是说redis自己并不体谅漫衍式的工作，而是交由twemproxy和codis来认真。而redis官方给出的cluster方案则是把漫衍式的这部门工作做到了每一个redis处事器中，使其不再必要其他的组件就可以独立的完身漫衍式的要求。我们这里不体谅这些方案的优略，我们存眷一下这里的漫衍式到底是要处理赏罚那些工作?也就是twemproxy和codis独立处理赏罚的处理赏罚漫衍式的这部门逻辑和cluster集成到redis处事的这部门逻辑到底在办理什么题目?

如我们前面所说的，一个漫衍式的处事在外界看来就像是一个齐集式的处事一样。那么要做到这一点就面对着有一个题目必要办理：既是增进或镌汰漫衍式处事中的处事器的数目，对斲丧这个处事的客户端而言应该是无感的;那么也就意味着客户端不能穿透漫衍式处事，把本身绑死到某一个台的处事器上去，由于一旦云云，你就再也无法新增处事器，也无法举办妨碍替代。

办理这个题目有两个路子：

第一个路子最直接，那就是我加一此中间层来断绝这种详细的依靠，即twemproxy回收的方法，让全部的客户端只能通过它来斲丧redsi处事，通过它来断绝这种依靠(可是你会发明twermproxy会成为一个单点)，这种环境下每台redis处事器都是独立的，它们之间互相不知对方的存在;

第二个路子是让redis处事器知道互相的存在，通过重定向的机制来引导客户端来完本钱身所必要的操纵，好比客户端链接到了某一个redis处事器，说我要执行这个操纵，redis处事器发明本身无法完成这个操纵，那么就把能完成这个操纵的处事器的信息给到客户端，让客户端去哀求其它的一个处事器，这时辰你就会发明每一个redis处事器都必要保持一份完备的漫衍式处事器信息的一份资料，否则它怎么知道让客户端去找其他的哪个处事器来执行客户端想要的操纵呢。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!