redis源码修改（修改redis数据）

本文目录一览：

• 1、redis maxclients可以改到多大
• 2、ubuntu下怎样源码安装redis
• 3、如何高效深入的阅读Redis的源码
• 4、windows怎么调试redis源码
• 5、如何实现高可用的 redis 集群

redis maxclients可以改到多大

可以设置无限大:redis.conf中maxclients 设置为0表示不作限制.

但是redis maxclients  会受到到其他影响,影响最大连接数.

1、其实你是受到了redis的file descriptor数目限制，这个需要更改redis的源码，在ae.h的36行（2.2.4版本）：

#define AE_SETSIZE (1024*10)    /* Max number of fd supported */

2、另外需要注意的是，如果你需要支持更高的连接数，还需要更改系统的相关配置，比如ulimit数目：

ulimit -n xxx(你需要的数目)

以及网络的并发连接数等限制：

net.ipv4.netfilter.ip_conntrack_max

net.nf_conntrack_max

net.netfilter.nf_conntrack_max

ubuntu下怎样源码安装redis

进入先前解压后得到的文件夹（我的在/usr/redis），复制配置文件redis.conf到/etc/redis/下，并用vi命令编辑该文件，将“daemonize no”修改为“daemonize yes”，即设置成作为后台进程运行，修改完成后保存退出。

如何高效深入的阅读Redis的源码

在这篇文章中， 我将向大家介绍一种我认为比较合理的 Redis 源码阅读顺序， 希望可以给对 Redis 有兴趣并打算阅读 Redis 源码的朋友带来一点帮助。

第 1 步：阅读数据结构实现

刚开始阅读 Redis 源码的时候， 最好从数据结构的相关文件开始读起， 因为这些文件和 Redis 中的其他部分耦合最少， 并且这些文件所实现的数据结构在大部分算法书上都可以了解到， 所以从这些文件开始读是最轻松的、难度也是最低的。

下表列出了 Redis 源码中， 各个数据结构的实现文件：

文件 内容

sds.h 和 sds.c Redis 的动态字符串实现。

adlist.h 和 adlist.c Redis 的双端链表实现。

dict.h 和 dict.c Redis 的字典实现。

redis.h 中的 zskiplist 结构和 zskiplistNode 结构， 以及 t_zset.c 中所有以 zsl 开头的函数， 比如 zslCreate 、 zslInsert 、 zslDeleteNode ，等等。 Redis 的跳跃表实现。

hyperloglog.c 中的 hllhdr 结构， 以及所有以 hll 开头的函数。 Redis 的 HyperLogLog 实现。

第 2 步：阅读内存编码数据结构实现

在阅读完和数据结构有关的文件之后， 接下来就应该阅读内存编码（encoding）数据结构了。

和普通的数据结构一样， 内存编码数据结构基本上是独立的， 不和其他模块耦合， 但是区别在于：

上一步要读的数据结构， 比如双端链表、字典、HyperLogLog， 在算法书上或者相关的论文上都可以找到资料介绍。

而内存编码数据结构却不容易找到相关的资料， 因为这些数据结构都是 Redis 为了节约内存而专门开发出来的， 换句话说， 这些数据结构都是特制（adhoc）的， 除了 Redis 源码中的文档之外， 基本上找不到其他资料来了解这些特制的数据结构。

不过话又说回来， 虽然内存编码数据结构是 Redis 特制的， 但它们基本都和内存分配、指针操作、位操作这些底层的东西有关， 读者只要认真阅读源码中的文档， 并在有需要时， 画图来分析这些数据结构， 那么要完全理解这些内存编码数据结构的运作原理并不难， 当然这需要花一些功夫。

下表展示了 Redis 源码中， 各个内存编码数据结构的实现文件：

文件 内容

intset.h 和 intset.c 整数集合（intset）数据结构。

ziplist.h 和 ziplist.c 压缩列表（zip list）数据结构。

第 3 步：阅读数据类型实现

在完成以上两个阅读步骤之后， 我们就读完了 Redis 六种不同类型的键（字符串、散列、列表、集合、有序集合、HyperLogLog）的所有底层实现结构了。

