-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJMgyAIAAoJEED6UmVskhksvTMIAK2cySLja/IUmiZ2JeebcGOb
XJvuqI1dDRQZqxrS33TqOMublbUSsPpnFGjpH8UNzljgI1/J37gPb2ENYw7q+lC0
Nu8e1tr73zdaIgyqXrv77UHAKNOhs8GTIcxJtJfYCcm9QQNQ8o5F/qqxVQLY0OmR
in8pM2KHi+rMhBBQKMWoakHfqZJovbR1XawLKNeSiJn6P8w2VlbhpDAbVDwkBHm9
ep19gjwNpACjBKRvZZ7q92HgSz3EiFQgZFwOjTIjS9MH5r79h1+fMao34PplkW4a
OAbY8iUlucjOqAUPhMGqvpSd9JQ7fo8mc8o1witNEJQFiu38jZXGxzfm7qeoNS4=
=PaDT
-----END PGP SIGNATURE-----
(公钥问题请见 关于页面)

实际上该说的话已经放到 README 里去了.

—

注意:
请使用 Google App Engine Python SDK 更新. 如不使用的话可能需要去掉 derived_file_type: – python_precompiled 两行.
部署后请设置 Administration – Versions 选择 secureable. 如不选择的话请注意修改 fetch server 地址.
请留意服务器证书问题. 使用 wget https://xxx.appspot.com 时不应有证书错误的提示. 可用的 IP 请自行查找.
请尽量不使用 GAppProxy2 登录访问 Google 相关服务, 特别是 HTTPS 方式. 如果有相关需求的可以试试 IPv6 方法.

安全相关问题:
不附带 SSL 证书, 不推荐通过 GAppProxy2 访问 HTTPS 网站. 证书可以用上面的命令自行生成. 使用证书并不保证 SSL 安全性. 内容传输加密依赖 SSL 层完成, 请注意证书的验证.

Changelog:
2010-08-29 1.0.0, 稳定版
基本重写, 代码更精简.
服务器端带宽利用率更高, 不再有无用的 urlfetch 请求. 增加了 x-range 以处理自适应 block size 的问题. 增加 CACHE_NAMESPACE 项, 适合与其它程序同时部署.
客户端把断点续传与主处理合并, 不再单独处理. 日志中增加 size 和 referer 项, 方便本地分析(但没有也不会做保存的功能).
本版起 Fetch_Max 可以改为 1 而不损失任何功能(断点续传适应能力可能会下降). 默认仍为 2 以平衡功能与 urlfetch 调用次数.

—

入正题, 列几个试试看.

布道者
也不知道散布的都是些什么东西.
技术白皮书 (Technical Overview) 挺重要的. 不过有些领域偶确实没什么发言权.
偶不是非常关心稳定性, 当然这是建立在冗余, Failover 等基础上的.
如果真做布道者的话, 应该更加重视同类竞争产品的相关特性. 不过偶看过那么多(?)之后, 却不完全清楚应该向外推荐什么.
技术创新靠什么来判定? 有一类技术偶是比较清楚的, 就靠对代码的理解, 加上复杂度的分析. 偶暂时不会去顾及非算法类的问题.

工程师
偶曾经是 Online Judge 的常客. 但偶知道自己不是 TopCoder.
虽然偶可以说自己擅长算法复杂度分析, 但并不等于自己数学怎么样.
事实上, 如果把算法描述的很清楚的话, 稍微有点基础的就能得到分析的结果. 这不是一个值得夸耀的地方.
需要特别提出的一个就是 DBA. 说如果大家都知道数据库里面的引擎怎么工作的话, 那就可以不用关注索引优化这些可怜事了.
希望这种职位整体尽快能够提升到架构层面上, 容量规划, 并发与延迟(准确点是 seek time) 规划.
偶是个及格的 SA. 说及格是因为知道关注安全方面的问题. 某些人的机器老是躲在(?)后面发抖, 万一穿过去怎么办?

