@nullcc 很多人用这个方案，但这个方案题主跑不起来，太慢了。 题主可以考虑 heka， 我们数据量比这还要高点，两台机器往 elasticsearch里扔， elasticsearch 需要 12G 内存， 未用 SSD， 不过能用 ssd 速度快很多。

logstash 是 jruby 来做正则解析的，不知道为什么他们会用这么个方案，百思不得其解的慢。 heka 做法非常好， 如果不能及时处理数据，会缓存到 /var/cache/hekad/ 下面，这样不会造成机器卡死。 数据传输和处理有点延迟很正常，硬盘做大点， 准备 100G 应当就差不多。 几天不做都死不了。

如果转运过程还需要去查询 mysql， 那么我认为设计方案可能可以优化一下，类似日志的数据分析不应该做即时分析的，可以先把数据格式化后，之后开始做计算。 否则可能让数据阻塞在原来的地方。

请求加密是指传过来的数据是加密的，然后解密这部分数据？ 感觉很多东西都混在一起，耦合有点高。

用 linode 的人专线， 楼上你好意思说呢？！

看一下 mysql 的日志， 我肯定 100% sure 和 mysql 没有关系， 换 mariadb 解决不了。

跨洋的同步谁有方案跟我说一下

阿里云的 IO 真是没得说， 跟几十年前的硬盘一样

利益声明，我是扇贝网的。


楼上有很多人给了很多牛逼的方案， 而且恶魔的奶爸也被提出来，这些方案如果真坚持下来肯定能学好， 这些方法就跟我们的祖辈学英语的方法是一样的。

但问题就是恶魔的奶爸那些方法根本不具有可用性 ... 你们提方案的人可以出来看看自己到了地狱的第几层。 如果方案不具有可用性，就好比一小破网站你让整 100 台服务器一样， 说多了都烦， 没用。

学好英文， 这个概念很广泛， 怎么定义好是个问题。 我想对于我们码农， 读是第一位，写是第二位。 这两样搞不定，就不是很合格的程序员。 有很多人觉得自己的读完全没问题，但这是幻觉。 读要好，首先要准，其次要块。 一本英文书，你多久能读完？ 一个月？ 一个星期行不行？ 我们很多同学应当一本书都没读完过吧？ 也可能连一篇英文报道都读不通， 或者巨慢无比

然后是写，写这个事情的确是比较难， 因为有人中文也写不利索，特别是程序员。但基础的表达还是能训练出来的，不写错误的句子， 不用错误的语法，这些都很容易训练。 另外，输入多了，输出也会好一点的。

至于听和说， 当然也很重要，但要一步步来，即使是哑巴英语也比不不识字好。 我们就想一下，我们英语是不是比英国的哑巴好就知道了，肯定很多人都不如的。 另外，读和写都到位了，其实听和说还是很容易的。 如果要出国，突击训练一下； 如果不出国，要跨国交流，开几次电话会议就可以了，因为底子比较好， 一下就领悟了。

那么现在就轮到我说一下扇贝网了。 扇贝网给人的感觉大概是背单词的，但背单词不是我们的终极目标，我们的目标是提供英语学习的可行性方案。 啥叫可行性，就是小步快走， 不等大招。 一边学一边练， 让学生容易坚持，学有所获，全面提升。

不夸张的说，能够在扇贝网坚持学习超过 3年的至少超过 数百位神仙，我其实也蛮佩服他们的，五体投地， 因为我自己都没能够这么牛。

扇贝目前提供单词， 新闻阅读， 书籍阅读（收费）， 炼句（句子和短语训练，收费）， 即将 cover 新的领域，但因为还没上线， 我就没法公布了，近期应当可以看到。


这里有篇不是很软的说教文： http://www.shanbay.com/footprints/article/2188/ 作为老师吗，说教避免不了， 请原谅学究口气！

@blacktulip 嗯， 我去 clone 一个试试看