接下来， 为了知道 Redis 是如何通过以上提到的数据结构来实现不同类型的键， 我们需要阅读实现各个数据类型的文件， 以及 Redis 的对象系统文件， 这些文件包括：

文件 内容

object.c Redis 的对象（类型）系统实现。

t_string.c 字符串键的实现。

t_list.c 列表键的实现。

t_hash.c 散列键的实现。

t_set.c 集合键的实现。

t_zset.c 中除 zsl 开头的函数之外的所有函数。 有序集合键的实现。

hyperloglog.c 中所有以 pf 开头的函数。 HyperLogLog 键的实现。

第 4 步：阅读数据库实现相关代码

在读完了 Redis 使用所有底层数据结构， 以及 Redis 是如何使用这些数据结构来实现不同类型的键之后， 我们就可以开始阅读 Redis 里面和数据库有关的代码了， 它们分别是：

文件 内容

redis.h 文件中的 redisDb 结构， 以及 db.c 文件。 Redis 的数据库实现。

notify.c Redis 的数据库通知功能实现代码。

rdb.h 和 rdb.c Redis 的 RDB 持久化实现代码。

aof.c Redis 的 AOF 持久化实现代码。

选读

Redis 有一些独立的功能模块， 这些模块可以在完成第 4 步之后阅读， 它们包括：

文件 内容

redis.h 文件的 pubsubPattern 结构，以及 pubsub.c 文件。 发布与订阅功能的实现。

redis.h 文件的 multiState 结构以及 multiCmd 结构， multi.c 文件。 事务功能的实现。

sort.c SORT 命令的实现。

bitops.c GETBIT 、 SETBIT 等二进制位操作命令的实现。

第 5 步：阅读客户端和服务器的相关代码

在阅读完数据库实现代码， 以及 RDB 和 AOF 两种持久化的代码之后， 我们可以开始阅读客户端和 Redis 服务器本身的实现代码， 和这些代码有关的文件是：

文件 内容

ae.c ，以及任意一个 ae_*.c 文件（取决于你所使用的多路复用库）。 Redis 的事件处理器实现（基于 Reactor 模式）。

networking.c Redis 的网络连接库，负责发送命令回复和接受命令请求， 同时也负责创建/销毁客户端， 以及通信协议分析等工作。

redis.h 和 redis.c 中和单机 Redis 服务器有关的部分。 单机 Redis 服务器的实现。

如果读者能完成以上 5 个阅读步骤的话， 那么恭喜你， 你已经了解了单机的 Redis 服务器是怎样处理命令请求和返回命令回复， 以及是 Redis 怎样操作数据库的了， 这是 Redis 最重要的部分， 也是之后继续阅读多机功能的基础。

选读

Redis 有一些独立的功能模块， 这些模块可以在完成第 5 步之后阅读， 它们包括：

文件 内容

scripting.c Lua 脚本功能的实现。

slowlog.c 慢查询功能的实现。

monitor.c 监视器功能的实现。

第 6 步：阅读多机功能的实现

在弄懂了 Redis 的单机服务器是怎样运作的之后， 就可以开始阅读 Redis 多机功能的实现代码了， 和这些功能有关的文件为：

文件 内容

replication.c 复制功能的实现代码。

sentinel.c Redis Sentinel 的实现代码。

cluster.c Redis 集群的实现代码。

注意， 因为 Redis Sentinel 用到了复制功能的代码， 而集群又用到了复制和 Redis Sentinel 的代码， 所以在阅读这三个模块的时候， 记得先阅读复制模块， 然后阅读 Sentinel 模块， 最后才阅读集群模块， 这样理解起来就会更得心应手。

如果你连这三个模块都读完了的话， 那么恭喜你， 你已经读完了 Redis 单机功能和多机功能的所有代码了！

下图总结了本文介绍的阅读顺序：

