趁着年轻

最近工作中需要用到数据库热备，虽然MYISAM表比较过时了，但是其索引性能还是有很大诱惑力的。

关于MYISAM表的备份，相对Innodb简单多了，因为其把表格式文件，数据文件，索引文件分开存放，容易管理。

表结构存放在**.frm , 数据文件在.MYD，索引文件在.MYI，关于数据库的索引 实现原理可以参考这篇文章，写的不错。

MYISAM表的备份简单来说就是拷贝走上面三类文件，但是之前需要保证着数据库内容已经完整写入到文件中，避免不一致的情况，所以在拷贝之前必须对表加读锁，阻塞写操作。 阅读全文...

前几天东政同学反馈说Linode服务器快卡死了，今天有时间排查了一下具体原因，最终原因稍微有点悲壮：file_get_contents没有设置超时时间，加上我用的php5.2关于curl的代码有个bug，于是导致PHP进程进入死循环。

今天下午又发现系统负载很高，于是上去看了一下，发现一大坨PHP进程没有退出，占用了很多CPU，如图： 阅读全文...

自从工作后就开始喜欢看服务器的日志滚动，尤其是半夜三更，大家都睡着了，然后扫扫服务器上的日志看看有没有什么异常。

然后安心的睡觉，似乎这样睡得更香。第二天早上上班，第一件事就是看监控数据，每天期待着Qps能涨点，最欢乐的还有机器实在抗不住了，得加机器的场景。 阅读全文...

前几天Google Reader终于竟然还是关闭了. 虽然还是有许多不错的替代品，比如Feedly，还有一些Alternatives，国内的也有网易云阅读等。但是我的需求如下： 阅读全文...

字典和hash表的实现都大同小异，所以简单说一下不同点。

0.概要

redis的字典是使用hash表实现的，相同hash值的key保存在list中，也就是index= hash(key)， index代表了key所在的数组下标，也就是槽位。查找操作找到槽位后，需要遍历下面的链表的元素去查找对应的key。插入操作将新key插入到链表的头部。 阅读全文...

一篇很老的文章了，原文只找到了这个，很有感触所以转载分享。二次转载文章如下：

转载此文的原因无怪乎很感慨，因我认识的多数娃都是此文中所谓的精英。

facebook, twitter自然稀松平常，iphone, Thinkpad, macbook pro的普及率也不要太高。精英们在做的，就是紧跟国际最新技术潮流，讨论的不是Android开发就是iphone平台，做咨询必去麦肯锡，进投行必进摩根士坦利，搞IT非IBM，Microsoft等500强不去，对银行IT均嗤之以鼻。 阅读全文...

继上面一篇文章“Redis源码学习-AOF数据持久化原理分析(0)”，介绍了Redis是如何将不断从客户端发送过来的数据持久化到AOF文件中的。这里介绍一下AOF rewrite是如何工作的，也就是redis是如何将AOF文件初始化，并后台自动AOF rewrite的。 阅读全文...

Redis作为一个使用广泛的KV内存存储，其也支持一定的数据持久化，这里试着介绍一下Redis在源码层面对持久化的实现机制。

总的来说，Redis支持的将其数据库里面的KV数据存储到磁盘，但可能会有短时间的丢失。官网关于持久化的介绍可以参考这里“Redis Persistence”,这篇文章介绍一下其在代码层面的实现。

其支持2中不同的持久化机制：

1. 第一种RDB数据快照持久化。RDB持久化实际上就是对数据库内容做快照，然后将快照存储到磁盘上面，这样就要去我们进行周期性的做快照，但是这种方式无法做到实时的存储，出现故障时只能恢复上一次做快照时的状态，因此比较有限。不过redis的主从同步也是利用RDB实现的，这个我们后续文章分析；
2. 第二种AOF日志实时持久化。AOF=Append Only File，也就是不断追加写的文件。在这种情况下，Redis首先将数据库做个快照，将数据还原为跟客户端的协议格式的文本数据，然后将其存储到一个临时文件中，然后将其覆盖成正常的aof文件，并把这个过程中新增的命令追加到aof文件后面，从此之后，后续的从客户端过来的命令都会不断根据不同的安全级别写到磁盘里面去。这样就支持了实时的持久化，只是可能会有短时间内的数据丢失，对一般系统还是可以容忍的。

