错漏百出，这都敢出来胡说八道，真行

首先 mongo 的 ObjectId 是本机生成的，谁说要写入库才有的，而且是单调递增的

分布式 ID 的首先需求是区分不同进程不同机器，不同机房，好嘛，直接把时间 bit 数加上去了，区分机器进程能力完全丧失，而且实际使用过程中，生成时间并不是平均的，有可能其中一毫秒内生成了几万几十万接下来好几小时都不用了，单毫秒内计数单字节，作死啊

Snowflake 需要手动配置集群机器进程 ID 作为一个分布式专用唯一 ID 生成算法就已经很不方便了，完全让一个微服务分布式系统无状态依赖变成了有状态依赖，而且是一个非常重要的依赖，作死啊，但是算法限制字节数 8 字节确实没用更好方法，但事实上强行限制字节完全没啥意义，多增加的成本并没有多少，但是一个完全无状态依赖又安全的分布式算法对于微服务分布式系统的意义就大多了，不知道省了多少事多少心

所以不清楚不知道还是别出来误人子弟瞎 bb 了

据观察，考试的车如果看着不咋滴发动机比较弱，所以起步时如果先少放点离合接着放刹车略微给油，提高点发动机转速再放离合可以大幅度降低熄火概率啊，但是考试时你还得协调的过来，当时教练死活说的是先放离合到车身抖动放刹车简直被搞到死啊，动不动熄火，后来才发现这车太破教练自己放离合也给油

大部分情况来说，代码真不值钱，值钱的代码都是靠专利和知识产权保护的，所谓跑得了和尚跑不了庙，重点是云厂商别存在啥漏洞可以被第三方获取就好，而 Serverless 再多个账户间应该是完全隔离的，你不用担心运行的过程中被其他代码复制了，思维还是要换换啊，别老是代码代码啥的

而且吧 Serverless 倾向于专注高性能免维护小服务，基本单一部署的不具备啥完整性，你弄过去也用处不大啊

从物理学来说，无线带宽越大的必然频率更高，然后穿墙能力越弱，满负载传输距离也更近，城市高楼的话还有无解的热点太多干扰问题，乡下没啥干扰还好点，有线则有这空间内更高叠加的优势，所以一行就算发展也应该时更多近距离更快无线 ap 节点才是，无论怎样都是有线更靠谱啊

其实吧，如果空间够，距离远各卧室似乎也没必要从弱电箱直拉啊，在楼上楼下再加交换机分就是了，带宽也足够了

@EdmondYoung #10 所以不想抽就别抽呗，其实远没自己想的那么重要，自己所在的边远地区最近几年抽烟的都少了很多了，也几乎没有人会再强行给你的感觉了，大城市那更是，一屋子人你在里边抽烟绝对被人鄙视，没素质没教养，在我们这边其实想融入主动给被人敬烟也就不算失仪异类了，不想拒绝别人那就都接下来，但是别抽带走了处理了就是，反正也没人说你一定要在现场抽完吧，酒文化倒是重一些，串个门都先来三杯，大不了再看看情况适量多敬几轮酒就是了

抽烟绝对陋习，看不顺眼就看不顺眼呗，理他个锤子，谁硬要塞那么这种人还是趁早拜拜了吧，而且吧有其他人的情况下还在室内抽烟也真真是绝对没教养没礼貌的恶劣行为，极其令人生厌

适量喝点酒还可以理解，虽然强行敬酒灌酒也是陋习，但是适量喝点酒确实可以快速融入，对身体也不算啥大坏处，可以理解

对用户 ID 进行加锁就是了啊，如果复杂业务的还可以以一系列信息生成 hash id 来加锁，除了多线程常规的单进程锁外，也可以用 redis 、zookeeper 之类的外部服务来加锁也很方便的

https://github.com/snower/slock

用 go 实现过一个能用于此种场景的小服务，能实现锁的语义还挺多的，性能也不错

serverless 最大的特点本身就是把算法由被动等待服务变成主动服务，部署运维那些就不说了，对于云服务商来说资源利用率更高，对于你来说那些 90%不使用的时间都不用付钱了，再者互联网渗透率进一步加深后，空闲时间和繁忙时间两级差距进一步拉大，算法可以无状态自动化扩容自我维护这真的太需要了

虚拟主机完全没法比，且不说自动扩容免维护了，资源隔离都做不到，更别说啥资源利用率，说个锤子

SAE 算是不错了，但是其设计之初完全是基于 IDC 时代减少手动维护的思路设计的，并非是现在云和智能化运维思想的产物，其资源利用率，可维护性并没用得到很大进步，这也是价格还是很贵的原因之一吧，这就好比 SAE 勉强由手工时代进步到小作坊时代，serverless 则是流水线自动化大型工厂，没法比

而且可以预见，未来必定进一步完算法和运行环境分离，数据就是权力与资产，那么爆炸性的数据增长和极低门槛数据融合的进一步需求必然增加，serverless 或许是一个不错的基础

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

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

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

如果你的意思是很多大 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 、无线投屏、智能家居设备啥的用起来体验下降太多了