digraph {

node [shape = plaintext]

datastruct [label = "数据结构\n（sds、adlist、dict、t_zset、hyperloglog）"]

encoding_datastruct [label = "内存编码数据结构\n（intset、ziplist）"]

object [label = "数据类型\n（object、t_string、t_list、t_hash、t_set、t_zset、hyperloglog）"]

db [label = "数据库相关\n（db、notify、rdb、aof）"]

client_and_server [label = "客户端与服务器相关\n（ae、networking、redis）"]

multi_server [label = "多机功能\n（replication、sentinel、cluster）"]

//

datastruct - encoding_datastruct - object - db - client_and_server - multi_server

}

结语

Redis 的设计非常简洁、优美、精巧和高效， 任何人只要愿意去阅读它的代码的话， 应该都会有所收获的。

希望这篇文章能够给想要阅读 Redis 代码的朋友们带来一些帮助， 也欢迎各位随时和我讨论 Redis 源码方面的问题， 或者跟我分享各位阅读 Redis 源码的心得和经验。

另外我的 Redis 源码注释 项目以及 《Redis 设计与实现》 一书对于理解 Redis 的源代码应该也会有所帮助， 有兴趣的朋友可以自行了解该项目/书本。

黄健宏（huangz）

2014.7.28

windows怎么调试redis源码

Redis对于Linux是官方支持的,安装和使用没有什么好说的,普通使用按照官方指导，5分钟以内就能搞定。详情请参考:

但有时候又想在windows下折腾下Redis,可以从redis下载页面看到如下提示(在页面中搜索 "windows")：

[plain] view plain copy

Win64 Unofficial The Redis project does not directly support Windows,

however the Microsoft Open Tech group develops and maintains

an Windows port targeting Win64.

大意就是 Redis官方是不支持windows的，只是 Microsoft Open Tech group 在 GitHub上开发了一个Win64的版本,项目地址是：

打开以后，可以直接使用浏览器下载，或者Git克隆。

可以在项目主页右边找到 zip包下载地址:

(注意: dist文件改变了下载地址: )

如何实现高可用的 redis 集群

Redis 因具有丰富的数据结构和超高的性能以及简单的协议，使其能够很好的作为数据库的上游缓存层。但在大规模的 Redis 使用过程中，会受限于多个方面：单机内存有限、带宽压力、单点问题、不能动态扩容等。

基于以上， Redis 集群方案显得尤为重要。通常有 3 个途径：官方 Redis Cluster ；通过 Proxy 分片；客户端分片 (Smart Client) 。以上三种方案各有利弊。

Redis Cluster( 官方 ) ：虽然正式版发布已经有一年多的时间，但还缺乏最佳实践；对协议进行了较大修改，导致主流客户端也并非都已支持，部分支持的客户端也没有经过大规模生产环境的验证；无中心化设计使整个系统高度耦合，导致很难对业务进行无痛的升级。

Proxy ：现在很多主流的 Redis 集群都会使用 Proxy 方式，例如早已开源的 Codis 。这种方案有很多优点，因为支持原声 redis 协议，所以客户端不需要升级，对业务比较友好。并且升级相对平滑，可以起多个 Proxy 后，逐个进行升级。但是缺点是，因为会多一次跳转，平均会有 30% 左右的性能开销。而且因为原生客户端是无法一次绑定多个 Proxy ，连接的 Proxy 如果挂了还是需要人工参与。除非类似 Smart Client 一样封装原有客户端，支持重连到其他 Proxy ，但这也就带来了客户端分片方式的一些缺点。并且虽然 Proxy 可以使用多个，并且可以动态增加 proxy 增加性能，但是所有客户端都是共用所有 proxy ，那么一些异常的服务有可能影响到其他服务。为每个服务独立搭建 proxy ，也会给部署带来额外的工作。

而我们选择了第三种方案，客户端分片 (Smart Client) 。客户端分片相比 Proxy 拥有更好的性能，及更低的延迟。当然也有缺点，就是升级需要重启客户端，而且我们需要维护多个语言的版本，但我们更爱高性能。

下面我们来介绍一下我们的Redis集群：

概貌：

如图0所示，

我们的 Redis 集群一共由四个角色组成:

Zookeeper ：保存所有 redis 集群的实例地址， redis 实例按照约定在特定路径写入自身地址，客户端根据这个约定查找 redis 实例地址，进行读写。

Redis 实例：我们修改了 redis 源码，当 redis 启动或主从切换时，按照约定自动把地址写到 zookeeper 特定路径上。