下面一步步介绍其实现的原理。 阅读全文...

走出校园快2年了，最近有点闲暇时间便想了一些空洞的东西，关于我想要什么。 阅读全文...

弄个博客，给自己一点学习，分享的动力，下面记录一下这个博客的由来，有的曲折。

阅读全文...

上篇文章“Nginx upstream原理分析【1】给后端FastCGI发送数据”讲到了给PHP等FCGI程序发送数据了，也就是ngx_http_upstream_send_request函数，下面接着写。

ngx_http_upstream_send_request调用输出的过滤器，发送数据到后端，前面已经介绍过，ngx_http_proxy_create_request函数会将客户端发送过来的HEADER，以及body部分的数据组成一块块的FCGI协议的buffer，放到u->request_bufs成员上面，因此在发送数据的时候，就需要吧这块数据发送给后端的PHP或者其他模块。send_request函数完成的任务有如下几个：

1. 连接状态诊断，调用ngx_http_upstream_test_connect();
2. 调用ngx_output_chain函数将需要发送的数据发送出去(不一定真的发送出了，可能留在缓冲链表里面)；
3. 设置定时器send_timeout，ngx_tcp_push标志位等；
4. 如果连接可读，则调用ngx_http_upstream_process_header()尝试读取FCGI的返回数据。

下面分2部分介绍这个函数： 阅读全文...

在前一篇文章“Nginx upstream原理分析【1】新连接的处理过程”中我们介绍了一个连接从accept到ngx_http_core_run_phases过程处理所发生的事情，后面剩下的就是FCGI的相关处理了，留在这里进行介绍。

0、写在前面的话

ngx_http_core_run_phases函数会不断调用cmcf->phase_engine.handlers上面的checker，从而调用rewrite模块，find_config模块等的函数进行相应的处理，对于我们今天要介绍的FCGI模块的处理，其checker调用的是ngx_http_core_content_phase，后者调用了ngx_http_fastcgi_handler进行相关的处理。 阅读全文...

在上一篇“Nginx upstream原理分析【0】指令解析”中介绍了nginx对于upstream的指令解析，初始化的逻辑。这里介绍一个请求从一开始到后面是怎么处理的。

0、Accept接收新连接：

首先，nginx在ngx_init_cycle解析完配置后，就已经打开了所有的监听端口，然后会调用各个进程初始化函数，这样event模块的进程初始化函数为ngx_event_process_init，这个函数会将所有的listening端口结构跟ngx_connection_t结构进行关联，互相指向，并且为这个连接注册了读写监控事件，这个事件的句柄正式：ngx_event_accept函数，这样，当listen端口有新连接到来的时候会调用ngx_event_accept函数。

下面来简单看一下ngx_event_accept函数的逻辑，函数首先循环最多5次调用accept（）系统函数去接收这个连接，并计算一下本进程的负载，来进行简单的负载均衡： 阅读全文...

熟悉nginx的同学都知道upstream的重要作用，当nginx接收到一个连接后，读取完客户端发送出来的Header，然后就会进行各个处理过程的调用。

之后就是upstream发挥作用的时候了，upstream在客户端跟后端比如FCGI/PHP之间，接收客户端的HTTP body，发送给FCGI，然后接收FCGI的结果，发送给客户端。作为一个桥梁的作用。同时，upstream为了充分显示其灵活性，至于后端具体是什么协议，什么系统他都不care，我只实现主体的框架，具体到FCGI协议的发送，接收，解析，这些都交给后面的插件来处理，比如有fastcgi,memcached,proxy等插件，我之前也做过一个简单的跟公司内部系统的module，其实他们都是一种回调形式的模块，跟upstream模块配合从而完成整个请求。如无特殊说明，后面都已FCGI作为后端模块为例说明。 阅读全文...

