修改libtask支持epoll处理大量并发连接
原生的libtask库不支持epoll， 这样无法处理大量并发协程的情况，所以小改了下，让它支持epoll，允许大量并发协程运行。代码在这里libtask_epoll。
修改方法比较简单，就是把epoll_create， epoll_ctl， epoll_wait 几个函数的使用替换掉原来poll相关的函数，diff在这里。 阅读全文...
分类: C/C++, TCP/IP, UNIX/LINUX, 协程
存档
作者存档
memcached 简单get操作处理代码学习
好久没写博客了，这里简单记录一下memcached的get操作处理过程，之前写了些memcached的主体流程/线程框架。get命令相对来说是最简单的了， 主要分为这几步： 读取命令； 解析命令；查找key， 拼接返回数据格式；发送结果给客户端；
分类: Memcached
memcached里面一段神奇，危险，暂且无bug的code： add_iov
翻memcached代码，看到一个函数：add_iov ， 在里面着实纳闷了许久，多次认为这个代码会有问题，于是打日志，gdb上去调试，最后不得不承认： 这代码能work！（不过很危险）
梦想一直都有，总有一天会实现的
高中时就喜欢马云的各种语录，今天阿里上市了，挺高兴的，算是有一点点信念吧，感想敢做，特立独行。
有些人能够实现自己的梦想，有些人却能帮助别人实现梦想。
有一天，我也一定会创业，有自己的产品，帮别人实现梦想。现在我什么也没有，只差一步步去实践了。
禅悟人生：白隐禅师
记得高中启蒙老师李黎上课时总是跑题，本来教数学，讲着讲着就在课堂上讲起了人生，好像那时候我们喜欢他的课也就是他讲故事的原因吧。其中最有印象也最难忘的就是日本白隐禅师的故事了，一直对我影响很大，感触很深。摘录如下： 阅读全文...
分类: 生活杂感
十年后，你会成为怎样的人？
大半的人在20岁或30岁上就死了：一过这个年龄，他们只变了自己的影子；以后的生命不过是用来模仿自己，把以前真正有人味儿的时代所说的，所做的，所想的，所喜欢的，一天天地重复，而且重复的方式越来越机械，越来越脱腔走板。如果你不想重复自己，那你需要不断地改变。—— 罗曼•罗兰 《约翰·克里斯托夫》
memcached源码学习-线程框架
看了看memcached, memcached 主要的线程框架是master-slave的主线程-工作线程模式，单进程，多线程，之间通过管道和链表通信，基本就是这样。
下面具体看下代码。 阅读全文...
libtask协程库实现源码学习-异步I/O
上篇文章写了libtask协程库实现的基本原理，最后说道协程编程一个很大的关键点是，程序员需要知道什么时候应该进行协程切换，什么地方需要异步I/O，什么地方的代码是顺序运行的等。
这里回顾一下具体哪些地方需要做协程切换，异步I/O： 所有可能会造成阻塞的操作，都必须进行异步IO处理，及时切换协程，绝对不能在协程里面做阻塞操作，因为阻塞了大家都阻塞了，就黄了。
顺藤摸瓜，上次的http压力测试小程序里面，协程执行函数fetchtask就是协程运行的主要函数，看下其实现： 阅读全文...
libtask协程库实现源码学习
协程的概念不多说了，轻量级线程，其最大的优势就是协程之间的切换代价非常低，理论上是单线程运行，只是在应用层进行了上下文手动切换。
其最重要的实现函数是makecontext， getcontext， swapcontext 这一组函数，具体的协程上下文切换由他们完成。具体就不多说了，这些函数在glibc里面是已汇编的形式提供的，实际上做的工作就是讲各个寄存器，堆栈指针，指令指针等全部保存起来，或者进行切换，从而达到协程切换的目的。我们知道程序在CPU上运行的时候，注意依赖2个重要的东西： 阅读全文...
人生最值的投资是对未来和理想的坚持
为未来做决定很不容易，至少30%的人会反对你。好决定一般是艰难痛苦的，但痛苦的未必就是好决定。得利者不会表态支持你，受挫者一定会骂。网络时代，最狠的往往是那些毫无利益关系的＂公＂人，他们往往赢得40%不太明白的糊涂人。因为害怕被骂而随波逐流大有人在。人生最值的投资是对未来和理想的坚持！
---转自这里。
分类: 生活杂感
工作又一年了
正好一年前的今天，从百度到唱吧工作，时间过的好快。
一年来做的还有很多不令人满意的地方，可以提高的还很多，再次深深的鄙视自己的执行力。
······(不知道是不是变老了的原因，心里很多话写的时候都觉得没有必要了)
年轻真好，没有那么多羁绊，还有许多的可能
继续好好努力，为了那些不太确定的未来
NAT网络下TCP连接建立时可能SYN包被服务器忽略-tcp_tw_recycle
最近一个长连接服务经常被反馈连接失败，刚开始怀疑是网络问题，也就没有细查。今天仔细抓包分析了一下，原来碰到了在开启tcp_tw_recycle和tcp_timestamps的机器上，当多个客户端使用同一个外网IP( NAT）时可能出现连接建立不成功的坑，具体表现为客户端发送了SYN 包给服务器，服务器也收到了，但就是不回复SYN+ACK 给客户端，从而导致客户端重传SYNC，直至一分钟左右才能成功。
分类: TCP/IP
小心TCP重连时连上了自己-TCP的回环连接
刚才在测试一个服务器跟redis之间的连接自动重连机制时，碰到了个诡异的问题，epoll检测到了连接可用但程序总是不work，并且诡异的是redis被我停掉了，server竟然能够连接上来····
后来netstat -anp | grep 8379 查看了一下原来是server自己连接上了自己··· 阅读全文...
Redis Scan迭代器遍历操作原理（二）–dictScan反向二进制迭代器
续上一篇文章 Redis Scan迭代器遍历操作原理（一）--基础 ，这里着重讲一下dictScan函数的原理，其实也就是redis SCAN操作最有价值（也是最难懂的部分）。
关于这个算法的源头，来自于githup这里：Add SCAN command #579，长篇的讨论，确实难懂····建议看看这帖子，antirez 跟pietern 关于这个奇怪算法的讨论···
这个算法的作者是：Pieter Noordhuis，作者称其为：reverse binary iteration ，不知道我一对一翻译为“反向二进制迭代器”可不可以，不过any way ··作者自己也没有明确的证明其真假： 阅读全文...
Redis Scan迭代器遍历操作原理（一）–基础
Redis在2.8.0版本新增了众望所归的scan操作，从此再也不用担心敲入了keys*, 然后举起双手看着键盘等待漫长的系统卡死了···
命令的官方介绍在这里， 中文版由huangz同学细心翻译了，作者Antirez的介绍在这里：Finally Redis collections are iterable （我又邪恶的想到了之前他那次机器down机的事故了···）。
具体的使用参考上面的链接即可，这里大概介绍一下Scan操作的实现原理。 阅读全文...
Redis从库备份和同步时小概率存在较严重数据错乱的Bug
先说一下影响：在主从模式下的从redis如果开启了定期BGSAVE，并且在做SYNC的时候，可能存在数据错乱的问题，目前2.8.8最新稳定版也存在这个bug。
redis的BGSAVE和slaveof触发的同步操作是互不相关的（对于从库），所以就完全有可能同时在进行备份和同步。看一下下面的代码： 阅读全文...
Redis Slave进行数据备份BGSAVE时可能内存突发跑满
前几天突然线上的redis slave 把64G的内存给占用满了，本来机器上的数据正常只会占用55.5%左右35G的内存的。
查看进程情况，当时redis正好在做BGSAVE操作，所以有2个Redis进程存在，初步怀疑是因为这个原因，但是理论上redis的BGSAVE是fork出来的进程，他们刚开始是共用物理内存的（Redis源码学习-AOF数据持久化原理分析(0)），除非主进程有数据修改，其实就是利用了操作系统的COW机制，巧妙的对redis做了一个数据快照。但明显线上系统不可能短时间内触发大部分数据的修改，所以排除这个的原因。 阅读全文...
近期评论