橙子wj的博客

1 研究背景分布式缓存是各大公司业务系统必不可少的组件，目前市面上开源的分布式缓存解决方案主要有redis cluster和codis，在进行了一系列调研之后，redis cluster现阶段的模块耦合使得我最后放弃了这一方案，转向了codis。在使用过程中，发现了一些codis的不足之处。因此笔者在官方codis的基础上（基于最新版本3.2.2），修改了源码，做出了codisX。先说一下...

Topom.ha.monitor本身相当于一个上帝视角的sentinel。它本身并不是一个实际的sentinel服务器，但是它负责收集各个sentinel的监控信息，并对集群作出反馈。这一讲我们就来看看Topom.ha.monitor。下面参数中的servers []string就是添加的sentinel的ip:port所组成的字符串数组，有多少个sentinel，数组的长度就有多少func (s

sentinel是redis集群高可用的保障。怎么搭建sentinel，网上有很多教程，我们这里就不重复了。 添加sentinel的过程很简单。新建sentinel，调用sentinel flushconfig强制 sentinel 重写所有配置信息到配置文件，然后更新ctx.sentinel和zk上存储的信息。但是刚刚添加sentinel的OutOfSync属性默认为true，也就是说，此时与集

我们在java项目里面连接已经搭建好的Codis集群时，需要用到其java客户端——Jodis。这一篇我们就来看看Jodis是如何操作对Codis集群进行操作的。import io.codis.jodis.JedisResourcePool;import io.codis.jodis.RoundRobinJedisPool;import redis.clients.jedis.Jedi...

在Codis源码解析——proxy监听redis请求一篇中，我们介绍过，SharedBackendConn负责实际对redis请求进行处理。上一篇，在fillslot的过程中通过codis-server地址获取SharedBackendConn是这样用的slot.backend.bc = s.pool.primary.Retain(addr)为了弄清这个方法的实现，首先我们要搞清楚，基本原理是，从p

这一篇我们把处理slot操作的机制讲完。还剩最后两个部分。一个是fillSlot，一个是每一个槽具体的处理方式。本例中有两个group，将之前auto-rebalance过的slot（0-511属于group1,512-1023属于group2）现在将slot 400到500移动到group2。我们之前走到了s.newProxyClient(p).FillSlots(ctx.toSlotSlice(

上一篇我们讲了slot在集群中的分配方式，重点讲了auto-rebalance的原理。之前我们说过，再启动dashboard的时候，有一个goroutine专门用来处理slot的操作。这一篇我们就来看看slot的操作是如何进行的。我们这里举例也是用集群中有两个group和1024个从未分配的slot。首先复习一下，在slot还处于未分配状态的时候，上下文中的1024个SlotMapping如下所示。

上一篇我们给codis集群中添加了codis-server，接下来就是把1024个slot分配给每个codis-server。Codis给我们提供了多种方式，可以将指定序号的slot移到某个group，也可以将一个group中的多少个slot移动到另一个group。不过最方便的方式就是通过自动rebalance。首先看一下Slot的结构，可以看到，每个Slot都分配了其所属的BackendAd...

上一篇，我们成功在集群中添加了proxy。这一篇来讲讲codis-server添加到集群的过程中发生了什么。第一步，先别急着添加server，而应该是创建分组。创建分组的过程很简单，主要就是校验group的id在不在1~9999这个范围内，如果在的话（以group1为例），就调用zkClient创建路径/codis3/codis-wujiang/group/group-0001，初识创建好的时候，这

先把代码贴上来import io.codis.jodis.JedisResourcePool;import io.codis.jodis.RoundRobinJedisPool;import redis.clients.jedis.Jedis;/** * @author wujiang * @version 1.0.0 * @date 2017/7/12 */public class

前面我们说过，proxy启动之后，会默认处于 waiting 状态，以一秒一次的频率刷新状态，监听proxy_addr 地址（默认配置文件中的19000端口），但是不会 accept 连接，通过fe或者命令行添加到集群并完成集群状态的同步，才能改变状态为online。那么，将proxy添加到集群的过程中发生了什么？这一篇我们就来看看。通过界面添加比较简单，直接输入fe的地址即可主要调用的方法在/pk

虽然dashboard负责对集群的实际操作，但是用户的最直观操作，都是来自于fe的。这一节我们就来讲fe的启动，没有proxy和dashboard那么复杂。首先，启动的时候指定fe的监听端口，这个就是我们最后通过浏览器打开fe的端口--listen=0.0.0.0:18090然后根据系统参数找到assets文件夹目录，再在这个目录下寻找index.html，没错，就是浏览器中看到的html。如果在本

首先认识两个重要的structtype Future struct { sync.Mutex wait sync.WaitGroup vmap map[string]interface{}}type RedisStats struct { //储存了集群中Redis服务器的各种信息和统计数值，详见redis的info命令 Stats map[string]

dashboard是codis的集群管理工具，支持proxy和server的添加、删除、数据迁移，所有对集群的操作必须通过dashboard。dashboard的启动过程和proxy类似。dashboard的启动只是初始化一些必要的数据结构，复杂的在于对集群的操作，这个日后的文章会有详细的描述，本文先不管这些。启动的时候，首先读取配置文件，填充config信息。根据coordinator的信息，如果

笔者之前在云主机上启动codis，这次是在本地启动。dashboard，proxy，fe都成功启动之后，打开 fe 的页面，点击最左侧自己创建的product_name，却发现页面显示残缺不全再看fe的控制台日志，发现报错http : proxy error : dial tcp : lookup cnsz22vla888.novalocal on 127.0.1.1:5

上一篇我们讲到，pkg/proxy/proxy.go的构造函数中，传入Config，返回Proxy。其中有一步是//s是Proxygo s.serveProxy()接到一个redis请求，就创建一个独立的session进行处理。这里的第一个参数是net.Conn，Conn是一个通用的面向流的网络连接，多个goroutines可以同时调用Conn的方法。这里的net.Conn就是我们之前Proxy的

proxy启动的时候，首先检查输入的命令行，一般情况下，启动proxy的命令如下：nohup ./bin/codis-proxy --ncpu=2 --config=./conf/proxy.conf --log=./logs/proxy.log --log-level=WARN &程序会解析这行命令参数，下面举个例子（实例代码是cmd/proxy/main.go），有关于go的并行，这里要特别说明