应该你说的这个代谢是全局整个身体的问题，如同人总会慢慢一点点老去不可避免，而在青中年的健康问题更多是局部的，生活方式的不均衡会很容易导致局部损伤过快，这应该才是健康最大的问题，提倡多运动则可以很大程度刺激再生长，这个是在人类适应环境过程中自然形成的，同时也可以加快这些部位血液体液流动，更快的带走老化的组织和有害物质，所以运动有益健康更多就如同汽车保养一样，避免局部过快磨损而导致使用不顺甚至报废一个意思吧

磁盘头是不是会一会儿 seek 到文件头部？？这是个啥操作！ seek 只是切换了文件描述符内记录的文件当前读写文件位置罢了，和磁头也没啥关系吧，更不要说两个进程文件描述符信息都是独立的，有啥关系，实际读写触发磁头寻到的话，磁头始终在高速旋转在磁盘上，你不操作也有其他进程会触发磁头寻道的吧，而且 kafka 这种连续读写的方式来说，文件头和文件尾大概率在同已磁道上，消耗很小的吧，更不要说操作系统还有文件缓存

恢复时间和异常概率是最重要的，用 etcd 或 zookeeper 这样实现的服务发现，节点的上下线一般是节点自身主动上报，这样某个节点上线或者下线整个集群几乎可以毫秒级感知到，根本无须额外人工操作，负载均衡服务添加新节点肯定是要手动，节点下线也只能做到秒级检测，加上 dns 恢复时间那时间就太长了，而对于现在大型系统成千上万甚至十万个微服务来说，节点数都能到数十万吧，再加上云时代跨区域跨机房，各微服务各节点又必须能实现自由更新重启自由决定发布进程相互不影响，无须等着晚上统一更新重启，还要能随时可以自由迁移切换机器机房，如果人工修改加秒级的恢复时间，所造成的波动异常会十分高，用户都能感知到了，所以还使用负载均衡的方式的话就太作死了

你可以查一下 app 和小程序的单客推广成本就知道了，估计至少 10 倍差距吧，支付宝淘宝这样市场占有率超高的国民 app 单客推广成本更是高到快上百了
无需安装扫码就能用就秒杀了大部分 app 了，直接屏幕上竞争优势更大确实是的，但是吧这个优势仅只是 1%打开率还是 2%打开率比较，你觉得有啥实际优势么，app 打开、转换率你可以到网上查一查，估计数百万及千万以上安装的，能几万日活都是不错的了
还有最后这个小程序使用习惯了无法往 app 引流就更扯淡了，做成了有钱了想怎么玩怎么玩完全不是事，做不成哪凉快哪去说啥都没用，关于啥产品、体验啥的纯属意淫，大部分情况来说，只要不是特别特别难用，影响可以忽略不计

你手动这两错误本身就是正常的吧，你这个 for 是死循环的，又没有检查 websocket 连接是否断开的情况，如果前端有异常断开了你再写就会返回这个错误啊，前端断开一般会重连，所以你应该断开后数据就保存再 chan 中，重连之后再往新的连接中写，具体是不是这样和为啥断开不行可以抓包仔细看看

微信 API 请求延时基本低于 200ms，这样算不到 600 并发就够了，8 核 cpu 的话一台机器都可以轻松搞定，别用多线程，异步 io 啥得库搞一个 600 并发并不算啥，微信正常发的话，估计也不会封你，但是吧 1000 万每小时，总用户得多大啊，要是乱发垃圾营销消息的话，投诉人数达到一定量肯定分分钟被封号了

@shijingshijing #96 眼睛看清楚啊，我们在说轻薄笔记本，谁跟你说 plc 的，眼睛不好就别出来了

@shijingshijing #89 你有需求和别人必须满足你是两回事，厂商只看市场统计学结果，厂商砍掉网口本来就代表已经放弃你这样的用户了啊，他觉得放弃你这样的用户反而利润更高有啥问题，你自己企业部署困难成本高，那是你企业的问题，你不能说无法把这部分成本转嫁给厂商就说厂商做的不对吧，部署合理花钱足够，wifi 的稳定延时完全可以达到要求，你不能因为你不想花钱或者不想升级自己的设备，就要求厂商应该保留网口，那么对那些更希望网口是否也不公平，再说轻薄笔记本本来定位就是 wifi 覆盖完善的大多数人大多数时候啊，你非用在没有 WiFi 的场景下，不好用还能怪谁，既然如此你买啥轻薄本

