m0_74099572的博客

这里介绍的只是一个简单的“互斥锁”。这里对redis的学习就告一段落了，如果还想继续深入学习redis可以阅读redis的源码。

哨兵 模式, 提⾼了系统的可⽤性. 但是真正⽤来存储数据的还是 master 和 slave 节点. 所有的数据都需要存储在单个 master 和 slave 节点中.如果数据量很⼤, 接近超出了 master / slave 所在机器的物理内存, 就可能出现严重问题了虽然硬件价格在不断降低, ⼀些中⼤⼚的服务器内存已经可以达到 TB 级别了, 但是 1TB 在当前这个 "⼤数据" 时代, 俨然不算什么, 有的时候我们确实需要更⼤的内存空间来保存更多的数据。

我们这里为了演示3个redis-server，3个哨兵节点，本来应该是在6台机器上的，但是我们这里只有一台云服务器来完成这里的环境搭建。在实际工作上，把上述节点放在一个服务器上是没有意义的。由于这些节点比较多，依赖的端口号/配置文件/数据文件都避免冲突，当然如果在不同的主机上配置就比较容易了，在一个主机上的话可以使用docker来解决这个问题。首先为什么要使用docker？我们都知道虚拟机这个东西，它是通过 软件，在电脑上模拟出一些另外的硬件环境，就相当于构造了另一个电脑。

Redis的事务要比MySQL要简单很多。1.弱原子性：Redis 事务不支持回滚。2.不保证一致性：Redis并不会保证事务执行前和执行后的内容是统一的。3.没有持久化：Redis本身就是在内存中存储数据的，这里的事务与持久化无关。4.不存在隔离性：Redis作为单线程的服务器模型，处理请求本质就是串行执行的。

RDB 是⼀个紧凑压缩的⼆进制⽂件，代表 Redis 在某个时间点上的数据快照。⾮常适⽤于备份，全量复制等场景。⽐如每 6 ⼩时执⾏ bgsave 备份，并把 RDB ⽂件复制到远程机器或者⽂件系统中如 （hdfs）⽤于灾备。•Redis 加载 RDB 恢复数据远远快于 AOF 的⽅式。•RDB ⽅式数据没办法做到实时持久化 / 秒级持久化。因为 bgsave 每次运⾏都要执⾏ fork 创建⼦进程，属于重量级操作，频繁执⾏成本过⾼。•。

我们之前的学习都是通过Redis自带的命令行式的客户端来使用Redis的，我们在执行命令的时候，都是手动执行的。然而这种操作方式并不是日常开发的主要形式。更多的时候，是使用Redis的api来实现定制化的Redis客户端程序，进一步来操作服务器。虽然还有些带有图形化界面的客户端，它们的本质跟命令行式的客户端一样，都是通用性质的，在工作中还是会更希望用到专用的，定制化的客户端程序。

我们之前已经学过了Redis最常用的五个类型了，然而Redis还有一些在特定场景下比较好用的类型Redis最关键的五个数据类型：上面的类型是非常常用，很重要的类型。除此之外的其他类型不常用，只是在特定的场景能够发挥用处，所以这里只是做简单描述与介绍。

有序集合相对于字符串、列表、哈希、集合来说会有⼀些陌⽣。它保留了集合不能有重复成员的特点，但与集合不同的是，有序集合中的每个元素都有⼀个唯⼀的浮点类型的分数（score）与之关联，着使得有序集合中的元素是可以维护有序性的，但这个有序不是⽤下标作为排序依据⽽是⽤这个分数。注意：在有序集合这里，有序指的是升序，而不是顺序，这里的概念与集合那里是不一样的。简单对比以下list set zset。

列表类型 list 相当于 数组或者顺序表list内部的编码方式更接近于 双端队列 ，支持头插 头删 尾插 尾删。需要注意的是，Redis的下标支持负数下标。 比如数组大小为5，那么要访问下标为 -2 的值可以理解为访问 5 - 2 = 3Redis中的数据是有序的，但是注意这里的有序不是指排序数组中的升序或者降序，而是指数据的顺序很关键。比如把元素位置调换之后，得到的新的list与原来的list是不等价的。同样的一个词在不同的上下文中，它的意义可能是不一样的。比如同步这个词在 线程之间和IO之间的意义就不

⼏乎所有的主流编程语⾔都提供了哈希（hash）类型，它们的叫法可能是哈希、字典、关联数组、映射。在 Redis 中，哈希类型是指值本⾝⼜是⼀个键值对结构，形如 key = "key"，value = { {注意：哈希类型中的映射关系通常称为 field-value，⽤于区分 Redis 整体的键值对（key-value），注意这⾥的 value 是指 field 对应的值，不是键（key）对应的值，请注意 value 在不同上下⽂的作⽤。

这是Redis中两个最为核心的命令。set插入这里的key 和 value都是字符串，我们可以加双引号 或者单引号，或者不加。get查找如果查询的key值不存在，那么会返回一个 nil ，也就是代表空在Redis中命令是不区分大小写的。这就是Redis最核心的命令和它俩的使用方法了，看起来就像是一个网络版的hash map一样。这也是Redis的一个优势，使用简单 学习成本低。

之前说了单机架构模式， 还有服务器的核心资源。当某一时刻，请求的数量太多了，就可能会导致服务器的某个硬件资源不够用了，无论是哪个方面不够用了，都会导致服务器处理请求的时间变长，甚至出错。如果碰到这种情况，怎么处理呢？1.开源：简单粗暴，直接增加更多的硬件资源来解决性能问题。但是需要注意：一台主机能增加的硬件资源是有限的。比如CPU ，内存条，这些取决于主板的扩展能力。当一台主机扩展到极限的时候，那么就只能引入多台主机了。而且不是说新的机器买来就可以直接解决问题，还需要在软件上做出对应的调整和适配。