。

但随着请求量的增加#xff0c;SLA要求的提高#xff0c;我们势必会对Redis进行一些改造和定制性开发。

Redis提供了主从、哨兵、cluster等三种集群模式#xff0c;其中cluster模式为目前大多数公…Redis的数据结构丰富一般不会在功能性上造成困扰。

但随着请求量的增加SLA要求的提高我们势必会对Redis进行一些改造和定制性开发。

Redis提供了主从、哨兵、cluster等三种集群模式其中cluster模式为目前大多数公司所采用的方式。

016383个整数槽内属于无中心化的架构。

但它的维护成本较高slave也不能够参与读取操作。

它的主要问题在于一些批量操作的限制。

由于key被hash到多台机器上所以mget、hmset、sunion等操作就非常的不友好经常发生性能问题。

Redis的主从模式是最简单的模式但无法做到自动failover通常在主从切换后还需要修改业务代码这是不能忍受的。

即使加上haproxy这样的负载均衡组件复杂性也是非常高的。

哨兵模式在主从数量比较多的时候能够显著的体现它的价值。

一个哨兵集群能够监控成百上千个集群但是哨兵集群本身的维护是比较困难的。

幸运的是Redis的文本协议非常简单在netty中甚至直接提供了Redis的codec。

自研一套哨兵系统加强它的功能是可行的。

冷热数据分离

Redis的特点是不管什么数据都一股脑地搞到内存里做计算这对于有时间序列概念有冷热数据之分的业务造成了非常大的成本考验。

为什么大多数开发者喜欢把数据存放在MySQL中而不是Redis中除了事务性要求以外很大原因是历史数据的问题。

通常这种冷热数据的切换是由中间件完成的。

我们上面也谈到了Redis是一个文本协议非常简单。

做一个中间件或者做一个协议兼容的Redis模拟存储是比较容易的。

比如我们Redis中只保留最近一年的活跃用户。

一个好几年不活跃的用户突然间访问了系统这时候我们获取数据的时候就需要中间件进行转换从容量更大速度更慢的存储中查找。

这个时候Redis的作用更像是一个热库更像是一个传统cache层做的事情发生在业务已经上规模的时候。

但是注意直到此时我们的业务层代码一直都是操作的Redis的api。

它们使用这众多的函数指令并不关心数据到底是真正存储在redis中还是在ssdb中。

功能需求

Redis还能玩很多花样。

举个例子全文搜索。

很多人都会首选es但Redis生态就提供了一个模块RediSearch可以做查询可以做filter。

但我们通常还会有更多的需求比如统计类、搜索类、运营效果分析等。

这类需求与大数据相关即使是传统的DB也不能胜任。

这时候我们当然要把Redis中的数据导入到其他平台进行计算啦。

如果你选择的是Redis数据库那么dba打交道的就是rdb而不是binlog。

有很多的rdb解析工具(比如redis-rdb-tools)能够定期把rdb解析成记录导入到hadoop等其他平台。

此时rdb成为所有团队的中枢成为基本的数据交换格式。

导入到其他db后的业务该怎么玩怎么玩完全不会因为业务系统选用了Redis就无法运转。

大多数业务系统跑在Redis上这是很多一直使用MySQL做业务系统的同学所不能想象的。

看完了上面的介绍相信你能够对Redis能够实现的存储功能有个大体的了解。

打开你的社交app、游戏app、视频app看一下它们的功能能够涵盖多少呢

要强调的是某些数据并不是一定要落地到RDBMS才算安全它们并不是一个强需求。

那既然Redis这么厉害为什么还要有mysql、tidb这样的存储呢关键还在于业务属性上。

如果一个业务系统每次交互的数据都是一个非常大的结果集并涉及到非常复杂的统计、过滤工作那么RDBMS是必须的但如果一个系统能够通过某个标识快速定位到一类数据这一类数据在可以预见的未来是有限的那就非常适合Redis存储。

一个电商系统选用Redis做存储就是作死但一个社交系统就快活的多。

在合适的场景选用合适的工具才是我们应该做的。

但是一个系统能否在产品验证期就能快速的响应变化快速开发上线才是成功的关键。

这也是使用Redis做数据库所能够带来的最大好处。

千万别被那概率极低的丢数据场景给吓怕了。

比起产品成功你的系统即使是牢如钢铁也一文不值。