数据库

恭谢啦～这是深入理解 Redis 常用数据类型源码及底层实现系列的最后一篇～由于前面的铺垫，对于大多数知识不会重复赘述，感兴趣的朋友可以移步到如下文章(￣∇￣)🎉～ 【Redis】深入理解 Redis

分类 不同类型的日志文件可以用来存储不同类型的信息，一般来讲MySQL的日志可以分为如下6种： 慢查询日志 记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化 通用查

在使用I/O多路复用之前，最简单典型的处理并发多客户端连接的方案就是**同步阻塞网络I○模型** 简单来讲就是用一个进程来处理一个网络连接/用户请求（来一个new一个）

上一篇我们介绍了Redis的Hash数据结构的源码及底层实现（感兴趣的朋友可以移步 【Redis】深入理解 Redis 常用数据类型源码及底层实现(4.详解Hash数据结构)），这篇我们继续List~

接着之前的SDS结构，这篇我们开始介绍Hash结构(￣∇￣)/🎉 Hash数据结构 看过前面的介绍，大家应该知道 Redis 的 Hash 结构的底层实现在 6 和 7 是不同的

从这篇开始，我们结合源码依次解析下String、Hash、List、Set、ZSet这五大数据结构，先看下object.c中各个类型的数据结构的编码映射和定义

为了便于操作，Redis采用了`redisObject`结构来统一5种不同的数据类型（下图绿色部分），这样所有的数据类型就可以以相同的形式在函数间传递而不用使用特定的类型结构。

在Redis的逻辑中，服务（redisServer）启动加载数据库（redisDb），然后去读取字典（dict），然后去找哈希（dictht），就像Java中的那句——一切皆对象，在Redis中一切皆

复制带来的问题 主机（master）能读能写，从机（slave）只能读 无论主机已经写了多少数据，从机一旦启动，就会全部复制过来，后续主机写，从机跟 配置文件🆚命令配置 使用配置文件进行主从配置时，如

一致性哈希算法分区 是什么 一致性Hash算法背景 一致性哈希算法在1997年由麻省理工学院中提出的，设计目标是为了解决分布式缓存数据变动和映射问题（当服务器个数发生变动时，尽量减少影响客户端到服务器

什么是集群 官网地址 https://redis.io/docs/reference/cluster-spec/ 由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平

为什么Redis的槽数是16384？ Redis集群并没有使用一致性hash而是引入了哈希槽的概念。 Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置那个槽

上一篇我们介绍了复制，正是由于复制的痛点，于是产生了哨兵（sentinel） 什么是哨兵 哨兵会巡查监控后台master主机，查看是否存在故障，如果故障了，就会根据投票数自动将某一个从库转换为新主库，

什么是Redis的复制 官网地址: https://redis.io/docs/management/replication/ 其实就是主从复制，master以写为主，slave以读为主 当maste