Hsusan的博客

在⼀个分布式的系统中， 也会涉及到多个节点访问同⼀个公共资源的情况。此时就需要通过 锁 来做互斥控制， 避免出现类似于 “线程安全” 的问题线程安全问题：多个线程并发执行的时候，执行先后顺序是不确定的。就需要保证程序在任意执行顺序下执行逻辑都是OK的⽽ Java 的 synchronized 或者 C++ 的 std::mutex， 这样的锁都是只能在当前进程中⽣效， 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了。此时就需要使⽤到分布式锁。本质上就是使⽤⼀个公共的服务器， 来记录加锁状态。

缓存 (cache) 是计算机中的⼀个经典的概念，在很多场景中都会涉及到。核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅， ⽅便随时读取。举个例⼦：⽐如我需要去⾼铁站坐⾼铁. 我们知道坐⾼铁是需要反复刷⾝份证的 (进⼊⾼铁站， 检票， 上⻋，乘⻋过程中， 出站…)正常来说， 我的⾝份证是放在⽪箱⾥的(⽪箱的存储空间⼤， ⾜够能装). 但是每次刷⾝份证都需要开⼀次⽪箱找⾝份证， 就⾮常不⽅便。因此我就可以把⾝份证先放到⾐服⼝袋⾥。⼝袋虽然空间⼩， 但是访问速度⽐⽪箱快很多。

Redis 作者的答案: https://github.com/antirez/redis/issues/2576。

Redis Sentinel 是⼀个分布式架构，其中包含若⼲个 Sentinel 节点和 Redis 数据节点，每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控，当它发现节点不可达时，会对节点做下线表⽰。Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）加个来解决这个问题。

当从节点正在复制主节点时，如果出现⽹络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区存在数据则直接发送给从节点，这样就可以保持主从节点复制的⼀致性。⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持，如图所⽰。复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写⼊复制积压缓冲区，如图所⽰。

Redis 的事务和 MySQL 的事务概念上是类似的. 都是把⼀系列操作绑定成⼀组. 让这⼀组能够批量执⾏.原子性：把多个操作打包成一个整体了一致性：事务执行之前和之后，数据都不能离谱持久性：事务中做出的修改都会存硬盘隔离性：事务并发执行涉及到的一些问题弱化的原⼦性：redis没有 “回滚机制”，只能做到这些操作 “批量执⾏”，不能做到 “⼀个失败就恢复到初始状态”，也就是不保证全部执行成功，其中有失败的就失败了，不理会。不涉及 “约束”，也没有回滚。

父进程此时继续写这个旧的 aof 文件的意义就是为了避免出现，重写的过程中重写一半服务器挂了，这种情况下子进程内存写的数据就都没了，新的 aof 文件内容还不完整，父进程写的旧的 aof 文件就能保证重启之后数据的完整性了。内存中的数据的状态，已经相当于是把 AOF 文件结果整理后的模样了。dump.rdb 是 RDB 机制生成的镜像文件，Redis 服务器默认就是开启了 RDB 的，这是一个二进制文件，内存中的数据是以压缩的形式保存到这个二进制文件的，这是需要消耗一定的 CPU 资源，但能节省存储空间。

比如我们本身是需要通过 Windows 主机，访问云服务器的 6379 端口，于是就构造一个特殊的 SSH 数据报，把要访问 Redis 的请求放大 SSH 数据报里，这个数据报就会通过 22 端口发送给服务器，服务器的 SSH 服务器程序就能解析出上述的数据报，然后把数据报交给 6379 端口的程序。服务器的响应类型是特定于命令的。，函数式接口，即回调函数，写我们要执行的 redis 命令，这个回调就会被 RedisTemplate 内部进行执行了，在方法内部这么写即可删库，或者其他你想的操作。

时间复杂度：O(log(N)+M)，M 是 [start, stop] 的大小，N 是整个有序集合的元素个数，此处查找位置，只需要查找一次 start 和 stop，因此这部分只是一个 logN。求出给定有序集合中元素的交集并保存进⽬标有序集合中，在合并过程中以元素为单位进⾏合并，元素对应的分数按照不同的聚合⽅式和权重得到新的分数。这样的特定位置，但删除时没有应用这个特性，而是直接调用了一个通用的删除函数，给定一个 member 的值，进行查找，找到位置后再删除。M 是最终结果的有序集合的元素个数.