设计师
视觉设计不行. 页面设计会抄.
前两天偶说对像素的敏感度也应该有点区别. 偶不太喜欢 psd 到 html 这种方式.
不过后来知道了, 这是设计师的本能, 偶这种外行还真不能瞎搀和.
这年头又多了一种交互设计师. 说设计还真是抬高了. 找茬能力强就行? 当然, 这玩意也应该形成一些理论或者方法之类的, 不过好像这个真不缺.
说到这里想到一篇文章, “向用户、竞争对手学习，是360的微创新之源”.
这个问题偶是这样看的, 他策略对了, 但时间和地点都不完全对, 再加上大环境的背景. 你产品好, (员工?)技术好, 但说不准做了件什么坏事呢.

研究员
研究旁边还有分析/挖掘的问题. 如果让安全背景的工程师去做网站统计, 做出来的东西会很有意思.
当然事实上不会这样做. 不同人对报表的关注点是不一样的.
刚才这个微创新的问题实际上没说完. 策略是对的, 也就是说遇到问题要看看和自己有没有什么关系.
事实上这些事情很多都不是偶然的, 学到的东西迟早会有用.
都说天生我才必有用是吧? 可以往这个角度去理解, 理解也是多种多样的, 别抱着一个死理不放, 要不底下写不对有效性负责干嘛?
不过很可惜的是用户研究偶做的非常不好就是了. 还有很大一部分人偶很难接触到.

另一个方面是技术研究. 前面说过偶数学不够好. 所以这个方面突破的机会不太大.
课题都没有上哪里突破去? 不过真有心的话可以看看 GSoC 或者是 Bug Tracker / 邮件列表什么的, 看看这些项目遇到了哪些困难, 和你自己的工作有怎样的关联.

—

ps:
这好像简历一样的东西. 写出来就算是个反思好了.

豆瓣有个很有意思的 Feature, 不知道有多少人知道. 先说个无关紧要的事, 挡住这个 Preview.
豆瓣日文书的价格哪里来的小数点?!

Feature 就是, 在豆瓣里的 Amazon (某国) 搜索, 生成的链接在点击时会更新已有数据库中的数据.
偶这个豆列里就有不少书是重新更新过数据的.
最近还发现有 ISBN 有问题的书, 哪里有反馈途径哪? 这个数据来源是个问题. 好多书店也跟着一起错.

搜索时有结果的时候有 amazon 链接, 无结果的时候反而没有这种链接了, 这叫什么设计?
白送数据都不要. (这话很耳熟? 谈统计的时候说过, 这里居然也能套上)

—

为感谢电子工业出版社某编辑, 于是推荐了两本日文书.
Debug Hacks -デバッグを極めるテクニック&ツール
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)
以下以 #1, #2 代替完整书名.

#1 正在挑译者.
看样章偶有点想去买原版书慢慢啃了… 校对, 审核碰上这种的不累死才怪? 专业用语的翻译很重要. 大家都知道 Binary Hacks 已经被某出版社(选的翻译)给毁掉了, 要是挑不出人来…

插一句, 这年头靠搜索引擎翻译倒是蛮靠谱的. 这个和开发经验关系并不是很大, 懒可能是个更大的问题.
搜上个词, 有维基的看维基, 没有的还可以看其它文章的上下文. 这种方法对外来词特别有效.

#2 书都有人自告奋勇译出目录来了 (不过这目录是有点小问题, 偶有个修正版的).
顺便说个翻译目录中漏掉的事. Hatena 的 Bug Tracking System 最初不是程序.
TODO | DO LATER | PENDING | DONE, 四状态.
好像 DO LATER 这个状态在某些地方被简化掉了. 其它的就少说点, 免得知道太多不新鲜了…

—

张春雨说:

国内读者有个不好的习惯，就是好高骛远，一本书如果看看标题只要觉得大多数是自己见过的，不管是不是真的搞懂，也不会考虑，非得是有一些完全没听过或听起来很深奥的东西才物有所值。不容易静下心来从头学起，这也就是国内图书与日韩、港台都有很大区别的原因，尤其是现在，畅销的书都有很比较新的面貌，也是在迎合这种心态。

hmm… 这段自己读吧, 偶不插话了.