@vibbow 20K 肯定够了，我mac air 上其实还可以接受， 云太差了而已。 之前我们在公司的台式机（2core, 4G, i7)上跑时间也可以接受的。 如果没有带宽要求， 7K 够了， 买 ip 起远程是可以，但电信卖 ip 往死里贵

@blacktulip 其实我还真不是新开的，很早之前的，但我最近升级了一次， 升到 4096, 按理应当也换了 instance 了

@blacktulip 他们说明天联系，我看能不能搞个中国节点。 东京和北美 push 代码太慢了，让程序员等着 push 代码头疼的要命

@vibbow 服务器我们有托管的， 不过这样有点贵。 托管一年大概 6-7K, 一台机器要 20K，从订购到富士康出货要7天，还要去机房上架。 其实云服务器比实体机好多了，不说别了，我曾经 iptables 把自己关在外面这种事情想起来就恶心死了，周末还不开门，去机房要申请， 所以我不打算继续在机房折腾了。 尽量用云来代替。

btw, 某著名服务商说是节后联系我，当然我也不抱太大希望。 他们春节后就说联系我！

这个问题怎么谈的上 ip 呢， 难道不注册吗？ 不注册就可以发帖？

1. 注册的时候加验证码

2. 发帖的时候也加上验证码

3. 每次发帖的时候按照用户名统计发帖次数， 多长时间内禁止重发。 做的体验好一点，对发长贴的进行限制。 如果一旦发现一个， 丢到黑名单，永世不见天日；

4. 其次删掉重复字符， 这样看起来就不美了. 即使只是 strip 掉 空格，应当就很难看了

5. 最后过滤掉全部这种 unicode 字符就好了， 这个字符我也不认识 ...

我估计不用到3 就没人和你玩了， 不用去搞 ip 这么复杂， 又不是 DDOS

@qwe321 我比较 care 性能， 价钱其实我都能接受。 毕竟我跑单元测试一台机器就可以了， 是用来集成跑的

@MASAILA 好吧， 码农坚持的的确比较少，不是刚需。 不过坚持下来，对工作会有很大的帮助，成为 IT 大牛的第一步。

@XXOO 阿里云很稳定吗？ 我用七牛偶尔 CDN 解析不了，我用 阿里云 VPS （注意， vps 不是 cdn) 经常解析不了， 解析用的是 dnspod。

阿里云值得商用吗？ 被 CDN 要搞挂了，烦透了

@buobuk 带宽如果不够， 所有的请求可能都存在丢包，本来 50 ms 结束的请求， 可能需要 500ms 这个时候连接一直关不掉，会占用 CPU 资源。 如果遇上高峰（一般带宽不够肯定是开始高峰了）， 然后就会持续堆积，情况会越来越糟糕。 不过如果全部堵住， load 就不会持续升高了

@Sivan 可以背单词，如果反应好，还会有阅读等

从我的经验来看，如果你还在和我们讨论这个问题， 那你暂时还不涉及到分布式数据库的问题。 你可以先做起来再说，把这个问题留给能解决的人。

@gaicitadie 这个太夸张了。 对 v2ex 来说， thread 也是 select * from thread where id = 109856, 难道这个 thread 不缓存么？

我们缓存的对象是共用的，变化少的， 不容易计算出来的。

至于楼主说的情况，也需要看情况处理， 如果这一串信息很多， 而且可能在不同的表里，那么是需要缓存的， 如果他必须一次性取出来的话。

显然 账户余额和头像信息是不应当放在一个表里的， （如果是一张表的话， 那么我觉得这个设计本身有问题， 数据量大，存在更新平静， 不断刷 user 表）， 那么为了获取用户信息，可能要查询很多表， 这就有效率问题。

@pykwokcc 你代码放什么地方？

avatar 未来可能要扩展， 不是加个字段。 我的经验是不要这么整了， avatar 独立出来一个 app, 在 app 里来写 avatar 逻辑。

如果你在 auth_user 加了字段，哪里写 avatar 上传，剪切的代码呢？

加个 app 什么都搞定了

@ichou 2013就联系我了，现在都 2014 快过完了。如果好了，我大概也是用来做个反向代理，就和我用阿里云一样。