如果 set1 和 set2 中都有一个 1，此时让 set1 的 1 移动到 set2 中，最终返回值是 1，即移动成功，set1 的 1 不见了，set2 的 1 也还在。注意，由于 set 内的元素是⽆序的，所以取出哪个元素实际是未定义⾏为，即随机删除，这里是真随机，而不是伪随机。这里的无序，是指变换一下元素的顺序，集合还是一样的集合，而不是说顺序逆序的无序。获取⼀个 set 的基数（cardinality），即 set 中的元素个数。获取⼀个 set 中的所有元素，注意，元素间的顺序是⽆序的。

如图 2-23 所⽰，Redis 同样使⽤ lpush + brpop 命令，但通过不同的键模拟频道的概念，不同的消费者可以通过 brpop 不同的键值，实现订阅不同频道的理念。列表类型是⽤来存储多个有序的字符串，如图 2-19 所⽰，a、b、c、d、e 五个元素从左到右组成了⼀个有序的列表，列表中的每个字符串称为元素（element），⼀个列表最多可以存储。brpop 这样的命令设定就能实现一个“轮询”的效果，先执行 brpop 的消费者先拿到 lpush 进入列表的元素，后执行的后拿到下一个。

哈希类型中的映射关系通常称为 field-value（里层value），⽤于区分 Redis 整体的键值对（key-value（外层value）），注意这⾥的 value 是指 field（可以理解为，这个 field 就是 外层value 里的 key，这里的 value 是 里层value）对应的值，不是键（key）对应的值，请注意 value 在不同上下⽂的作⽤。缺点：占⽤过多的键，内存占⽤量较⼤，同时⽤⼾信息在 Redis 中⽐较分散，缺少内聚性，所以这种⽅案基本没有实⽤性。避免“牵一发动全身”

字符串类型是 Redis 最基础的数据类型，关于字符串需要特别注意：1）⾸先 Redis 中所有的键的类型都是字符串类型，⽽且其他⼏种数据结构也都是在字符串类似基础上构建的，例如列表和集合的元素类型是字符串类型，所以字符串类型能为其他 4 种数据结构的学习奠定基础。以上介绍了使⽤ Redis 的字符串数据类型可以使⽤的⼏个场景，但其适⽤场景远不⽌于此，开发⼈员可以结合字符串类型的特点以及提供的命令，充分发挥⾃⼰的想象⼒，在⾃⼰的业务中去找到合适的场景去使⽤ Redis 的字符串类型。可以使⽤负数表⽰倒数。

目录Redis 常⻅数据类型预备知识基本全局命令小结数据结构和内部编码单线程架构引出单线程模型为什么单线程还能这么快Redis 常⻅数据类型Redis 提供了 5 种数据结构，理解每种数据结构的特点对于 Redis 开发运维⾮常重要，同时掌握每种数据结构的常⻅命令，会在使⽤ Redis 的时候做到游刃有余。本章内容如下：预备知识：⼏个全局（generic）命令，数据结构和内部编码，单线程模式机制分析。5 种数据结构的特点、命令使⽤、应⽤场景⽰例。键遍历、数据库管理。预备知识在正式介绍 5

的⻆度，数据分为热数据和冷数据，热数据通常是指需要频繁操作的数据，反之为冷数据，例如对于视频⽹站来说，视频基本信息基本上在各个业务线都是经常要操作的数据，⽽⽤⼾的观看记录不⼀定是经常需要访问的数据，这⾥暂且不讨论两者数据规模的差异，单纯站在数据冷热的⻆度上看，视频信息属于热数据，⽤⼾观看记录属于冷数据。排⾏榜系统⼏乎存在于所有的⽹站，例如按照热度排名的排⾏榜，按照发布时间的排⾏榜，按照各种复杂维度计算出的排⾏榜，Redis 提供了列表和有序集合的结构，合理地使⽤这些数据结构可以很⽅便地构建各种排⾏榜系统。

在进⾏技术学习过程中，由于⼤部分读者没有经历过⼀些中⼤型系统的实际经验，导致⽆法从全局理解⼀些概念，所以本⽂以⼀个 “电⼦商务” 应⽤为例，介绍从⼀百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让⼤家对架构的演进有⼀个整体的认知，⽅便⼤家对后续知识做深⼊学习时有⼀定的整体视野。