Sentinel ： redis 自带的主从切换工具，我们通过 sentinel 实现集群高可用。

客户端（ Smart Client ）：客户端通过约定查找 redis 实例在 ZooKeeper 中写入的地址。并且根据集群的 group 数，进行一致性哈希计算，确定 key 唯一落入的 group ，随后对这个 group 的主库进行操作。客户端会在Z ooKeeper 设置监视，当某个 group 的主库发生变化时，Z ooKeeper 会主动通知客户端，客户端会更新对应 group 的最新主库。

我们的Redis 集群是以业务为单位进行划分的，不同业务使用不同集群（即业务和集群是一对一关系）。一个 Redis 集群会由多个 group 组成 ( 一个 group 由一个主从对 redis 实例组成 ) 。即 group 越多，可以部署在更多的机器上，可利用的内存、带宽也会更多。在图0中，这个业务使用的 redis 集群由 2 个 group 组成，每个 group 由一对主从实例组成。

Failover

如图1所示，

当 redis 启动时，会 把自己的 IP:Port 写入到 ZooKeeper 中。其中的 主实例模式启动时会在 /redis/ 业务名 / 组名 永久节点写入自己的 IP:Port （如果节点不存在则创建）。由 主模式 变成 从模式 时，会创建 /redis/ 业务名 / 组名 /slaves/ip:port 临时节 点，并写入自己的 IP:Port （如果相同节点已经存在，则先删除，再创建）。而从实例 模式 启动时会创建 /redis/ 业务名 / 组名 /slaves/ip:port 临时节点，并写入自己的 ip:port （如果相同节点已经存在，则先删除，再创建）。由 从模式 变成 主模式 时，先删除 /redis/ 业务名 / 组名 /slaves/ip:port 临时节点，并在 /redis/ 业务名 / 组名 永久节点写入自己的 IP:Port 。

ZooKeeper 会一直保存当前有效的 主从实例 IP:Port 信息。至于主从自动切换过程，使用 redis 自带的 sentinel 实现，现设置为超过 30s 主 server 无响应，则由 sentinel 进行主从实例的切换，切换后就会触发以主、从实例通过以上提到的一系列动作，从而完成最终的切换。

而客户端侧通过给定业务名下的所有 groupName 进行一致性哈希计算，确定 key 落入哪个组。 客户端启动时，会从 ZooKeeper 获取指定业务名下所有 group 的 主从 IP:Port ，并在 ZooKeeper 中设置监视（监视的作用是当 ZooKeeper 的节点发生变化时，会主动通知客户端）。若客户端从 Zookeeper 收到节点变化通知，会重新获取最新的 主从 I:Port ，并重新设置监视（ ZooKeeper 监视是一次性的）。通过此方法，客户端可以实时获知当前可访问最新的 主从 IP:Port 信息。

因为我们的所有 redis 实例信息都按照约定保存在 ZooKeeper 上，所以不需要针对每个实例部署监控，我们编写了一个可以自动通过 ZooKeeper 获取所有 redis 实例信息，并且监控 cpu 、 qps 、内存、主从延迟、主从切换、连接数等的工具。

发展：

现在 redis 集群在某些业务内存需求超过预期很多后，无法通过动态扩容进行扩展。所以我们正在做动态扩容的支持。原先的客户端我们是通过一致性哈希进行 key 的

路由策略，但这种方式在动态扩容时会略显复杂，所以我们决定采用实现起来相对简单的预分片方式。一致性哈希的好处是可以无限扩容，而预分片则不是。预分片

时我们会在初始化阶段指定一个集群的所有分片数量，这个数量一旦指定就不能再做改变，这个预分片数量就是后续可以扩容到最大的 redis 实例数。假设预分片 128 个 slot ，每个实例 10G 也可以达到 TB 级别的集群，对于未来数据增长很大的集群我们可以预分片 1024 ，基本可以满足所有大容量内存需求了。

