Redis方案

骑猪看日落 2022-07-15 11:50 154阅读 0赞

**1，Redis**

*  **丰富的数据结构（Data Structures）**
 *   *  **字符串（String）**
     *   *  Redis字符串能包含**任意类型**的数据
         *  一个字符串类型的值最多能存储**512M字节**的内容
         *  利用**INCR命令簇**（**INCR, DECR, INCRBY**）来把字符串当作**原子计数器**使用
         *  使用**APPEND**命令在字符串后添加内容
     *  **列表（List）**
     *   *  Redis列表是简单的字符串列表，按照插入顺序排序
         *  你可以添加一个元素到列表的**头部（左边：LPUSH）**或者**尾部（右边：RPUSH）**
         *  **一个列表**最多可以包含232-1个元素（4294967295，每个表超过**40亿个元素**）
         *  在社交网络中建立一个时间线模型，使用**LPUSH**去添加**新的元素**到**用户时间线**中，使用**LRANGE**去检索一些**最近插入的条目**
         *  你可以同时使用**LPUSH**和**LTRIM**去创建一个**永远不会超过指定元素数目**的**列表**并同时记住**最后的N个元素**
         *  列表可以用来当作**消息传递**的**基元（primitive）**，例如，众所周知的用来创建后台任务的Resque Ruby库
     *  **集合（Set）**
     *   *  Redis集合是一个**无序**的，**不允许相同成员存在**的字符串合集（**Uniq操作**，获取某段时间所有数据**排重值**）
         *  支持一些服务端的命令从现有的集合出发去进行**集合运算**，如合并（**并集：union**）,求交(**交集：intersection**)，**差集**, 找出不同元素的操作（共同好友、二度好友）
         *  用集合跟踪一个独特的事。想要知道所有访问某个博客文章的独立IP？只要每次都用SADD来处理一个页面访问。那么你可以肯定重复的IP是不会插入的（ 利用**唯一性**，可以**统计访问网站的所有独立IP**）
         *  Redis集合能很好的表示**关系**。你可以创建一个tagging系统，然后用集合来代表单个tag。接下来你可以用SADD命令把所有拥有tag的对象的所有ID添加进集合，这样来表示这个特定的tag。如果你想要同时有3个不同tag的所有对象的所有ID，那么你需要使用**SINTER**
         *  使用**SPOP**或者**SRANDMEMBER**命令**随机地获取元素**
     *  **哈希（Hashes）**
     *   *  Redis Hashes是字符串字段和字符串值之间的映射
         *  尽管Hashes主要用来表示对象，但它们也能够**存储许多元素**
     *  **有序集合（Sorted Sets）**
     *   *  Redis有序集合和Redis集合类似，是**不包含相同字符串**的合集
         *  每个有序集合的成员都**关联着一个评分**，这个评分用于把有序集合中的成员按最低分到最高分排列（**排行榜应用，取TOP N操作**）
         *  使用有序集合，你可以非常快地（O(log(N))）完成添加，删除和更新元素的操作
         *  元素是在插入时就排好序的，所以很快地通过**评分(score)**或者**位次(position)**获得一个**范围的元素**（需要**精准设定过期时间**的应用）
         *  轻易地访问任何你需要的东西: **有序的元素**，**快速的存在性测试**，**快速访问集合中间元素**
         *  在一个**巨型在线游戏**中建立一个**排行榜**，每当有新的记录产生时，使用**ZADD** 来更新它。你可以用**ZRANGE**轻松地获取**排名靠前的用户**， 你也可以提供一个用户名，然后用**ZRANK**获取他在**排行榜中的名次**。 同时使用**ZRANK**和**ZRANGE**你可以获得与指定用户有相同分数的用户名单。 所有这些操作都非常迅速
         *  有序集合通常用来**索引存储**在Redis中的数据。 例如：如果你有很多的hash来表示用户，那么你可以使用一个有序集合，这个集合的年龄字段用来当作评分，用户ID当作值。用**ZRANGEBYSCORE**可以简单快速地检索到**给定年龄段**的所有用户
 *  **复制（Replication, Redis复制很简单易用，它通过配置允许slave Redis Servers或者Master Servers的复制品）**
 *   *  **一个Master**可以有**多个Slaves**
     *  Slaves能**通过接口其他slave的链接**，除了可以接受同一个master下面slaves的链接以外，还可以接受同一个结构图中的其他slaves的链接
     *  redis**复制**是在**master段**是**非阻塞**的，这就意味着master在同一个或多个slave端**执行同步**的时候还可以**接受查询**
     *  **复制**在**slave端**也是非阻塞的，假设你在redis.conf中配置redis这个功能，当slave在执行的新的同步时，它仍可以用旧的数据信息来提供查询，否则，你可以配置当redis slaves去master失去联系是，slave会给发送一个客户端错误
     *  为了有多个slaves可以做只读查询，**复制可以重复2次，甚至多次**，具有**可扩展性**（例如：slaves对话与重复的排序操作，有多份数据冗余就相对简单了）
     *  他可以利用**复制去避免在master端保存数据**，只要对master端redis.conf进行配置，就可以避免保存（所有的保存操作），然后通过slave的链接，来实时的保存在slave端
 *  **LRU过期处理（Eviction）**
 *   *  EVAL 和 EVALSHA 命令是从 Redis 2.6.0 版本开始的，使用内置的 Lua 解释器，可以对 Lua 脚本进行求值
     *  Redis 使用**单个 Lua 解释器去运行所有脚本**，并且， Redis 也保证脚本会以**原子性(atomic)**的方式执行： **当某个脚本正在运行的时候，不会有其他脚本或 Redis 命令被执行**。 这和使用**MULTI / EXEC** **包围的事务**很类似。 在其他别的客户端看来，脚本的效果(effect)要么是不可见的(not visible)，要么就是已完成的(already completed)
     *  LRU过期处理（Eviction）
     *   *  Redis允许为每一个key设置不同的**过期时间**，当它们到期时将自动从服务器上删除（EXPIRE）
 *  **事务**
 *   *  **MULTI 、 EXEC 、 DISCARD** 和 **WATCH** 是 Redis **事务的基础**
     *  事务是一个**单独的隔离操作**：事务中的所有**命令**都会**序列化、按顺序地执行**。事务在**执行的过程中**，**不会被其他客户端发送来的命令请求所打断**
     *  **事务中的命令要么全部被执行，要么全部都不执行**，**EXEC 命令负责触发并执行事务中的所有命令**  
     *  Redis 的 Transactions 提供的并**不是严格的 ACID 的事务**
     *  Transactions 还是提供了基本的**命令打包执行**的功能： 可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行
     *  Redis 还提供了一个 **Watch** 功能，你可以**对一个 key 进行 Watch**，然后再**执行 Transactions**，在这过程中，如果这个 **Watched 的值进行了修改**，那么这个 **Transactions 会发现并拒绝执行**
 *  **数据持久化**
 *   *  **RDB**
     *   *  **特点**
         *   *  RDB持久化方式能够在**指定的时间间隔**能对你的**数据进行快照存储**
         *  **优点**
         *   *  RDB是一个非常**紧凑的文件**,它保存了**某个时间点得数据集**,非常**适用于数据集的备份**
             *  RDB是一个紧凑的单一文件, 非常**适用于灾难恢复**
             *  RDB在保存RDB文件时父进程唯一需要做的就是**fork出一个子进程**,接下来的**工作**全部由**子进程来做**，父进程不需要再做其他IO操作，所以RDB持久化方式可以**最大化redis的性能**
             *  与AOF相比,在**恢复大的数据集**的时候，**RDB方式会更快一些**
         *  **缺点**
         *   *  如果你希望在**redis意外停止工作**（例如电源中断）的情况下**丢失的数据最少的话**，那么**RDB不适合**，Redis要完整的**保存整个数据集**是一个比较**繁重的工作**
             *  RDB 需要经常fork子进程来保存数据集到硬盘上,当**数据集比较大**的时候,**fork的过程是非常耗时**的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,**AOF**也需要fork,但是你可以**调节重写日志文件的频率来提高数据集的耐久度**
     *  **AOF**
     *   *  **特点**
         *   *  AOF持久化方式记录**每次对服务器写的操作**
             *  redis重启的时候会**优先载入AOF文件**来**恢复原始的数据**,因为在通常情况下**AOF文件保存的数据集**要比**RDB文件**保存的**数据集要完整**
         *  **优点**
         *   *  使用AOF 会让你的Redis**更加耐久**: 你可以使用不同的**fsync策略**：**无fsync,每秒fsync,每次写的时候fsync**
             *  AOF文件是一个只**进行追加的日志文件**,所以不需要写入seek
             *  Redis 可以在 AOF 文件体积**变得过大**时，**自动**地在后台对 **AOF 进行重写**
             *  AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 **AOF 文件的内容**非常**容易被人读懂**， 对文件进行**分析（parse）也很轻松**。 **导出（export） AOF 文件也非常简单**
         *  **缺点**
         *   *  对于**相同的数据集**来说，**AOF 文件的体积**通常要**大于 RDB 文件**的体积
             *  根据所使用的 **fsync** 策略，**AOF 的速度**可能会**慢于 RDB**
     *  **选择**
     *   *  同时使用**两种持久化**功能
 *  **分布式**
 *   *  **Redis Cluster （Redis 3版本）**
     *  **Keepalived**
     *   *  当**Master挂了后**，**VIP漂移到Slave**；**Slave** 上**keepalived 通知redis 执行**：slaveof no one ,开始提供业务
         *  当**Master起来后**，**VIP 地址不变**，**Master**的**keepalived 通知redis 执行slaveof slave IP host**，开始**作为从同步数据**
         *  依次类推
     *  **Twemproxy**
     *   *  **快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法**
         *  对于客户端而言，r**edis集群是透明的，客户端简单，遍于动态扩容**
         *  Proxy为**单点、处理一致性hash**时，集群节点**可用性检测不存在脑裂问题**
         *  **高性能，CPU密集型**，而**redis节点集群多CPU资源冗余，可部署在redis节点集群上，不需要额外设备**
 *  **高可用（HA）**
 *   *  **Redis Sentinel（redis自带的集群管理工具 ）**
     *   *  **监控（Monitoring）**： Redis Sentinel实时监控主服务器和从服务器运行状态
         *  **提醒（Notification）**：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知
         *  **自动故障转移（Automatic failover）**： 当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接到 Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口
     *  **单M-S结构**
     *   *  单M-S结构特点是在Master服务器中配置**Master Redis**（Redis-1M）和**Master Sentinel**（Sentinel-1M）
         *  Slave服务器中配置**Slave Redis**（Redis-1S）和**Slave Sentinel**（Sentinel-1S）
         *  其中 **Master Redis**可以提供**读写**服务，但是**Slave Redis**只能提供**只读**服务。因此，在业务压力比较大的情况下，可以选择将只读业务放在Slave Redis中进行
     *  **双M-S结构**
     *   *  双M-S结构的特点是在**每台服务器**上配置一个**Master Redis**，同时部署一个**Slave Redis**。由两个**Redis Sentinel**同时对**4个Redis进行监控**。**两个Master Redis**可以同时对应用程序提供**读写**服务，即便其中一个服务器出现故障，另一个服务器也可以同时运行两个Master Redis提供读写服务
         *  缺点是**两个Master redis之间无法实现数据共享**，不适合存在大量用户数据关联的应用使用
     *  **单M-S结构和双M-S结构比较**
     *   *  **单M-S结构**适用于**不同用户数据存在关联**，但**应用可以实现读写分离的业务模式**。**Master主要提供写操作，Slave主要提供读操作**，充分利用硬件资源
         *  **双（多）M-S结构**适用于**用户间不存在或者存在较少的数据关联的业务模式**，**读写效率是单M-S的两（多）倍**，但**要求故障时单台服务器能够承担两个Mater Redis的资源需求**
 *  **发布/订阅（Pub/Sub）**
 *  **监控：Redis-Monitor**
 *   *  历史redis运行查询：**CPU、内存、命中率、请求量、主从切换**等
     *  实时监控曲线