—

继续换话题. 上个月这个时候点了点书, 现在的结果又不一样了. 只有 1 本的出版社略掉.
Oreilly 4(电子3机械1), 电子7(1翻译,不含Oreilly), 机械6(6翻译,不含Oreilly), 人邮6(1原创,2非图灵,2 Newriders), 清华3(1原创,1影印,1翻译). 电子社以微弱优势胜出啊.

都看到这里了, 这里丢个豆列好了.

—

ps:
GAppProxy2 1.0.0 可以发布了. 不过… 还是等等吧

问题的背景请看 谈 mixi 访问故障事件.

patch: http://gist.github.com/524517

主要的修改是对多线程条件下的计数器做了修正(例子如下), 并对链表操作加了 mutex.
- base->event_count--;
+ __sync_sub_and_fetch(&(base->event_count), 1);

未加锁的情况下 event_count 有可能会被破坏.
event_haveevents() 的代码很简单 (return (base->event_count > 0); ).
在 event_count 被破坏掉之后, event_haveevents() 返回 false.
/* If we have no events, we just exit */
if (!event_haveevents(base)) {
event_debug(("%s: no events registered.", __func__));
return (1);
}

这样, memcached 就这样无声无息的结束了自己. 这是 mixi 版的问题.

更深层的原因要先注意一下其它错误的信息.
[err] event_queue_remove: 0×15ea9d88(fd 30) not on queue 8
queue 8 即 EVLIST_ACTIVE (event.h)
在什么情况下 ev_flags 会被改动呢? 注意 do_accept 在连接数过多变成 false 的情况.