原先我们的 redis 集群有四种角色， Smart Client, redis ， sentinel ， ZooKeeper 。为了支持动态扩容，我们增加了一个角色， redis_cluster_manager （以下简称 manager ），用于管理 redis 集群。主要工作是初始化集群（即预分片），增加实例后负责修改Z ooKeeper 状态，待客户端做好准备后迁移数据到新增实例上。为了尽量减少数据迁移期间对现性能带来的影响，我们每次只会迁移一个分片的数据，待迁移完成，再进行下一个分片的迁移。

如图2所示

相比原先的方案，多了 slots 、M anager Lock 、 clients 、M igrating Clients 节点。

Slots: 所有分片会把自身信息写入到 slots 节点下面。 Manager 在初始化集群时，根据设置的分片数，以及集群下的 group 数，进行预分片操作，把所有分片均匀分配给已有 group 。分片的信息由一个 json 串组成，记录有分片的状态 (stats) ，当前拥有此分片的 group(src) ，需要迁移到的 group(dst) 。分片的状态一共有三种： online 、 pre_migrate 、 migrating 。

Online 指这个分片处于正常状态，这时 dst 是空值，客户端根据 src 的 group 进行读写。

Pre_migrate 是指这个分片被 manager 标记为需要迁移，此时 dst 仍然为空， manager 在等所有 client 都已经准备就绪，因为 ZooKeeper 回掉所有客户端有时间差，所以如果某些 client 没有准备就绪的时候 manager 进行了数据迁移，那么就会有数据丢失。

Migrating 是 manager 确认了所有客户端都已经做好迁移准备后，在 dst 写入此分片需要迁移的目标 group 。待迁移完成，会在 src 写入目标 group_name ， dst 设为空， stats 设为 online 。

Manager Lock： 因为我们是每次只允许迁移一个 slot ，所以不允许超过一个 manager 操作一个集群。所以 manager 在操作集群前，会在M anager Lock 下注册临时节点，代表这个集群已经有 manager 在操作了，这样其他 manager 想要操作这个集群时就会自动退出。

Clients 和M igrating Clients 是为了让 manager 知道客户端是否已经准备就绪的节点。客户端通过 uid 代表自己，格式是 客户端语言 _ 主机名 _pid 。当集群没有进行迁移，即所有分片都是 online 的时候，客户端会在 clients 下创建 uid 的临时节点。

当某个 slot 从 online 变成 pre_migrate 后，客户端会删除 clients 下的 uid 临时节点，然后在M igrating Clients 创建 uid 临时节点。注意，因为需要保证数据不丢失，从 pre_migrate 到 migrating 期间，这个 slot 是被锁定的，即所有对这个 slot 的读写都会被阻塞。所以 mananger 会最多等待 10s ，确认所有客户端都已经切换到准备就绪状态，如果发现某个客户端一直未准备就绪，那么 mananger 会放弃此次迁移，把 slot 状态由 pre_migrate 改为 online 。如果客户端发现 slot 状态由 pre_migrate 变成 online 了，那么会删除 migrating_clients 下的 uid 节点，在 clients 下重新创建 uid 节点。还需要注意的一点是，有可能一个客户刚启动，并且正在往 clients 下创建 uid 节点，但是因为网络延迟还没创建完成，导致 manager 未确认到这个 client 是否准备就绪，所以 mananger 把 slot 改为 pre_migrate 后会等待 1s 再确认所有客户端是否准备就绪。

如果 Manager 看到 clients 下已经没有客户端的话（都已经准备就绪），会把 slot 状态改为 migrating 。 Slot 变成 migrating 后，锁定也随之解除， manager 会遍历 src group 的数据，把对应 slot 的数据迁移到 dst group 里。客户端在 migrating 期间如果有读写 migrating slot 的 key ，那么客户端会先把这个 key 从 src group 迁移到 dst group ，然后再做读写操作。即这期间客户端性能会有所下降。这也是为什么每次只迁移一个 slot 的原因。这样即使只有 128 个分片的集群，在迁移期间受到性能影响的 key 也只有 1/128 ，是可以接受的。

Manager 发现已经把 slot 已经迁移完毕了，会在 src 写入目标 group_name ， dst 设为空， stats 设为 online 。客户端也删除 migrating_clients 下的 uid ，在 clients 下创建 uid 节点。