这不是连接你代理服务器的信息么，不明文你咋代理连接

似乎没人管你喜不喜欢吧，从来都是看整体用户接受程度以及达到这个接受程度所需付出成本，既然他们已经活了下了并且壮大到如斯，那么显然大多数人还是喜欢这样的，关于啥规范不规范那就更扯淡了，大多数人接受不爆发的就是规范，自古如此

如何持久保证自己获取信息的质量，本身就是很难得，这是一个千年难题，想着毫无压力的通过某个工具不断获得高质量深度广度信息是痴心妄想，所以还是别想那么多了，多花时间不断学习搜索整理才是正理，商业信息平台的目的和价值是获利，从来不是为了让你进步

如果你的意思是很多大 message 会占用很多传输时间，网络不好的时候会阻塞整体性能的话
一般来说这种情况下用 tcp 的话，更常用的做法应该是大 message 使用单独连接发送，小消息使用一个连接，网络不好大消息超过一定时间无法传输完成直接关闭连接就是了，考虑到连接建立开销啥的，用连接池就行了吧
不能开连接的话，那么应该是分小帧传输，加入优先级就行，大消息优先级比小消息优先级更低，这样也可以保证良好性能

如上所说，文件名用 hash，保证相同文件只存一份，其他的就无所谓了啊，反正现在磁盘页不值钱，删它干嘛

socket 创建的也是文件句柄，你都关闭了，那么这个文件句柄在内核里就直接被释放了啊，你在操作他当然不行了，就好比你一个文件打开然后关闭再读写当然不行了

第二个也是上面说的，tcp 为了过滤异常包所以关闭后会继续保持占用一段时间端口，立刻重用这个端口也是不行的

代理的话，能配出 C 直接看到是 A 的 ip，又不在应用层协议内支持，nginx 应用层不可能做到，ip 层应该是可能的，那么你这是要逆天啊

单纯转发流量的话太简单了，自己做一个都不需要 3 分钟

距离短时间短完全没用，前期不熟悉送的慢本来就是外卖小哥要付出的学习成本，而且面对着高纬度的更好算法调度根本就是降维打击，咋说三转手的怎么保温，食品安全谁来承担责任，别看着不起眼，麻烦大着了

@marcong95 #15 短信本来就很快，美团单车又没做到秒开，五六秒足够短信到达了

BLE 是比 GSM 耗电低，但是怎么着也需要单车能联网，GSM 必须的，那么少一个 BLE 模块不香么，GSM 模块还附带基站点位，GPS 都省略了

这不是技术水平的问题，这是成本的问题，有钱谁做不出好东西啊，但是就一两块钱的事情真花那么多钱想着优化毛用没有用户体验才是真傻叉，而且硬件不比软件，各种奇奇怪怪的问题总是超过想象，所以吧现在的共享单车低校验高容错低成本的系统可以说是非常科学了

没有客服显然是问这个问题的人太多了，客服多费钱啊，那我就不留了这不就省钱又省事了

自行车为了省电，现在估计都改用发短信通知开锁了吧，所以这都不算事，反正也没几块钱，你提个异常开锁，直接给你免单就是，想那么多干嘛

但是重点是楼主居然为了这小毛病离开十分钟还折回去，然后花了一个小时折腾这事，真实佩服佩服

楼上一堆说太浪费的，人家有钱有地方有心思，想用的舒服咋滴了。。

主路由 ac-68u 确实不够，性能太弱了，如果房间大，各种手机电脑平板，再买点智能家居设备估计都能上百设备接入了，ac-68u 估计够呛

其实吧新房装修如果以后改线麻烦的话，最重要的就是布线了，不管怎么说有线总会比无线好的，一个房间只一根线还是比较虚的，重要的建议多放一根，光纤有空间也可以放一点，现在用户不大，但是这科技日新月异的说不定以后就好用了，如果改线不麻烦那就无所谓了

设备的话，更换方便，可以先选一部分，后面实在不行再补呗，比如马上 wifi6 到处都是了，ap 肯定也是要支持 wifi6 的，智能家居设备以后也会越来越多，那么后面交换机主路由肯定也是要再升级的


按 @dell #9 说的再内部分子网 nat 实在坑肯定不行，否则内部 nas 、无线投屏、智能家居设备啥的用起来体验下降太多了

https://github.com/snower/forsun

或许可以看看，自己一直在用，订单超时处理啥的，超时后触发消息压入消息队列再由异步任务处理，最多创建了数百万定时任务一切 ok，使用 redis 持久化稳定性也还可以，程序添加删除都很方便，除了常见的几种超时处理器外也可以自己编写超时处理器来配合自定义消息队列啥的

磁盘 IO 异步话似乎完全没啥必要吧，现在 ssd 的话本来就很快，而异步增加逻辑复杂大多数情况消耗的资源更多吧

内存小就每次 ssh 进去跑最好了，确保每次跑完进程都退出重启，多连几次 ssh 也没啥吧

也许从法律看起来，老板只是说你爬一下竞争对手的数据吧，然后你用模拟登录代理啥从法律来看违法的手段爬到了数据，而且显然你比老板更清楚这个手段的不合法性，所以从法律方向上看谁的罪更重不是显而易见的么，哈哈哈

虽然大多数情况下，最终老板用这些非法获得数据赚钱了，所以同等担责，一勺烩是正常没跑了

你可以 dis 看下生成的字节指令就知道了，+= 1 也是需要好多条指令的，python 的 GIL 应该只是在单条字节指令保证原子性吧，但是你一行代码很多时候都是多条字节指令的吧

@pmispig #3 那估计你很难找到解决方案了，毕竟无论是 mysql 数据库和 mysql 协议自身都没有加入流式传输模式

不能改程序的话估计靠谱的方案还是加内存就是了，现在内存也不怎么值钱，使用量少不想多花钱就多加点交换空间死撑，量大的话就只能多花钱买内存了，然后控制着并发写读数量，只要不崩溃就是了

似乎 mysql 应该不支持单行流式传输吧，mysql 的协议也不支持流式传输吧，而且这样显然事务也没法做了，所以你这不太符合 mysql 使用方式估计很难找到靠谱解决方案了

实在不行或许可以考虑分片，整个大数据分成 16K 的小段，每小段编个码放到一行里，写入的时候一行一行写也间接实现了流式传输写入，读取的时候也可以用 unbuffer 模式可以很好的支持流式传输

话说你这不分片，就算 mysql 不爆内存，你应用服务器也得爆吧，你这是存的视频数据么？认值说还真没人这么干，太低效了

正常不应该同时网线+光纤么。。