(memcached.c)
void do_accept_new_conns(const bool do_accept) {
...
if (do_accept) {
update_event(next, EV_READ | EV_PERSIST);
if (listen(next->sfd, settings.backlog) != 0) {
perror("listen");
}
}
else {
update_event(next, 0); //look at me
if (listen(next->sfd, 0) != 0) {
perror("listen");
}
}
...

参考资料:
mixi大規模障害について
memcachedの件: その2

ps:
/* You cannot use this interface for multi-threaded apps */

ps2:
/* not thread safe */

ps3:
(diff)
if (!event_haveevents(base)) {
event_debug(("%s: no events registered.", __func__));
- return (1);
}

ps4:
给 update_event 加个锁? 好像没必要.
update_event 调用 event_del 再调用 event_queue_remove, 这个已经 patch 过了…
同理调用 event_add 再调用 event_queue_insert 也修掉了.
更特别的, event_queue_remove(base, ev, EVLIST_ACTIVE); 被保护起来了.

ps5:
三家联合, 力量果然大.

ps6:
thread safe 真是麻烦事…

ps7:
这 ps 数量破记录了吧…

ps8:
在这顺便牢骚一下啊. GR 不是有个 Like 功能嘛. 你要喜欢就点哪.
你不给偶反馈偶怎么知道文章好不好啊.

Update1:

http://kzk9.net/blog/memcached-fix-accept-new-conns-race.patch.txt

Update2:
mixi大規模障害について 解明編

Update3:
http://groups.google.com/group/memcached/browse_thread/thread/fe1ccd05242a5f05 (小心有墙)

加 memcached 服务器, 使每台 memcached 服务器不承担那么多连接. 这个问题就解决了.
但这显然不是长久之计.

—

这个问题从多个方面来看.

1 意外的挂掉
意外指的是什么? 这是一个还没有弄清楚的问题.
memcached 对各方面性能的要求并不苛刻.
可能的进程死掉的原因第一个要算在 OOM Killer 身上.
但人家说, 要是 log 里有这种东西, 那早不就注意到了.

另外 OOM 是可以关掉的.
echo 0 > /proc/sys/vm/oom-kill # 关掉
echo -17 > /proc/PID/oom_adj # 降低 OOM 评分, 所以杀不掉

有些原因是可以排除掉的. 因为挂掉的不只一台.
内存容量被限制住了, 肯定要为内核留一定的余量.
连接数量多也是内核在用内存, 杀掉用户进程实在是不厚道? 当然这事情不是这样的.

代码上还有问题吗? 这个很难说, 这么多眼睛盯着呢…

2 容量规划
容量规划也应该包括连接数规划, 之前也确实没怎么注意这个问题. 当然这只是一个方面.
hmm… 难道说以后故障规划也会流行起来?
数据库的连接数/处理能力问题全让缓存给盖住了.

说前些日子看过笑话, 数据库 100 连接数授权加上某软件之后就能承担 1000 连接数. 答案见 ps.
这都超过了 C10K 了, 再用这种东西好像没什么用了.
mixi 也没有说自己用的是 udp 还是 tcp 来连接 memcached. 不过这应该不是主要问题.

3 架构问题
都在喊优雅降级. 要做到容易吗? 不容易的.
memcached 挂掉, 用 consistent hashing 也不行.
特别是一台机器上插着那么多内存, 那挂了损失是多少?
对 DB 的查询次数可以近似看作 内存大小 除以 缓存项平均大小
(实际还有个压缩问题, 当然不一定非是这个数, 只是说这个意思).
要是用个 SSD (这里是容量大的意思) 做缓存挂了岂不更惨? 你要用多少时间去做这个恢复?
(当然, 这里有 mapreduce 思想可以套用一下)
这种东西这么重要, 不把它当作单点看待行吗?

说这种问题一旦重现(偶给你关上几台 memcached 机器的电源), 让你降级试试? 牵一发而动全身.
DB 都挺不住, 页面逻辑那么复杂, 需要多少多少个查询才能完成, 就因为负载的问题完不成请求, 那当然就要出故障了.
t.sina.com.cn 在说用纯缓存的架构, 这真是一个警钟哪,
虽说现在好像没什么问题, 也许是因为知道 memcachedb 承受不了那么多连接.
这都是猜的. hoho

也许这种情况 redis 或者其它带实际存储的系统更好一些,
因为至少有个硬盘 snapshot. 重新起来之后还能撑上一会.

当然 mixi 还有一个问题. 所有服务同时挂掉. 缓存没有分开. 这个相对来说是容易解决的.

—

mixi 自己的总结 (非直译)
1 降低缓存系统负载
2 为将来负载增加的情况做准备, 对故障发生时 memcached 异常终止问题进行调查, 研究提高缓存系统可靠性的方法.
3 重新设计/部署缓存系统以减小故障影响范围.

—

八卦时间
1 mikio 同学离开了 mixi.
Kyoto Cabinet 是 GPL 授权的(附加条款: 链接除外). 商业授权可以收钱.
mixi 的架构设计 mikio 居然没有参与. 很令人意外…
2 有人说是 love machine 把 mixi 弄挂的.
3 谣言说 mixi 申请破产. 不过股价确实跌了有不到 3%.

—

ps:
答案是连接池

—

Update1:
问题可能和 libevent 版本有关.
mixi 使用了 memcached-1.4.4 和 libevent-1.3b 的组合. 而后者是老东西了. (现在普遍使用 1.4 系列)

这个肯定要动用 strace 之类的东西, 个人认为要用排除法了, 问题重现的难度并不低.
就在这时某些无聊人在 Twitter 上大谈 Linux 服务器发行版的选择问题. 在此做个记录.

Update2:
找到了 1.3b 有嫌疑的一个地方, 但此处已在 1.4 系列中修正.

[err] event_queue_remove: 0×15ea9d88(fd 30) not on queue 8
类似错误在 libevent 1.4 系列较新版本中仍有发现. 详情待查.

Update3:
使用该代码可使 memcached 重现上述错误 http://gist.github.com/522741
详情见 memcachedの件: その2
这次的调查团队阵容很强大. mixi, hatena, Preferred Infrastructure 都有工程师参与.

Update4:
bug 确由 libevent 引起.

Update5:
问题与 memcached 也有关系, 发现人 @llamerada. 相关 bug: http://code.google.com/p/memcached/issues/detail?id=99

http://kzk9.net/blog/memcached-fix-accept-new-conns-race.patch.txt

Update6:
mixi大規模障害について 解明編