**2，数据类型Redis使用场景**

*  **String**
 *   *   **计数器**应用
 *  **List**
 *   *  取**最新N个数据**的操作
     *  **消息队列**
     *  **删除**与**过滤**
     *  **实时分析**正在发生的情况，用于**数据统计**与**防止垃圾邮件**（结合Set）
 *  **Set**
 *   *  **Uniqe**操作，获取某段时间所有数据**排重值**
     *  **实时系统，反垃圾系统**
     *  **共同好友、二度好友**
     *  利用**唯一性**，可以**统计**访问网站的所有**独立 IP**
     *  好友推荐的时候，根据 tag **求交集**，大于某个 threshold 就可以推荐
 *  **Hashes**
 *   *  **存储、读取、修改用户属性**
 *  **Sorted Set**
 *   *  **排行榜**应用，取**TOP N**操作
     *  需要**精准设定过期时间**的应用（时间戳作为Score）
     *  带有**权重**的元素，比如一个游戏的用户得分排行榜
     *  **过期项目处理，按照时间排序**

**3，Redis解决秒杀/抢红包等高并发事务活动**

*  **秒杀开始前30分钟把秒杀库存从数据库同步到Redis Sorted Set**
 *  用户秒杀**库存**放入秒杀限制数长度的**Sorted Set**
 *  秒杀到**指定秒杀数**后，**Sorted Set不在接受秒杀请求，并显示返回标识**
 *  秒杀活动完全结束后，**同步Redis数据到数据库**，秒杀正式结束