其实退订一般来说不是退订短信通道么？但是营销类的好多共用短信通道的吧，那么人家怎么可能真的把你屏蔽了

@tongjun #3 所以要发的更勤了么。。

@daybyday #16 mysql/redis 都有 tornado 的异步版本 driver 啊
redis 推荐 https://github.com/thefab/tornadis 比 tornado-redis 性能高很多
mysql 推荐 https://github.com/snower/TorMySQL

@mengskysama #17 tornado 和 asynicio 在高并发下的问题都是同一个，python 语言性能太低，高并发下同时处理大量连接数据会导致协程栈太长，每个 req 处理时间大大增加而导致很多连接会超时，事实上 python 在普通 curd 的 web 场景下大约 64-128 同时处理 req 之间就能保持进程 100%cpu 使用率，既保持每个 req 的低延迟又可以保持每秒吞吐不变，当然是 mysql redis 都用异步的情况下

asynicio 比 tornado 性能高一点点大概是 tornado iostream 的实现问题了，太繁琐，导致性能比 asynicio 的 protocol 性能低了很多

自定义字体，这个加密牛逼啊，有想法，但是每次生成字体文件应该挺耗资源的吧，那么就不可能有太多份才是，写个脚本刷新试试，看看会不会遇到重复的

@wwqgtxx #14 你说的对，区别就是 gevent eventlet 完全屏蔽了上层对协程连接的调度，在大量连接同时运行的时候会产生大量协程在运行，使得等待运行的协程栈太长，很容易产生雪崩的

还有 flask-socketio 只能在连接读写有框架做异步，应用层是很难异步的，并发会受限的

tornado 管理 10w 连接问题不大，反正都是由系统 epoll 处理的，重点还是在消息发送数量，发送量很大的话会受限 python 语言的性能可能会跟不上，还有可能还是连接建立时认真的过程吧，如果需要重启的话，单个进程 10w 连接建立可能会比较久

flask-socketio 这种可能管理 10w 连接都有问题，更别说转发消息了，socketio 玩具吧，真要用估计还是要自己实现服务端的吧

不过话说 10w 的在线，可能需要多进程多机备份的话，就需要路由功能了吧，只是单进程会不会不稳定

已读也都是一条消息了，都一样，只是不知道你只是需要把这个状态转发给发送方，还是服务器要持久化存储，那么要注意受限 python 语言性能，单进程访问 mysql mongodb 等数据库 rps 都不是太高，im 持久化会是个很大问题

话说干嘛不找个云服务，太费劲了吧，还是有业务要处理？

@Danic #12 multiprocessing.Array multiprocessing.Value 创建的都是共享内存啊，fork 之后都是多个子进程共享的

这个变量 A 在 fork 之前用 multiprocessing 创建成共享内存变量就行了啊，这样 fork 之后任何一个字进程修改了变量的值，其他进程都会同步读取到新的值，只是每次访问共享变量比访问普通变量要慢很多

路由器不行？以前 tplink 的小路由普遍都只能 54m，有墙速度更慢了，而且也得看周围热点多不多，多的话相互干扰速度也慢，话说有限直连居然不是千兆网？

@kimown #17 slave 最后同步 master 的时间是正常的，bgsave 无法成功应该是内存不足的问题，可以看 @monsterxx03 #15 的提示

master 被系统 oom killer 是因为整台机器都给 redis 用了，所以没有设置最大内存使用，也没有设置 swap，redis 有峰值使用所以差不多申请了所有的物理内存，虽然平时只用差不多一般，机器上还部署有监控系统的 agent，所以其在某次申请内存的时候触发了系统 oom killer，也没有对 redis 进程的 oom_adj 进行特别设置，所以系统果断 kill 掉了 redis 进程

数据少了大半的问题就简单了，发现时 redis 已经被 kill 掉了一晚上了，所以都过期了啊

可以看看这个 https://cachecloud.github.io/2017/02/16/Redis%E7%9A%84Linux%E7%B3%BB%E7%BB%9F%E4%BC%98%E5%8C%96/

说起来做了监控，但没加 redis 的告警，业务使用 redis 连不上也不出系统错误，而是除了其他业务错误，导致其他系统告警完全忽略了，也是自己给自己挖了好大的坑

@monsterxx03 #15 好的，我研究下，感谢！

@monsterxx03 #10 哦，master 被系统 kill 掉了，从库数据只剩一小半，奇怪了，说起来怎么防止 redis 被系统 oom kill 掉呢？

@swulling #9 血崩，表示我现在很崩溃，master 被系统 kill 掉了，slave 的 bgsave 自己停了，数据也不知道哪去了大半。。。

@judeng #11 slave，从某天开始突然不 bgsave，又没注意，被坑了，不知道这种情况会是啥问题，难道是内存不足，无法完成 bgsave 么？

master 是关闭持久化的，虽然是 bgsave 但是，似乎还是导致延时上涨，所有就由 slave 来 bgsave 了

@judeng #5 好吧，slave 有不自动 bgsave 是啥问题？ redis 坑还不少啊，感觉

@rrfeng #6。。。这个不是重点好吧，先解决问题才是

@monsterxx03 #3 还是 2.8，那么 slave 的内存怎么回收呢？ bgsave 的时候似乎能处理过期问题，这跪了。。

@jyf #1 就是 redis-cli info 之后看到 key space 加起来有将近 200 多万 key，忘了保存截图了
唉，惊讶的发现 slave 切 master 之后，瞬间数据 key space 信息只剩 30 多万 key 了，血崩。。