解决金字塔回调问题的两种手段

javascript确实是一门在设计和使用上与主流语言上有着很多区别的语言,但一点也不妨碍她成为一门优雅的语言.
但是习惯了顺序执行的coder(指我自己)使用javascript的异步操作容易产生金字塔回调的问题(无止尽的回调套回调).最常见的就是按顺序异步操作.

ajax(url1, function(){
    ajax(url2, function(){
        ...
    });
});

之前遇到这个问题时,我想到了小时候玩的多米诺骨牌,确保前一个倒下能推到自己,自己倒下以后能推到后面一个.(以jQuery的自定义事件方式实现).


- 阅读剩余部分 -

为nginx日志加入上游响应时间

生产环境发现一个请求报了超时.查询应用日志在收到请求后1秒内就做出了响应;查看nginx访问日志发现那笔请求状态为499,经查是因为请求端等待超时主动掐断连接.由于之前nginx只记录了默认的访问日志格式,所以无法排查究竟是是否为上游超时.为了找到问题原因遂需要记录一下上游的响应时间:

配置如下:
1.定义新的日志格式(在默认格式之后加上请求/响应时间,管道)

log_format access '$remote_addr - $remote_user [$time_local]  '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '$request_time $upstream_response_time $pipe';

2.重新配置日志格式

access_log logs/access.log access;

等待问题重现后即可排查

mysql无符号整型溢出

下午用sql的时候突然想到这个问题,徒手测试了一下,结果还真令人意外:

首先创建一张测试用表

mysql> CREATE TABLE `t1` (
-> `id`  int UNSIGNED NOT NULL AUTO_INCREMENT ,
-> `val`  int UNSIGNED NOT NULL DEFAULT 0 ,
-> PRIMARY KEY (`id`)
-> );
Query OK, 0 rows affected (0.04 sec)

- 阅读剩余部分 -

php持久化连接数据库

php的持久化数据库连接已经不是一个新鲜的名词了,由于php语言生命周期的问题,如果每次连接数据库都重新打开一个连接会很低效,所以引入了长连接机制(应该是实现在sapi部分,例如cli sapi就不支持db长连接),本文探究apache2handler sapi和 fpm sapi是否支持db长连接.使用方法以pdo为例在实例化pdo对象时传入:

PDO::ATTR_PERSISTENT => true

即可实现长连接,但是隐约在哪里听说过在apache下由于是以线程的方式执行,所以连接在线程关闭时也会释放掉.本着实践是检验真理的唯一标准态度,遂决定做个实验测试下.

- 阅读剩余部分 -