之前介绍过Nginx的FCGI模块，upstream模块的解析，今晚扫了一下mecached模块的代码，下面记录一下。

总的来说，mecached 模块是继proxy模块外的一个很简单的content模块了，非常简单，就500多行代码，也没有处理一次发送多个KEY给mecached的情况，也没有像FCGI那样做buffering处理，这样mecached返回一点点数据，nginx就发送一点数据给客户端，比较简单。

阅读全文...

上一篇Nginx upstream原理分析【2】-带buffering读取upstream数据 我们介绍了nginx在带buffering的情况下是如何读取FCGI数据的，这里我们介绍他是怎么给客户端返回数据的。

从上篇文章我们知道ngx_event_pipe这个函数一句参数不同，既可以读取upstream数据，也可以给客户端返回数据。其调用的功能函数分别为：ngx_event_pipe_read_upstream 和ngx_event_pipe_write_to_downstream。nginx读取upstream的数据后，会把数据放在p->in链表里面，当然如果缓存不够等原因，写入了磁盘的话，nginx总是将p->in的前面部分写入磁盘，因此会记录在p->out链表上面。在发送时就围绕这2个成员进行了。
发送数据时，客户端的连接结构存放在p->downstream。先来看一下缓存结构：
阅读全文...

上篇文章Nginx upstream原理分析【1】-无缓冲模式发送数据 讲到了nginx upstream在不带buffer的情况下，是如何接收upstream数据然后把它们发送给客户端的。这里讲一下带缓存的情况下nginx是怎么巧妙的完成这一任务的。

回到ngx_http_upstream_send_response函数，这个函数发送请求数据给客户端。里面会分别发送header,body，这个在上篇文章已经介绍过了，对于FCGI这种带buffering的数据处理，这里nginx是用所谓的event_pipe方式处理的，pipe为管子的意思，顾名思义就是读写事件的管道。

其所有的处理都集中在ngx_event_pipe_s这个结构体上，结构体包含指向upstream连接，指向客户端的连接的指针，以及尽心各个缓冲区管理的指针，还有input_filter、output_filter等函数回调，以及一堆标志位。这里先看一下这个结构的内容：
阅读全文...

前阵子学习了一下nginx 关于接收upstream的数据，然后发送给客户端的过程，总结一下。

下面的许多注释等是在upstream后面是FCGI协议而介绍的，比如nginx连接后端php-fpm的情况下。nginx接收到客户端的header数据后会调用各个处理过程，也就是ngx_http_core_content_phase，该过程会不断调用各个阶段（phrase）的回调函数，依次进行配置解析，重定向，访问控制，内容处理等过程。

在内容处理的回调ngx_http_core_content_phase()中，会调用ngx_http_fastcgi_handler，请求由后者接管。

nginx中关于upstream经常围绕在ngx_http_upstream_s上面，这上面包括各种缓冲区数据，回调等，所以先看一下ngx_http_upstream_s结构的内容，具体含义注释下面了。

阅读全文...

今天花了点时间学习nginx rewrite模块的代码，其跟脚本解析是紧密相连的。
老毛病，贴个代码，以后补图，脑袋快撑不住了····
其他注释的代码在这里：https://github.com/kulv2012/ReadNginxSrc 阅读全文...

nginx的配置文件功能是相当强大的，之前了解了其主体执行流程，配置文件加载等，今天学习了一下其脚本解析的原理等，写了点注释放下面。
目前没写什么描述代码了，快趴下了，得睡觉去···
其他注释的代码在这里：https://github.com/kulv2012/ReadNginxSrc
最近比较忙，过段时间用grahpviz画个图吧
阅读全文...