学习态度不端正

其实别把学语言当成一场圣战, 其实入门也不过一周时间, 学深入了日常用一年基本也够了, 但是学了语言就够么, 好多初学者最大的困惑反而是在学完之后, 那个时候学完某某语言 prime 仿佛手握雷神之锤,举目四望到处找钉子, 但是往往很多人都在这个时候发现, 妈蛋的学了半天语言确还是啥也不会做, 然后发帖求助问能做啥, 然后被告知还要再学习 B, C, D, E.......等等 等等.......

@billlee 因为逻辑上来说只需要同步最终状态所以合并处理是最优的, 这个方案是原来做游戏服务器的时候用的, 主要的数据操作都在内存完成, 往数据库存只是为了持久化, 那么其实只需要持久化最终状态即可

@qq915458022 如果一直是这个频度的话, 基本上压力都是在数据库上了, 前端加什么都不好使, 先上个阿里云的 RDS 自己测一下 TPS, 能超过 1000 就 ok, 可以从最小规格的开始实验.
我在网上找到一个评测文章你可以参考一下:
http://chuansong.me/n/2057150

另外, 如果全是 update, 而且 MySQL 测试出来不 满足 1000 的 TPS, 比如只有 200(原来年幼无知的时候在阿里云的最挫的 VPS 上本机装 mysql 测出来的结果). 那么可以用 redis 来做个对列, 如果光用对列是没用的, 因为写入数据库的频度始终比来数据的小, 所以对列会一直堆积耗光内存, 我原来做的对列是可以合并 update 请求的, 比如用 update 一个计数作为例子, 如果发现前面有未执行的 update 的值, 就把几次请求合并成一次数据库写入, 这样子数据库就不需要那么高的 TPS 了.

@qq915458022 我是说的访问模式, 比如你说的每 5 秒陆续会产生 4K 次请求, 那么是一直都是这个频度还是峰值是这个频度然后会有一段时间没有这么高的频度

@qq915458022 看你独立数据库服务器选的等级咯, 我觉得你还是先从访问模式的分析开始比较好, 你的业务什么访问模式都不清晰的情况下盲目做架构基本都跟找死没区别, 除非钱多, 用服务器来堆

@qq915458022 最好用 SSD 的 VPS, 不然 MySQL 装本地性能堪忧.

另外如果每次请求都有一次 update 的请求的话, 那基本就是在考 mysql 的性能了, 加缓存什么的治标不治本, 除非你的服务请求的频度是根据时间还有不同, 分了峰值和谷值的.

有很多情况还不清楚, 所以暂时没法给你进一步的建议

交个外国女朋友就行了

焚香沐浴扣脚皮

这个量级基本上大多数服务器都很轻松能扛下来嘛, Linux 修改一下 open file 的 limit 就好了

支持开

gunicorn 用 meinheld 的 worker 比 greenlet 的还快

今年还是有好几个乔粉去见乔布斯去了

@wafm 貌似是 6 折

@wafm 打狗爹 400 电话, 有折扣

买回来最大的可能性就是吃灰........ 呵呵

结果一去发现全是扣脚大汉

毫不掩饰, 就是这么霸气