Weakyon Blog

对于C/S模型而言，传统的请求和回复是这样的

1
2
3
4
5
6

req ------------->
    <------------- rsp
req ------------->
    <------------- rsp
req ------------->
    <------------- rsp

而pipeline模式是这样的

1
2
3
4
5
6
7
8
9
10

req1 ------------->
req2 ------------->
req3 ------------->
req4 ------------->
    <------------- rsp1
req5 ------------->
    <------------- rsp2
    <------------- rsp3
req6 ------------->
    <------------- rsp4

pipeline模式下的客户端可以狂吐数据，而不用等待服务端回复，服务端会按顺序返回rsp。

为了提高代码质量，在同事的帮助下学习了如何使用gtest进行单元测试

准备工作

1 首先从googlecode上下载gtest的源码（googlecode明年一月即将关闭不知道这个项目会何去何从呢）

解压后参考README文件进行编译

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

GTEST_TARGET=googletest ./travis.sh
GTEST_TARGET=googlemock ./travis.sh
```  

此时目录下会生成一个build目录，代码的单元测试依赖的就是这个目录里的静态库文件

2 安装lcov

一般yum即可安装，如果不行的话，那就下载安装

这里不用编译，直接make install即可

```c  
wget http://downloads.sourceforge.net/ltp/lcov-1.11.tar.gz
tar xvf lcov-1.11.tar.gz
cd lcov-1.11
make install

首先这个问题相当小白，如果已经了解的同学看到这个标题应该就明白了，就能略过不看了。

我遇到这个问题是对改造的twemproxy做异常测试时出现的。

首先简介一下改造的多进程版本的twemproxy原理。

改造的twemproxy会连接zk去获取一些信息，建立监视使得后端redis掉线(使用一个watchdog来将redis注册到zookeeper上)能够通过zookeeper被通知到。

而后才会fork出子进程，主进程当获取到zookeeper的watch消息后，会通过管道来通知子进程去连接此时正常的redis。

经常能看到线上的服务器报出超时，除了自己代码的问题，因为网络环境导致超时的原因是各种各样的：

硬件上：各层交换机微突发；芯片转发；链路，网卡阻塞等等

软件上：在负载较高的情况下，KVM之类的虚拟化性能更不上（同一宿主机的两台KVM虚拟机压测时会报出大量超时）；

网络导致的超时，简单的可以用ping -f来观察，但是有些细微的超时，需要借助更加细微的工具来发现

我遇到的网络问题，大部分情况下都能使用下面的代码测试验证

内存方面的知识真是博大精深，把一些看到的零碎的知识点做个笔记总结下。

这些知识只是自己的理解，并不能保证正确，ULK和《深入理解Linux虚拟内存管理》这两本书看完以后还会来更新这篇的内容。

段式管理与页式管理

在操作系统理论中

gitcafe创建项目

配置域名

继如何创建这样一个blog这一篇已经过去快一年了。

然而最近遇到一个新的问题，各大搜索引擎毫无流量。因此写了文章后，除了几个朋友以外也没人看。

内存管理有两篇文章讲的还是满清晰的：

操作系统学习笔记-储存管理

The Linux Kernel-Chapter 3 Memory Management

下面这本书是有不少中文翻译的，可以自行查找

本文主要是讨论伙伴算法的，讲伙伴算法的文章虽然多，但是没几篇讲的很清楚的。我也是结合了几篇文章看了好久才弄明白，特地记下来。

业务线上出错，返回给用户的结果不正确。

使用了ZINTERSTORE这个接口对多个集合做交并集返回预期外的空集。如下图：

这是因为twemproxy只是把指令转发给redis而已，而多个集合被哈希算法分片在不同的redis节点上，所以转发这个redis并没有这几个集合，会直接返回空集。

这并不是BUG，redis3.0也存在这个特性，当多个集合做交并集操作时，需要使用hash_tag特性。

由于twemproxy的多进程改造计划，所以对教科书一般的nginx的管理方式做了分析

nginx的-s指令可以对进程执行多个命令。

这些命令由主进程接受信号然后在循环中对状态进行判断，然后通过unix socket或者信号的方式传达给子进程。

从代码里面可以看到如下状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

for()
{
    if (delay) {}
    sigsuspend();
    ngx_time_update();
    if (ngx_reap) {} //需要重启工作进程
    if (!live && (ngx_terminate || ngx_quit)) {} //工作进程都结束，自己也设定了结束，那么退出
    if (ngx_terminate) {} //强制退出状态
    if (ngx_quit) {} //优雅退出状态
    if (ngx_reconfigure) {} //配置热加载
    if (ngx_restart) {} //重启(配置不变)
    if (ngx_reopen) {} //重新打开日志
    if (ngx_change_binary) {} //二进制文件改变
    if (ngx_noaccept) {} //不再接受新连接
}

twemproxy的多进程改造计划中参考了nginx的设计，然而nginx有一段让我看不太明白。

这篇文章总结的很好

sigsuspend sigprocmask函数的使用方法

sigsuspend将新的信号集阻塞操作和pause操作组合在一起成为原子操作

做了以下的操作