为什么要用Redis

最近阅读了《Redis开发与运维》,非常不错。这里对书中的知识整理一下,方便自己回顾一下Redis的整个体系,来对相关知识点查漏补缺。

我按照五点把书中的内容进行一下整理: • 为什么要选择Redis:介绍Redis的使用场景与使用Redis的原因; • Redis常用命令总结:包括时间复杂度总结与具体数据类型在Redis内部使用的数据结构; • Redis的高级功能:包括持久化、复制、哨兵、集群介绍; • 理解Redis:理解内存、阻塞;这部分是非常重要的,前面介绍的都可以成为术,这里应该属于道的部分。; • 开发技巧:主要是一些开发实战的总结,包括缓存设计与常见坑点。

先来开启第一部分的内容,对Redis来一次重新打量。

本系列内容基于:redis-3.2.12

Redis不是万金油

在面试的时候,常被问比较下Redis与Memcache的优缺点,个人觉得这二者并不适合一起比较,一个是非关系型数据库不仅可以做缓存还能干其它事情,一个是仅用做缓存。常常让我们对这二者进行比较,主要也是由于Redis最广泛的应用场景就是Cache。那么Redis到底能干什么?又不能干什么呢?

Redis都可以干什么事儿

缓存,毫无疑问这是Redis当今最为人熟知的使用场景。再提升服务器性能方面非常有效;

排行榜,如果使用传统的关系型数据库来做这个事儿,非常的麻烦,而利用Redis的SortSet数据结构能够非常方便搞定;

计算器/限速器,利用Redis中原子性的自增操作,我们可以统计类似用户点赞数、用户访问数等,这类操作如果用MySQL,频繁的读写会带来相当大的压力;限速器比较典型的使用场景是限制某个用户访问某个API的频率,常用的有抢购时,防止用户疯狂点击带来不必要的压力;

好友关系,利用集合的一些命令,比如求交集、并集、差集等。可以方便搞定一些共同好友、共同爱好之类的功能;

简单消息队列,除了Redis自身的发布/订阅模式,我们也可以利用List来实现一个队列机制,比如:到货通知、邮件发送之类的需求,不需要高可靠,但是会带来非常大的DB压力,完全可以用List来完成异步解耦;

Session共享,以PHP为例,默认Session是保存在服务器的文件中,如果是集群服务,同一个用户过来可能落在不同机器上,这就会导致用户频繁登陆;采用Redis保存Session后,无论用户落在那台机器上都能够获取到对应的Session信息。

Redis不能干什么事儿

Redis感觉能干的事情特别多,但它不是万能的,合适的地方用它事半功倍。如果滥用可能导致系统的不稳定、成本增高等问题。

比如,用Redis去保存用户的基本信息,虽然它能够支持持久化,但是它的持久化方案并不能保证数据绝对的落地,并且还可能带来Redis性能下降,因为持久化太过频繁会增大Redis服务的压力。

简单总结就是数据量太大、数据访问频率非常低的业务都不适合使用Redis,数据太大会增加成本,访问频率太低,保存在内存中纯属浪费资源。

选择总需要找个理由

上面说了Redis的一些使用场景,那么这些场景的解决方案也有很多其它选择,比如缓存可以用Memcache,Session共享还能用MySql来实现,消息队列可以用RabbitMQ,我们为什么一定要用Redis呢?

速度快,完全基于内存,使用C语言实现,网络层使用epoll解决高并发问题,单线程模型避免了不必要的上下文切换及竞争条件; 注意:单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求,像持久化它就会重开一个线程/进程去进行处理

丰富的数据类型,Redis有8种数据类型,当然常用的主要是 String、Hash、List、Set、 SortSet 这5种类型,他们都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令,可以满足绝大部分需求,如果有特殊需求还能自己通过 lua 脚本自己创建新的命令(具备原子性);

除了提供的丰富的数据类型,Redis还提供了像慢查询分析、性能测试、Pipeline、事务、Lua自定义命令、Bitmaps、HyperLogLog、发布/订阅、Geo等个性化功能。

Redis的代码开源在GitHub,代码非常简单优雅,任何人都能够吃透它的源码;它的编译安装也是非常的简单,没有任何的系统依赖;有非常活跃的社区,各种客户端的语言支持也是非常完善。另外它还支持事务(没用过)、持久化、主从复制让高可用、分布式成为可能。

做为一个开发者,对于我们使用的东西不能让它成为一个黑盒子,我们应该深入进去,对它更了解、更熟悉。今天简单说了下Redis的使用场景,以及为什么选择了Redis而不是其它。下次对Redis的内部数据结构及常用命令的时间复杂度进行总结。

原文发布于微信公众号 - 大愚Talk(dayuTalk)

原文发表时间:2018-07-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JavaEdge

Java并发编程实战系列11之性能与可伸缩性Performance and Scalability

线程可以充分发挥系统的处理能力,提高资源利用率。同时现有的线程可以提升系统响应性。 但是在安全性与极限性能上,我们首先需要保证的是安全性。 11.1 对性能的...

3665
来自专栏Golang语言社区

13 年的 Bug 调试经验总结

在《Learning From Your Bugs》一文中,我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近,我回顾了我所有的194个条目(从13岁开始...

3216
来自专栏林冠宏的技术文章

Android 5.0 到 Android 6.0 + 的深坑之一 之 .so 动态库的适配

(原创:https://cloud.tencent.com/developer/user/1148436/activities) 目录:   前序   一,问题...

32010
来自专栏Java学习网

测试是浪费时间,我的程序肯定没问题

测试是浪费时间,我的程序肯定没问题 尽管关于测试驱动开发(TDD)的书和文章有成百上千之多,仍然有很多人从未感受过测试的强大力量。 之所以不愿意去写测试程序不...

2565
来自专栏Golang语言社区

转-Golang分布式设计模式之-----分层设计

提到分布式系统,我们会想到很多机器,分别部署着各自的服务,然后整体组成一个分布式系统。在这类系统中,分布式系统与常规的集中式系统存在着以下三个区别。(来自分布...

41713
来自专栏Golang语言社区

13 年的 Bug 调试经验总结

在《Learning From Your Bugs》一文中,我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近,我回顾了我所有的194个条目(从13岁开始...

3476
来自专栏PingCAP的专栏

性能测试工具的 Coordinated Omission 问题

很早之前就看过 Gil 大神的一篇文章《Your Load Generator Is Probably Lying To You - Take The Red ...

2585
来自专栏樊华恒的专栏

海量之道系列文章之弱联网优化 (五)

在客户端接入服务器调度策略的演化过程中,我们最早采用了“就近接入”的策略,在距离客户端更近的地方部署服务器或使用CDN,期望通过减少RTT来提高网络交互响应性能...

6230
来自专栏Java学习网

13 年的 Bug 调试经验总结

编码 下面这些都是我经历过的会导致难点bug的问题: 1.事件顺序。在处理事件时,提出下列问题会很有成效:事件可以以不同的顺序到达吗?如果我们没有接收到此事件会...

3195
来自专栏IT技术精选文摘

客服系统微服务架构的演化

微服务要求 ? ? ? ? 服务协作 ? 服务治理 ? 服务治理 ? ? ? 1 怀疑第三方 坚持一条信念:“所有第三方服务都不可靠”,不管第三方什么天花乱坠...

4335

扫码关注云+社区

领取腾讯云代金券