人家生产笔记本的厂商显然考虑的是生产成本和使用用户需要的统计学结果，就算自己到外面随机抽查几乎都没几个人需要用网口的，既然如此，厂商既可以节省成本又可以笔记本更好看为啥不这么干，就算你说的又部分场景还是需要，但是厂商凭啥又为你这特别小的群体这么干呢，你不喜欢别买就是了，你情我愿的事，纠结个啥，我支持砍掉网口，没用网口漂亮好多啊，看着就舒心多了，说啥都不如自己看着爽重要

确实如上面所说，除非宅基地，否则地显然不是你的，占用你私人土地说不通，但是占用耕地做他用还是要给补贴的，这一点还是合理合法的，一般以当地常规作物一年价值的数年来补贴，以一根电线杆占用面积及现在农作物常规价格来说估计也就几百这样子，不可能更多了，起诉估计也没啥用，即使你觉得很不方便很不爽但是规则法律并不会为你不爽买单，所以差不多也就行了，实在位置不好，农村嘛给根烟来杯酒商量着帮忙挪个位置更靠谱吧，否则花的时间啥的成本都比这个高多了，顺便说间断肯定是不行的，破坏他人财物妥妥的啊，较起真来，估计你的陪他十倍都有可能，所以好奇究竟你要了多少？他们还不同意

@zhybzc #19 基本现在量大一些一个月千万条以上的都 3 分了，发更多的还能到 2.5 分，考虑到分销商也还要利润，估计运营商给的价都快接近 1 分了吧，即使如此，分销商运营商等各种系统还是要钱的，这个也没多少钱了

公益化的问题就是肯定没人认真维护了，反垃圾，安全性都要弱很多了，而且大概率被滥用的可能，所以这不是一个好方案，不管效果怎么样，运营商在反诈反垃圾反滥用还是花了一些功夫的

开多连接针对高延迟应该是有效果的，等同于增大了发送窗口，丢包可能有点效果，但是不丢包延迟也较低只是单纯占满带宽所以速度慢，那肯定没啥用了

https 请求才收费，既然如此你自己不请求 https 哪里的费用，大不了再加个 http 的域名就是了，再说你用 http 请求就不需要付费了？白嫖 10G 的话就更别说了，你这话明显有歧义有故意在黑七牛的嫌疑啊

并发本来就没有先后，有先后叫啥并发，队列才有先后

这种等待时间不会很长的，合适的做法还是 ajax 请求后保持直到有数据或者超时，要实现保持也有很多方法，比如 redis 的 pubsub，zookeeper，或者用分布式锁服务啥的都很方便，websocket 会复杂一些，也需要单独长连接处理服务才能支持，不能直接在 web 中实现成一个 rest api

https://github.com/snower/slock

用 go 实现过这样一个锁服务，分布式 Event 的语义也很简单，使用支付 ID 为 key，已 1 为 lock_id 在创建订单的时候锁住，前端等待的时候尝试 2 为 lock_id 获取锁，异步通知的时候释放 lock_id 为 1 的锁，这时候 lock_id 为 2 的获取成功就代表这个分布式 Event 被激活了也就是支付完成，前端等待会立刻收到反馈返回，搞定

kcp 发包只要不超过你物理连接速度就可以啊，带宽限速在运营上那边，又不在路由这，而且就现实来说，流量越大的重要程度越低，所以从运营商那边来说，同等带宽想，优先保证低流量业务更有利于提升用户体验节省成本，再说你长时间满带宽使用或者超带宽发送数据包那么滥用可能就越高，那么给你更低的发包优先级和更高丢包优先级再正常不过了

@lovecy 估计不是，北京时间按定义应该是东八区时间，但是吧每个时区似乎是又可以细分的，上海其实不完全在东八区起始位置，所以应该 python 是用了细分后的时区，但是吧数学上也许看起来更严谨现实来说就很坑人了

多高的并发啊，就算 mysql update +1 这个性能是非常高的吧，再加上分库分表啥的，十万级 tps 应该是能轻松达到的吧，而点赞的日志会受限写入性能，那么完全可以异步队列落地就是了

先把点赞数加上去，前端缓存结果，然后用队列异步落地点赞记录，绰绰有余了

再不行把点赞数加在 redis 里，点赞记录也在 redis 加缓存，然后点赞记录推队列，异步落地 mysql 一小短时间后再回写 redis 确保准确，这样还不够你用的话，估计预算该上亿了吧，还问啥啊，找点牛人再做一个专门为点赞优化的的数据库就是了，千万级 tps 都小 case 了