Redis 是在内存在存储数据，当服务器重启则会丢失内存中的数据。 为保证数据安全， Redis 提供了对数据持久化的支持，数据持久化是防止数据丢失的最好方法。
Redis 共有两个数据持久化方式：RDB和AOF。持久化功能有效地避免因进程退出造成数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
Redis Persistence 官网，Redis persistence demystified(Redis 持久化揭秘)，Redis 持久化 –中文译
为解决单个数据库可能存因系统崩溃、设备异常等单点故障导致整个应用系统无法提供服务的问题，数据库系统提供了复制技术来支持多存储服务的数据复制同步。
复制机制是读写分离的基础，也是是集群的基础。 Redis 也支持复制机制，可以将一个 Redis 服务器(master，主实例)中的数据复制到其他 Redis 服务器中(slave, 从实例)。
在 Java 中使用 Redis，基于 Spring Boot 框架。 关于 Spring Boot 集成 Redis，可阅读Spring Boot 2实践系列(十二)：Spring Data Redis 集成详解和使用。
本篇主要演示 Spring Boot 提供的 RedisTemplate 对 Redis 功能特性的使用，主要是管道和事务的操作。各种数据类型的操作比较简单。
Redis 提供了丰富的 API 来操作数据，某些业务需求不只一个 API 可实现，但实现同一功能的不同的 API 在性能上是不一样的。
Redis 是内存级别单线程处理请求，对性能非常在乎。正确的使用 API 就显得尤为重要。
Redis 为满足业务需求提供了丰富的数据类型，在使用时需要注意它们在不同业务场景中的优缺点，还需要考虑选中的数据类型在性能和内存消耗上是否还有优化的空间。
Redis 对小的聚合类型数据进行了特殊的编码处理。Redis2.2版本及以后，存储集合数据的时候会采用内存压缩技术，以使用更少的内存存储更多的数据。当集合中的元素小于给定的个数，或元素小于给定的最大值时，Redis 会以一种非常有效的内存方式进行编码，最多可节省10倍的内存(平均至少节省5倍)。
在缓存领域，Redis 处于遥遥领先的地位，Redis 4 第一个稳定版本发布已经一年多，中间有些小版本的更新。
Redis 新的大版本 Redis 5 于 2018年10月17日(周三) 发布了第一个稳定版本：Redis 5.0.0 stable。
Publish/Subscribe(Pub/Sub-发布/订阅)是两种异步消息通信模式中的一种(另一种是 queue 点对点模式)。在发布-订阅模式中，发布者把消息发送到一个频道(channel)，订阅此频道的消息接收者就可收到消息。
发布-订阅是一对多的通信模式，发布的消息可以被多个订阅者接收，消息发布者不需要知道有那些订阅者，订阅者也不需要知道发布者，订阅者只接收(订阅)自己感兴趣的频道, 类似于调频广播。
应用场景：群发消息、通知多系统更新缓存(数据)、推送关注频道(主题)消息等。未在生产中使用过，可靠性、稳定性未知。
个人认为 Redis 中的这个功能是个鸡肋，还没看到在生产中使用，消息中间件的发布-订阅功能更强大可靠。
Redis 中的事务与传统数据库的事务存在较大的差异，所以理解 Redis 事务，必须跳出传统数据库事务的概念，这是由两者对事务的实现方式不同决定的。
Redis 官方文档对 Redis 事务在处理所有命令的描述是：要么处理所有命令，要么都不处理，因此 Redis 事务也是原子的。 Redis Transactions 官方文档。注：Redis 事务确保原子性的时机不同于传统数据库的事务处理，详见下文。
Redis 管道是客户端将多个命令打包一次性发送给服务器，不用等到单独命令的执行结果返回；而 Redis 管理需要服务器在执行所有的命令后返回结果，所有命令发送和接收只发生一次，大大减少了多个命令单独在网络的耗时延迟。Redis 管道官方文档。
Bitmap：Redis 中的位图并不是一种新的数据类型，它的底层数据类型是字符串。字符串的本质是二进制大对象(BLOB:Binary Large Object)，所以可以视作位图。
Expire：可以通过设置键的过期时间，让 Redis 自动地删除键。
Sort：可以对列表以某种非权重顺序对有序集合的元素进行排序。