前几天碰到碰到一个线上redis CPU跑满的情况，基本无法处理正常请求了，刚开始以为是其他地方的问题，后来grep "Max open files" /proc/`pidof redis-server`/ -r 排查原来是启动redis的时候。ulimit -n 只有1024，从而无法接受新连接。
晚高峰时段段时间突发的大量请求导致某个时候redis连接数超过1024，从而listen sock 持续可读并且accept失败，从而CPU跑满，进而导致更严重的雪崩。 阅读全文...
不知不觉又在北京飘了一年，寻找了一年，摸索了一年。
待会就拖着行李踏上回家的火车了，难免回想起这一年的路程。不多，2件事：1.离开百度；2.去了唱吧；
离开百度是因为心里迫切的想做一些让自己心动的事情，所以去了唱吧；结果还好，算是没选错路，只是路上，还得努力。
脑子突然进水了，闪现了些连自己也听起来没道理的想法：
有些时候我们认为Ridiculous的事情很可能是因为我们这个level的人不懂，不懂用户，不懂另一批人的思维，比如我不懂我弟弟一样。
毕竟我们生活在不同的圈子，不同的学历，必然有不同的思维和价值观。但是··· 阅读全文...
没事碰到了librtmp库，这个库是ffmpeg的依赖库，用来接收，发布RTMP协议格式的数据。
代码在这里：git clone git://git.ffmpeg.org/rtmpdump
先看一段通过librtmp.so库下载RTMP源发布的数据的例子，从rtmpdump中抽取出来。使用的大体流程如下：
这是标题党，
下面是鸡汤，请忽略。
Mosquitto是一个IBM 开源pub/sub订阅发布协议MQTT的一个单机版实现（目前也只有单机版），MQTT主打轻便，比较适用于移动设备等上面，花费流量少，解析代价低。相对于XMPP等来说，简单许多。
MQTT采用二进制协议，而不是XMPP的XML协议，所以一般消息甚至只需要花费2个字节的大小就可以交换信息了，对于移动开发比较有优势。
IBM虽然开源了其MQTT消息协议，但是却没有开源其RSMB服务端程序，不过还好目前有比较稳定的实现可用，本文的Mosquitto是其中比较活跃的实现之一，具体在这里有目前的实现列表可供选择。
趁着大脑还没有进入睡眠状态记录一下刚才看代码学到的东西。我下载的版本是1.2.2版，在这里可以找到下载链接。 阅读全文...
今天在看MQTT协议文档，到处关于QoS（Quality of Service）的介绍，文档说如果没有收到对方的PUBREL等确认包，超时后server需要'delivery retry"， 一开始觉得理所当然的，重发嘛，丢包，正常。
然后就看到消息重发（Message delivery retry）这一章：
4.2. Message delivery retry
Although TCP normally guarantees delivery of packets, there are certain scenarios where an MQTT message may not be received. In the case of MQTT messages that expect a response (QoS >0 PUBLISH, PUBREL, SUBSCRIBE, UNSUBSCRIBE), if the response is not received within a certain time period, the sender may retry delivery. The sender should set the DUP flag on the message.
占个坑，贝叶斯进行垃圾邮件过滤方法简单，效果也挺明显的。基本能满足一般需求。具体算法不多说，google即可。
贝叶斯在线上使用的准确性其实严重依靠人工的调整的，需要进行巧妙的调整才能极大的提高降低误判率。
下面贴个代码，从其他地方考过来改吧改吧的。 阅读全文...
前面的2篇文章分别介绍了Redis主从同步源码浅析-Master端 以及 Redis主从同步源码浅析-Slave端 相关的代码实现，从中我们可以看出redis主从同步的一个最大的缺点，也是阻碍大数据应用的地方便是其每次连接端开都需要重连master进行全量数据的重新同步，这个代价是可想而知的。
长连接断开在线上环境中出现得很频繁，如果需要重新同步所有RDB文件，几十G的文件，从建立RDB快照，发送文件内容到slave，然后slave执行命令一一加载进内存中，这个时间开销估计也得好几个小时，更别说树形结构的master->slave->slave， 对网卡的压力，对服务器的压力都是很恐怖的。从这方面来说，动辄几个小时甚至一天的修复时间，没人敢用Redis主从同步在生产环境中使用。
但是福音来了：即将（2013年第三季度）发布的2.8版本会解决这个问题，通过：Replication partial resynchronization 的方式，也就是部分重新同步，这里就说部分同步吧，注意不是常规情况下的新写入指令同步。 阅读全文...
前一篇文章写了下redis主从同步的server端代码，这里补一下slave端的。
简单来讲，看了master端就知道slave端的代码大概流程了：
下面分别介绍这些步骤。 阅读全文...
关于Redis的主从同步的基本介绍这里有:Replication, 不多介绍了。本文只涉及到主库的代码，从库的相关代码改天补上。
这里主要介绍redis 2.6.13版本代码，目前2.8新增了一些功能，比如增量同步功能等，不过到目前2013-10-05还没有正式上线。总结一下几点跟下面相关的：
总体来说，redis的同步原理是：slave启动时下载所有数据快照，下载快照过程中产生的新写操作日志会不断累积记录起来，发送完快照后就发送这部分增量日志，日志在slave端进行重放。下面分步讲。 阅读全文...
spawn-fcgi是一个小程序，作用是管理fast-cgi进程，功能和php-fpm类似，简单小巧，原先是属于lighttpd的一部分，后来由于使用比较广泛，所以就迁移出来作为独立项目了，本文介绍的是这个版本“spawn-fcgi-1.6.3”。不过从发布新版本到目前已经4年了，代码一直没有变动，需求少，基本满足了。另外php有php-fpm后，码农们再也不担心跑不起FCGI了。
很久之前看的spawn-fcgi的代码，当时因为需要改一下里面的环境变量。今天翻代码看到了就顺手记录一下，就当沉淀.备忘吧。 阅读全文...
HTTP 的Content-Range支持对于一般的网页处理没啥重要的作用，但是对于大文件的下载，CDN回源，点续传功能的作用是非常重要的。
Content-Range允许一次只下载一个文件的一部分，后面再分批次下载文件的其他部分，或者并发下载，提高下载速度，这样如果在下载一个文件的过程中，网络断开了，恢复后不需要重新下载。
nginx 对Content-Range的支持包括header处理和body处理，分别用来解析客户端发送过来的Range header 和裁剪返回给客户端的请求数据Body。其实现分别由2个filter过滤模块完成，分别是ngx_http_range_header_filter_module和ngx_http_range_body_filter_module。下面分别介绍。 阅读全文...
随便记录一点杂感，比如如何对待用户，需求等，很杂乱的思维。 阅读全文...
回顾一下之前看的redis代码，脑子内存比较小，一会就忘了，所以备忘一下。
redis主体流程比较简单，init,listen, accept, read, write,基本就是这几步。下面简单介绍一下，当做备忘。 阅读全文...
最近接触到开源搜索引擎Solr,碰了不少坑，在这里备忘一下，了解有限，仅供个人学习···
关于服务搭建等就不多说了，网上一大堆，这里记录一下一些容易出问题的地方等。
我用的是solr-4.3.1.tgz，貌似现在已经是4.4版本了，下载地址这里有，在使用Solr的时候一定注意版本问题，由于他是基于Lurance的，所以难免不断的跟着Lurance改动代码，也就导致某些模块上下不兼容。
solr有本专门介绍的书：《Solr 1.4 Enterprise Search Server》下面记录一些使用的小方法。 阅读全文...
最近需要用XtraBackup进行mysql数据备份，Gaojie同学推荐的工具，效果还不错，推荐。
详细的介绍请移步上面的链接去官网查看，官网介绍的很清楚了，这里只是就一些容易总结和容易犯的错误等。如果确定数据库的表全部是myisam的表，那就可以简单用“mysql数据热备份脚本-MYISAM表”里的方法做文件备份了，简单的东西总是"更简单可依赖"。
XtraBackup包含2个主要的部分：C程序xtrabackup， perl包装代码innobackupex ， 实际上后者调用了前者，提供一些包装的功能。因为xtrabackup只支持Innodb表，所以innobackupex 额外提供备份myisam表的能力。下面会说一下其原理
阅读全文...
近期评论