Codis架构笔记

Codis是起源于豌豆荚的redis Proxy项目,其主要目的是为了解决redis使用中的两个痛点:

  1. 难以动态的平行扩展增加新的redis服务.
  2. 难以运维管理.

它主要的架构是这样的:

系统扩展的三种维度

经常提到一个系统的扩展性,只谈到垂直扩展和水平扩展,其中垂直扩展是提高系统内单个系统的处理能力,比如给机器加内存,换性能更高的机器等;水平扩展通俗一点说就是加更多的机器来处理请求,而不是试图提高单机的处理能力.

<<可扩展的艺术>>一书,将一个系统的可扩展性做了更多的划分和分析,它将一个系统的扩展性划分为以下三种维度:

No Comments »

灰度发布系统的实现(续)

上周写完灰度发布系统相关的博文之后,有朋友表示灰度系统的实现太过简单了,因为我目前接触的系统确实比较简单,很多复杂的东西没有考虑周全,如果更大型的业务系统,涉及到的服务更多,还有如果掺杂着数据的迁移,就更复杂了.这里就把当时讨论的内容提取出来,主要的贡献者为滴滴的沈佳伟.

1.调用链上有多个业务服务的场景

考虑这样一个业务场景,假设对外提供了服务A给客户端访问,服务A后面会调用服务B,C,D,此时需要上线一个功能,这个功能涉及到了服务A,C的修改,但是服务B,D不需要变动,换言之,我们的意图是,如果一个客户端请求,走到了新的灰度服务A,那么最终这个请求也应该走到这次和A一起灰度的服务C上.

这里的处理策略,可以给客户端请求进行tag打标记的方式,比如经由新版本服务A处理的请求,全部打上tag

灰度发布系统的实现

灰度发布,已经不是一个很新的概念了.一个产品,如果需要快速迭代开发上线,又要保证质量,保证刚上线的系统,一旦出现问题那么可以很快的控制影响面,就需要设计一套灰度发布系统.

灰度发布系统的作用在于,可以根据自己的配置,来将用户的流量导到新上线的系统上,来快速验证新的功能修改,而一旦出问题,也可以马上的恢复,简单的说,就是一套A/BTest系统.

它大抵的架构,应该是类似这样的:

Paxos原理与实现(二)实现与实践篇

上一部分描述了Paxos算法的原理,这部分根据 MIT 6.824 lab3 的内容,展开来讨论一下Paxos算法实现的过程中遇到的问题,以及如何将它运用到一个实际的K-V系统中.
我把这部分代码放在了github上.
这个实验包括两部分,第一部分是实现一个Paxos算法库,第二部分是基于这个Paxos库实现一个KV存储系统.

新申请了微信公众号

赶一赶时髦,开通了微信公众号,会同步一些这个博客的文章到上面去,公众号名字是”codedumpnote”.

Paxos原理与实现(一)原理篇

几年之前学习zookeeper的时候,就断续的学习过Paxos算法,对其中的原理和如何运用到实际环境中一知半解似懂非懂,以至于后面断断续续又花了不少时间在这上面,每一次的返工都没有达到自己想要的效果.直到最近,开始做

再谈同步/异步与阻塞/非阻塞

几年前写过一篇描写同步/异步以及阻塞/非阻塞的文章,今天回头来看bug不少,于是需要重新整理一下原来的描述.

同步/异步
首先来解释同步和异步的概念,这两个概念与消息的通知机制有关.

实现了一个协程库

C\C++实现的协程库已经不少了,最近自己也实现了一个.

与大多数协程库不同的是,这个协程库实现的思路是”非侵入式”的,简而言之,使用者不用include相应的头文件,只需要在编译链接的时候链接这个库就好了.

这个协程库中hook了几个网络编程中常用的可能会阻塞I/O操作的API:read,send,accept,在这几个API调用时,进入库本身hook的调用,在它们里面将所要操作的socket加入epoll中,然后让出协程的执行权,在主协程中通过epoll调用之后知道是哪个socket可用了然后再唤醒相应的协程继续操作.同时还hook了pthread_create函数,在创建线程的时候实际上也是创建出一个协程来操作.

库里面做这些,无非是为了对使用者透明:实际上用的是协程,但是使用起来没什么感觉.

代码放在这里:

简单的基于DFA的正则表达式引擎

最近做了一个很简单的正则表达式引擎,能支持*,|和字符连接,目的是动手写点东西熟悉一下编译里面的一些原理.

龙书中将解析正则表达式库分为两种办法:
1)将正则转换为NFA,然后NFA再转换成对应的DFA
2)将正则转换为抽象语法树,再将抽象语法书转换成DFA.

我这里用的第2种方式,第1种等我有空了再补上吧.

大体说一下流程,分为以下几步:
1)自下而上的构建抽象语法树

Pages: 1 2 3 4 5 6 7 8 9 Next