@anthoy #6 如果 binlog 还没覆盖清楚掉是可以的，binlog 可能会你自己删除了，或者设置了自动多长时间删除

@aaa5838769 #3 也不行吧，如果从数据库的数据更新，主从同步很快就冲突挂掉了

理解是不是有问题，难道不是应该从从库数据的主库 binlog 位置应用么。。
否则你从库数据和主库最新 binlog 之间的数据岂不是没有了

要循序渐进啊，一般每星期两小时锻炼的话，体能关节肌肉的改善至少需要稳定缓慢锻炼半年时间，跑步的话如果体能比较强还是不要大步幅，提高步频就可以了，器械锻炼的话 15 到 20 公斤起步，差不多要三个月以上才能再提高五公斤吧

之前手肘肩部关节疼死，手都抬不起来，稳定每星期两小时锻炼半年才感觉好一些，一年半后才明显感觉肠胃精神状态都好很多，循序渐进，稳定坚持才行啊，体力状态也会有低潮，所以实在坚持步行的也没必要逞强，适当超越但是适度锻炼才好啊

所以大家都很默契的显而不见了吧

其实不止服务器带宽跟不上，恐怕能写出 1Gbs 速度的代码都不是件容易的事，比如 python3 asyncio i5 单进程常规 web 内容长度 4K，127.0.0.1 echo 服务差不多在 3Gbs 左右，加上 http 解析返回和业务代码估计几百 Mbs 吧，想想各种对网络传输性能不太关注的 gui 程序，恐怕白瞎这么大带宽吧

@sazima #7 对啊，再说地图本来也支持一堆坐标点绘路线图吧，不需要索引的话确实这样就可以了

而且压缩之后只需保存经纬度和时间就可以了，并不复杂吧

这不就是和录音差不多原理么，按固定时间采样，比如 1 秒采样当前经纬度、速度和时间，然后压缩就可以了啊，压缩也就是去除相同方向速度的不同时间重复数据就可以了，最后数组保存就是了

一般来说应该扣余额之前检查卡是否有效就可以了额
余额的问题应该是算不算收入，算就设个定时每天扣款到消费记录就好了，不算，那就不应该扣余额

我觉得很多人过于乐观了，而且用 2g 到 3g，3g 到 4g 类比很不恰当，之前之所以会迎来巨大爆发，很大程度每一次升级确实是质变，更重要的我想还应该是，3g 和 4g 重要的商业场景都已经在 pc 有线或者 wifi 模式下完全得到了证明，比如 3g 的电商、sns、微博，4g 的在线游戏、视频语言直播，而且在 wifi 下已经完成了技术准备，缺的就是网络问题，这个谁都看到了，可是 5g 呢，有什么是成熟商业场景了么？看看现在提出的 vr、ar、自动驾驶、工业互联、万物互联，哪个是技术完备成熟的？

还有更重要的，3g、4g 依赖的场景几乎都是纯软件场景，一旦开发完成，部署几乎不需要成本，看看 5g，哪个不需要独立的硬件依赖，或许很多人没做过硬件相关的开发，现实世界总是很慢的，任何以小的功能都要很久，更别说还有很昂贵的分发部署维护成本了

再说句不客气的，5g 很多场景或许未必真的有用吧，比如万物互联，在现阶段下看来，真的会是一个有用的场景么？难道不是一个和当年大数据火爆时，啥走到门口就知道你是谁为了点好喜欢吃的菜、看妹子一眼就自动给你识别手机号微信这样现在看来有点可笑的实现么？把那么多东西连来组成一个有用的东西恐怕非一年两年可以搞得定的吧

5g 确实是一个很有用很有价值的功能，但我想认为和 3g、4g 一样会快速带来爆发点，我感觉也有点不太恰当，我相信未来 30 年，5g 和以后更先进的版本必定会彻底改变我们的生活，但是 5g 会想 4g 那样带来下一个爆点，似乎也不太可能，现在缺的可不止 5g，太多东西了，这个恐怕不是一年两年能搞得定的

纯 cpu 计算但是双核 cpu ？

if getNullTime >= 7 有啥作用，except 出 errno.EWOULDBLOCK, errno.EAGAIN 就表示数据还未准备好需要稍等通知啊，这个很正常啊，网络栈都是组合好数据一次可以读取多个 ip 包的，那么从内核 copy 到用户空间肯定比网络栈处理速度快啊，所以网络栈出 errno.EWOULDBLOCK, errno.EAGAIN 是正常的，没必要重试，下次如果数据准备好了，再调用 epoll 时又会得到通知

更细微的，就算 cpu 一直在运行，不同指令的功耗也不可能一样吧

@leafin #27 他的意思应该是覆盖整个城市的类似交流电的巨大电场吧，无负载时无功耗，但是就算有这么大功率足够完全改变整个环境了，感觉上还是没可能吧，几百年前特斯拉还提过呢，感觉核裂变聚变电池才更有可能近乎无限续航吧

从性能上看 tornado 和 twisted 差不多，好处是 twisted 实现的网络协议很多，没特殊要求我还是支持 tornado，感觉对 async await 支持更方便

asyncio 性能看似更好一些，但是其实只有 protocol，不过在 async reader 和 writer 的情况下，其实也差不多，不过不得不说 tornado 的 iostream 的实现过于复杂了，极大的拉低了性能

自己也实现过一个简单的，https://github.com/snower/sevent 差不多有 asyncio 三倍的网络性能，协议解析简单代理转发类的服务还不错

认真说还是 asyncio 吧，async 配合 await 还是比较容易写的，其实 go 的开发效率感觉还是低一些，没什么几万几十万并发的，性能啥的完全不是问题，感觉没啥特别必要，但是 go 确实方便啊