idea's blog

# explain select * from t1 where user_ip=123 limit 1;
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table       | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | t1 | ALL  | user_ip       | NULL | NULL    | NULL |  262 | Using where |
+----+-------------+-------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

# explain select * from t1 where user_ip='123' limit 1;
+----+-------------+-------------+------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table       | type | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-------------+------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | t1 | ref  | user_ip       | user_ip | 47      | const |    1 | Using where |
+----+-------------+-------------+------+---------------+---------+---------+-------+------+-------------+
1 row in set (0.01 sec)

可以看到, user_ip 字段是 varchar 类型. 查询时, 如果这个字段的值没有加引号, MySQL 就不会使用索引. MySQL 为什么会有这种致命的策略?!

----- 更新: -----

相关的文档已经找到: http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html, 这里面提到和几种类型转换的情况, 字符串和数字比较都被统一转成浮点数再比较.

这是关于 C1000K 序列文章的第二篇, 在前一篇文章 构建C1000K的服务器(1) – 基础 中, 介绍了支持 C1000K 的 Linux 系统的内核参数调整和系统设置. 在本篇文章中, 将对一个真正的应用服务器做 C1000K 测试.

Comet 服务器是一类逻辑相对简单, 需要高并发连接的服务器. Comet 在网站系统中的应用非常广泛, 可以见这篇日志的介绍: http://www.ideawu.net/blog/archives/737.html.

HTTP 协议处理

要开发一个支持百万并发连接的 Comet 服务器, 我选择 C/C++ 语言, 当然还有其它的选择如 Erlang, Java 等. 对于一个只支持 long-polling Comet 服务器, 首先要具备解析 HTTP 协议的能力, 我选择 libevent 来处理 HTTP 协议.

Continue reading »

著名的 C10K 问题提出的时候, 正是 2001 年, 到如今 12 年后的 2013 年, C10K 已经不是问题了, 任何一个普通的程序员, 都能利用手边的语言和库, 轻松地写出 C10K 的服务器. 这既得益于软件的进步, 也得益于硬件性能的提高.

现在, 该是考虑 C1000K, 也就是百万连接的问题的时候了. 像 Twitter, weibo, Facebook 这些网站, 它们的同时在线用户有上千万, 同时又希望消息能接近实时地推送给用户, 这就需要服务器能维持和上千万用户的 TCP 网络连接, 虽然可以使用成百上千台服务器来支撑这么多用户, 但如果每台服务器能支持一百万连接(C1000K), 那么只需要十台服务器.

有很多技术声称能解决 C1000K 问题, 例如 Erlang, Java NIO 等等, 不过, 我们应该首先弄明白, 什么因素限制了 C1000K 问题的解决. 主要是这几点:

1. 操作系统能否支持百万连接?
2. 操作系统维持百万连接需要多少内存?
3. 应用程序维持百万连接需要多少内存?
4. 百万连接的吞吐量是否超过了网络限制?

Continue reading »

Comet 技术就是常见的 Web 服务器"推"技术, 用于向网页实时地推送数据. 最常见的 Comet 技术应用在网页聊天, 当然还可以应用于很多的方面, 如微博更新, 热点新闻推送, 股票即时行情等等, 甚至是网页游戏!

Comet 技术如此重要, 但市面上并没有真正流行通用的 Comet 服务器和解决方案, 比较知名的互联网公司大多是自己开发, 或者基于开源服务器进行二次开发, 例如基于 Jetty(一个开源 Java Web 容器), 而 Facebook 的聊天系统的 Comet 服务器是基于 Mochiweb(一个开源的 Erlang Web 服务器).

当然还有比较知名的以 nginx 模块形式出现的 nginx-push-stream, 但根据实际使用经验, 这个模块无法稳定支撑 10 万个并发连接, 更别谈百万同时在线了. 这也是这个模块为什么没有被普遍大规模应用的原因.

Continue reading »

我的前一篇博客文章"谈谈Facebook的聊天系统架构", 对Facebook的聊天系统架构进行了分析. 其中的有些思想和系统划分, 对即使不是做聊天系统, 如一般的网站系统, 也是很有借鉴意义的. 例如其中的在线状态服务器(Presence).

在线状态服务, 是这样的一个服务, 它维护了网站当前的在线用户列表, 接受其它模块的查询. 是实现统计网站同时在线人数, 维护在线用户列表等功能的基础服务. 在Facebook的聊天系统中, 在线状态是为聊天系统服务的, 所以在线状态是一种"强"在线, 也即用户保持着和Comet服务器的连接, 可随时接受服务器推送(push)的消息.

Continue reading »

今天看到一份 Facebook 公司 2009 年的 Slideshow, 介绍它的聊天系统架构, 其中的一张图结构非常清晰, 所以我对这张图谈谈我的看法.

Continue reading »