目录
Redis优点
- Redis是一种基于键值对（key-value）的NoSQL数据库
- 与很多键值对数据库不同的是，Redis中的值可以是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位图）、HyperLogLog、GEO（地理信息定位）等多种数据结构和算法组成，因此Redis可以满足很多的应用场景，而且因为Redis会将所有数据都存放在内存中，所以它的读写性能非常惊人。
- Redis可以将内存的数据利用快照和日志的形式保存到硬盘上，这样在发生类似断电或者机器故障的时候，内存中的数据不会“丢失”。
- Redis还提供了键过期、发布订阅、事务、流水线、Lua脚本等附加功能。
- Redis官网：
Redis特性
速度快
- 正常情况下，Redis执行命令的速度非常快，官方给出的数字读写性能可以达到10万/秒，当然这也取决于机器的性能，但这里先不讨论机器性能上的差异，只分析一下是什么造就了Redis除此之快的速度可以大致归纳为以下四点：
- Redis的所有数据都是存放在内存中的，表是谷歌公司2009年给出的各层级硬件执行速度，所以把数据放在内存中是Redis速度快最主要原因。
- Redis是用C语言实现的，一般来说C语言实现的程序“距离”作系统更近，执行速度相对会更快。
- Redis使用了单线程架构，预防了多线程可能产生的竞争问题。
- 作者对于Redis源代码可以说是精打细磨，曾经有人评价Redis是少有的集性能和优雅于一身的开源代码。
基于键值对的数据结构服务器
- 几乎所有的编程语言都提供了类似字典的功能
- 例如Java里的map、Python里的dict，类似于这种组织数据的方式叫作基于键值的方式
- 与很多键值对数据库不同的是，Redis中的值不仅可以是字符串，而且还可以是具体的数据结构，这样不仅能便于在许多应用场景的开发，同时也能够提高开发效率。
- Redis的全称是REmote Dictionary Server，它主要提供了5种数据结构：字符串、哈希、列表、集合、有序集合，同时在字符串的基础之上演变出了位图（Bitmaps）和HyperLogLog两种神奇的“数据结构”，并且随着LBS（Location Based Service，基于位置服务）的不断发展，Redis3.2版本中加入有关GEO（地理信息定位）的功能，总之在这些数据结构的帮助下，开发者可以开发出各种“有意思”的应用。
丰富的功能
- 除了5种数据结构，Redis还提供了许多额外的功能：
- 提供了键过期功能，可以用来实现缓存。
- 提供了发布订阅功能，可以用来实现消息系统。
- 支持Lua脚本功能，可以利用Lua创造出新的Redis命令。
- 提供了简单的事务功能，能在一定程度上保证事务特性。
- 提供了流水线（Pipeline）功能，这样客户端能将一批命令一次性传到Redis，减少了网络的开销。
简单稳定
- Redis的简单主要表现在三个方面：
- 首先，Redis的源码很少，早期版本的代码只有2万行左右，3.0版本以后由于添加了集群特性，代码增至5万行左右，相对于很多NoSQL数据库来说代码量相对要少很多，也就意味着普通的开发和运维人员完全可以“吃透”它。
- 其次，Redis使用单线程模型，这样不仅使得Redis服务端处理模型变得简单，而且也使得客户端开发变得简单。
- 最后，Redis不需要依赖于操作系统中的类库（例如Memcache需要依赖libevent这样的系统类库），Redis自己实现了事件处理的相关功能。Redis虽然很简单，但是不代表它不稳定。
- 以笔者维护的上千个Redis为例，没有出现过因为Redis自身bug而宕掉的情况。
客户端语言多
- Redis提供了简单的TCP通信协议，很多编程语言可以很方便地接入到Redis，并且由于Redis受到社区和各大公司的广泛认可，所以支持Redis的客户端语言也非常多，几乎涵盖了主流的编程语言，例如Java、PHP、Python、C、C++、Nodejs等[1]，第4章我们将对Redis的客户端进行详细说明。
持久化
- 通常看，将数据放在内存中是不安全的，一旦发生断电或者机器故障，重要的数据可能就会丢失，因此Redis提供了两种持久化方式：RDB和AOF，即可以用两种策略将内存的数据保存到硬盘中（如图所示），这样就保证了数据的可持久性。
主从复制
- Redis提供了复制功能，实现了多个相同数据的Redis副本（如图所示），复制功能是分布式Redis的基础。
高可用和分布式
- Redis从2.8版本正式提供了高可用实现Redis Sentinel，它能够保证Redis节点的故障发现和故障自动转移。
- Redis从3.0版本正式提供了分布式实现Redis Cluster，它是Redis真正的分布式实现，提供了高可用、读写和容量的扩展性。
- 参考网址：http://redis.io/clients
Redis使用场景
Redis可以做什么
- 缓存
- 缓存机制几乎在所有的大型网站都有使用，合理地使用缓存不仅可以加快数据的访问速度，而且能够有效地降低后端数据源的压力。Redis提供了键值过期时间设置，并且也提供了灵活控制最大内存和内存溢出后的淘汰策略。可以这么说，一个合理的缓存设计能够为一个网站的稳定保驾护航。
- 排行榜系统
- 排行榜系统几乎存在于所有的网站，例如按照热度排名的排行榜，按照发布时间的排行榜，按照各种复杂维度计算出的排行榜，Redis提供了列表和有序集合数据结构，合理地使用这些数据结构可以很方便地构建各种排行榜系统。
- 计数器应用
- 计数器在网站中的作用至关重要，例如视频网站有播放数、电商网站有浏览数，为了保证数据的实时性，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。
- 社交网络
- 赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适合保存这种类型的数据，Redis提供的数据结构可以相对比较容易地实现这些功能。
- 消息队列系统
- 消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务解耦、非实时业务削峰等特性。
- Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。
Redis不可以做什么
- 可以站在数据规模和数据冷热的角度来进行分析。
- 站在数据规模的角度看，数据可以分为大规模数据和小规模数据
- Redis的数据是存放在内存中的，虽然现在内存已经足够便宜，但是如果数据量非常大
- 例如每天有几亿的用户行为数据，使用Redis来存储的话，基本上是个无底洞，经济成本相当的高。
- 站在数据冷热的角度看，数据分为热数据和冷数据
- 热数据通常是指需要频繁操作的数据，反之为冷数据。
- 例如对于视频网站来说，视频基本信息基本上在各个业务线都是经常要操作的数据，而用户的观看记录不一定是经常需要访问的数据，这里暂且不讨论两者数据规模的差异，单纯站在数据冷热的角度上看，视频信息属于热数据，用户观看记录属于冷数据。
- 如果将这些冷数据放在Redis中，基本上是对于内存的一种浪费，但是对于一些热数据可以放在Redis中加速读写，也可以减轻后端存储的负载，可以说是事半功倍。所以，Redis并不是万金油，相信随着我们对Redis的逐步学习，能够清楚Redis真正的使用场景。
用好Redis的建议
切勿当作黑盒使用，开发与运维同样重要
- 很多使用Redis的开发者认为只要会用API开发相应的功能就可以，更有甚者认为Redis就是get、set、del，不需要知道Redis的原理。
- 但是在我们实际运维和使用Redis的过程中发现，很多线上的故障和问题都是由于完全把Redis当做黑盒造成的
- 如果不了解Redis的单线程模型，有些开发者会在有上千万个键的Redis上执行keys*操作
- 如果不了解持久化的相关原理，会在一个写操作量很大的Redis上配置自动保存RDB。
- 在很多公司内只有专职的关系型数据库DBA，并没有NoSQL的相关运维人员，也就是说开发者很有可能会自己运维Redis，对于Redis的开发者来说既是好事又是坏事。
- 站在好的方面看，开发人员可以通过运维Redis真正了解Redis的一些原理，不单纯停留在开发上。
- 站在坏的方面看，Redis的开发人员不仅要支持开发，还要承担运维的责任，而且由于运维经验不足可能会造成线上故障。但是从实际经验来看，运维足够规模的Redis会对用好Redis更加有帮助。
阅读源码
- 前面提到过，Redis是开源项目，由于作者对Redis代码的极致追求，Redis的代码量相对于许多NoSQL数据库来说是非常小的，也就意味着作为普通的开发和运维人员也是可以“吃透”Redis的。
- 通过阅读优秀的源码，不仅能够加深我们对于Redis的理解，而且还能提高自身的编码水平，甚至可以对Redis做定制化，也就是说可以修改Redis的源码来满足自身的需求，例如新浪微博在Redis的早期版本上做了很多的定制化来满足自身的需求，豌豆荚也开源基于Proxy的Redis分布式实现Codis。
Redis重大版本
- Redis借鉴了Linux操作系统对于版本号的命名规则：
- 版本号第二位如果是奇数，则为非稳定版本（例如2.7、2.9、3.1）
- 如果是偶数，则为稳定版本（例如2.6、2.8、3.0、3.2）。
- 当前奇数版本就是下一个稳定版本的开发版本，例如2.9版本是3.0版本的开发版本。
- 生产环境通常选取偶数版本的Redis，如果对于某些新的特性想提前了解和使用，可以选择最新的奇数版本。
Redis2.6
- Redis2.6在2012年正式发布，经历了17个版本，到2.6.17版本，相比于Redis2.4，主要特性如下：
- 服务端支持Lua脚本。
- 去掉虚拟内存相关功能。
- 放开对客户端连接数的硬编码限制。
- 键的过期时间支持毫秒。
- 从节点提供只读功能。
- 两个新的位图命令：bitcount和bitop。
- 增强了redis-benchmark的功能：支持定制化的压测，CSV输出等功能。
- 基于浮点数自增命令：incrbyfloat和hincrbyfloat。
- redis-cli可以使用--eval参数实现Lua脚本执行。
- shutdown命令增强。
- info可以按照section输出，并且添加了一些统计项。
- 重构了大量的核心代码，所有集群相关的代码都去掉了，cluster功能将会是3.0版本最大的亮点。
- sort命令优化。
Redis2.8
- Redis2.8在2013年11月22日正式发布，经历了24个版本，到2.8.24版本，相比于Redis2.6，主要特性如下：
- 添加部分主从复制的功能，在一定程度上降低了由于网络问题，造成频繁全量复制生成RDB对系统造成的压力。
- 尝试性地支持IPv6。
- 可以通过config set命令设置maxclients。
- 可以用bind命令绑定多个IP地址。
- Redis设置了明显的进程名，方便使用ps命令查看系统进程。
- config rewrite命令可以将config set持久化到Redis配置文件中。
- 发布订阅添加了pubsub命令。
- Redis Sentinel第二版，相比于Redis2.6的Redis Sentinel，此版本已经变成生产可用。
Redis3.0
- Redis3.0在2015年4月1日正式发布，截止到本书完成已经到3.0.7版本，相比于Redis2.8主要特性如下
- Redis3.0最大的改动就是添加Redis的分布式实现Redis Cluster，填补了Redis官方没有分布式实现的空白。Redis Cluster经历了4年才正式发布也是有原因的，具体可以参考Redis Cluster的开发日志http://antirez.com/news/79）。
- Redis Cluster：Redis的官方分布式实现。
- 全新的embedded string对象编码结果，优化小对象内存访问，在特定的工作负载下速度大幅提升。
- lru算法大幅提升。
- migrate连接缓存，大幅提升键迁移的速度。
- migrate命令两个新的参数copy和replace。
- 新的client pause命令，在指定时间内停止处理客户端请求。
- bitcount命令性能提升。
- config set设置maxmemory时候可以设置不同的单位（之前只能是字节），例如config set maxmemory1gb。
- Redis日志小做调整：日志中会反应当前实例的角色（master或者slave）。
- incr命令性能提升。
Redis3.2
- Redis3.2在2016年5月6日正式发布，相比于Redis3.0主要特征如下：
- 添加GEO相关功能。
- SDS在速度和节省空间上都做了优化。
- 支持用upstart或者systemd管理Redis进程。
- 新的List编码类型：quicklist。
- 从节点读取过期数据保证一致性。
- 添加了hstrlen命令。
- 增强了debug命令，支持了更多的参数。
- Lua脚本功能增强。
- 添加了Lua Debugger。
- config set支持更多的配置参数。
- 优化了Redis崩溃后的相关报告。
- 新的RDB格式，但是仍然兼容旧的RDB。
- 加速RDB的加载速度。
- spop命令支持个数参数。
- cluster nodes命令得到加速。
- Jemalloc更新到4.0.3版本。
Redis4.0
- 可能出乎很多人的意料，Redis3.2之后的版本是4.0，而不是3.4、3.6、3.8。一般这种重大版本号的升级也意味着软件或者工具本身发生了重大变革，直到本书截稿前，Redis发布了4.0-RC2，下面列出Redis4.0的新特性：
- 提供了模块系统，方便第三方开发者拓展Redis的功能，更多模块详见：http://redismodules.com。
- PSYNC2.0：优化了之前版本中，主从节点切换必然引起全量复制的问题。
- 提供了新的缓存剔除算法：LFU（Last Frequently Used），并对已有算法进行了优化。
- 提供了非阻塞del和flushall/flushdb功能，有效解决删除bigkey可能造成的Redis阻塞。
- 提供了RDB-AOF混合持久化格式，充分利用了AOF和RDB各自优势。
- 提供memory命令，实现对内存更为全面的监控统计。
- 提供了交互数据库功能，实现Redis内部数据库之间的数据置换。
- Redis Cluster兼容NAT和Docker。
- 参考：《Redis开发与运维》
1316
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
