物联网业务，要确保的是各种智能设备的稳定性、低负载与低功耗。

从这个角度来说，智能设备与服务器的数据交互模式应该是，服务端把新增或修改的配置信息发给智能设备，智能设备根据配置信息里的数据采集规则，主动向服务端推送。这样做的好处是：

(1).如果智能设备负载过高，它可以通过降低数据推送频率来保持稳定。不然如果是服务端主动采集的话，智能设备可能会因本来就负载过高，还得响应来自服务端的请求，很容易挂掉。另外，如果智能设备功耗过高，或剩余电量不足，它也可以自行调节数据推送的频率，来达到降低功耗，或增加续航时间的目的。

(2).由于智能设备，把数据推往服务器的时间，通常设定为整点时间，比如 14 点 10 分 00 秒，那么服务端在处理接收数据的负载问题上，很容易出现差异很大的峰值现象。也就是说，对于服务端来说，要不在某一刻会同时接收到几乎大部分设备的推送数据，要不在某一时刻干脆就彻底闲着，因为没啥设备推送数据。比如：14 点 10 分 00 秒，1000 台智能设备同时推送数据，导致服务器负载 95%；然后 14 点 10 分 0 秒 - 14 点 19 分 59 秒，整台服务器负载却只有 1%；到了 14 点 20 分 0 秒，智能设备又同时推送，服务器负载飙升。

这问题的本质，同于春运，解决方法只有 2 种：

如果需要保证数据质量，就只能提供消化峰值的足够算力。这需要砸钱配置尽可能多、尽可能强的服务器或服务器集群；

要不，就降低数据推送频率，以及错峰推送，来降低项目预算。错峰推送的意思是，比如：

14 点 10 分 00 秒，ID 为 1-10 的 10 台设备进行数据推送。

5 秒后，

14 点 10 分 05 秒，ID 为 11-20 的 10 台设备进行数据推送。

5 秒后，

.....

玩音乐，能达到看谱演奏的水平，保持下来，就很开心了，谨慎再向上点技能树。因为这个阶段，是性价比最高的，既能泡妞，又能自己开心，还能录个演奏乐器小视频什么的发发 B 站，而且还不花什么时间。

再往上，就非常烧钱烧时间了。

比如乐器方面，钢琴必须精通，需要达到闭眼盲奏水平，就算演奏功力不咋地，郎朗与李云迪那种演奏气势与姿态你得好好学学。这个阶段，基本上是别的哥们网吧通宵，而你得在琴房通宵。其他东西方主流乐器，比如小提琴、二胡、笛子、爵士鼓、吉他、古筝、琵琶之类，也都要达到熟练级别，为后面的技能树做铺垫。特别是冬天练乐器，还得先用温水暖手，每天都要保持几个小时的练习时间。

再往上就是作曲编曲，这个阶段需要进行大量的理论学习、扒谱实践、创作实验，以及各种作品分析，费脑费耳。同时还需要烧钱砸器材，去做录音混音的研究与实验，才能保证心中所想的音乐能够很好地呈现出来。但这个阶段也很有意思，使用各种音乐软件、软硬音源、效果器，以及各种录音设备，基本上可以把心中所想的曲子，做成成品，发到 B 站，收获一帮只会在弹幕里扣 6666 的小可爱。

再往上，写交响，指挥乐团。当幕布缓缓拉开，聚光灯打在你肥胖而又秃顶的脑门上。你昨晚还在实验室帮学妹增加数组越界的 bug，现在却要强行睁开疲惫的睡眼，指挥着整个乐团，演奏你自己创作的曲目。乐团里，一边看着最听话的学姐女朋友，一边欣赏着高颜值且前两天还和你偷偷上过床的女神学妹向你投来的微笑，玩音乐的凡人能达到的人生巅峰也莫过于此。

不过到了这个地步，已经算是把时间与资源浪费的差不多了，我总觉得，这些时间与资源，拿来投入到研究金融、公司运营中去，可能会让你更快达到破产边缘。毕竟大学一毕业，这些高级音乐技能树，除了逢年过年给单位领导同事们助助兴，就没啥作用了。

我把 18 位，理解为由 18 个[a-z0-9]组成的字符。因为如果 18 位指的是 2^18，那就啥都别做了。

18 个由[a-z0-9]组成的字符，那就是 36^18，大约 2^93 次方。

两种方法：

第一种方法，限制没毫秒内调用次数，直接借用 Twitter 的开源分布式 ID 生成算法：snowflake 。
41bit 时间戳；

12bit 的毫秒内序列号（每毫秒最多调用 4096 次，如果需要更多次数，可以放大这部分的长度）；

以上这两者，在每秒最多 4096 次调用内，保障了全局唯一。那么剩下 40bit 你自己随便找个快速 hash 算法，然后截取前面 40bit 就行了。


第二种方法，不限制每秒最多调用次数，但限制总长度。

x Bit，从 1 开始的自增 ID，x 为 2^x 的长度，由自增 + 放号业务来保障全局唯一。

剩下 93-x，随便找个快速 hash 算法，然后截取最前面的 93-xbit 就行了。

本质上是因为睡眠唤醒功能，用的很少，所以就算有 bug，因为没人提，或提的人少，软硬件厂商都不愿意去改 bug 。

睡眠唤醒，我自己经历过的，就有鼠标、键盘、USB 等设备不能用；或者唤醒后要卡半天；甚至唤醒后直接蓝屏，等等。

建议不要用睡眠唤醒，用云桌面或虚拟化的暂停运行都比睡眠唤醒稳定。

@xzour 我的意思是，只要不在程序里 for 循环然后一条一条去查就行了。存储过程是我建议的方式，你用其他方式也行。总之瓶颈不要被限制在数据库客户端驱动的 rpc call 就行。

不要那么丧气。

首先，投胎为人类，已经是最大的幸福了。人类**每天**消耗的鸡鸭鱼牛羊猪等动物，总量等于整个一战二战人类牺牲总和。注意，这是每天的量。

其次，基因是有分工的。大概 1%-5%的高颜值群体，是拿来繁衍后代，其他的全部都是工具人。而且高颜值群体天生就有排外性，为了保护基因，DNA 会让他们歧视低颜值群体。这就是为什么美女看不上一般人的本质原因，这是多少年积累下来的自然发展规律，并不是说一个颜值普通的人，成功后就一定能让美女死心塌地爱上自己，这从基因角度来说，并不现实。

接着，基因使用突变来让生物在繁衍中，应对环境的变化。这些基因突变，有些是良性的，比如智商变高。有些却是有害的，比如易胖，等等。这完全是抽奖。所有人有高矮胖瘦，有智商高低。

最后，我们现在所处的时代，已经够幸福了，想想那些兵荒马乱的战争年代，能吃个饱饭已经是过年般的幸福了。一战二战离现在才多少年。

综上，按自己喜欢的生活方式，遵纪守法，适当注意身体健康，开心就好。

事前预算，事中记账，事后总结。

预算是指，在每个时间周期，对周期内，各项需要花钱的地方，定好最大额度。比如买口红，每个周期限制最高 300 元； Steam 买游戏，每个周期限制最高 200 元。

结算是指，在每个周期后，拿记账本，对着预算，进行对比。没花超就继续努力，花超了就总结原因与调整下次方案。

不懂理财，自控能力差，周期就短一些，比如每月一次周期，甚至每周一次周期。懂理财，有自控力，就按年。

程序开发，建议买 21.5 支持壁挂的显示器，组屏幕墙，至少 2*2 （上下 2 层，每层 2 个）。

支架推荐：
https://item.jd.com/8715403.html

如果是架构师、高端程序或高端测试，那么至少需要 3 * 3 。

这年头，显示器、支架、多输出的主板与显卡并不贵，而且显示器数量提高了，工作效率会有质的提高。

有些人会觉得，压测不就是一两台渣渣服务器，甚至渣渣 PC，跑几分钟的 LoadRunner 或 Webbench，成本 1 元电费，不就行了？

但换个行业来说，比如火箭或飞机，只是测测发动机，一次几十万元起步。

直播测试也是如此。它不同于普通的网站压力测试，直播测试，需要很多客户端，客户端的带宽与设备也不便宜。测试成本可不低。

这种大型测试，对于开发公司，养这种团队与设备，性价比太低。建议去找专门的测试公司，去询价。

另外，你们自己测试的直播页面卡顿，要分析一下，到底是：

你们公司带宽问题？

阿里云服务器的带宽问题？

阿里云的直播组件性能问题？

你们公司收看直播的电脑设备性能问题？

等等..

@Kasumi20 如果嫌弃老师讲的不好，可以自学，可以找别的老师问。

就算所有老师都答不出来，可以问谷歌。

有些东西，比如 64k 的仿 CS 游戏，比如 12306 架构问题，去问老师，的确有些为难他们了，但绝大部分基础问题，一个学校里的计算机学院，总会有老师知道答案。

1.C/Cpp 以及传统主流数据库，对于 1000 * ( 1000 + 1000 )规模的两层 for 循环或游标遍历，甚至 1000 * 1000 * 1000 规模的 3 层循环或游标遍历，根本毫无压力。

如果有瓶颈，需要分析瓶颈在哪。

比如常见的错误实践，在编程语言中这样写：

for
----for
----.----for
----.----.----string SQL = "SELECT *....";
----.----.----db.search(SQL)；

那么主要的瓶颈就在 [db.search(SQL)；] 这条语句这里，具体一点就是编程语言的数据库客户端驱动，与数据库的接口调用这里。这种问题需要把程序逻辑全部移动到数据库的存储过程里，然后编程语言这边对数据库进行一次调用，瓶颈就解决了。


2.就算不改这些东西，总体时间也只是 30 分钟的话，可以考虑增加 N 台服务器，把数据分为 N 组，每台跑一组，这样总体时间可以缩减到 30 分钟 ÷ N + 汇总时间。

目前通道类的信息安全，根本不需要改端口以及密码错 N 次就封 IP，这些都是那种不懂信息安全的小学生搞出来的名堂。

通道类的信息安全，只需要注意两件事情：

1.密码的复杂度。我在这个帖子的 35 楼已经给出了具体方案： https://www.v2ex.com/t/735788#reply35

2.单一类型通道的 0day 。

通道类型越单一，使用就越方便，被 0day 的几率就越大。

为了安全，可以套两层甚至多层通道，但这样子做，使用就很不方便了。

微服务这功能，从本质上来说，首先是软件工程与管理上的问题，目的是为多人协同的大中型软件项目服务，是用增加组件间延时的代价来换取更快的平均运行性能与开发协作效率，所以时延高是必须，是代价，没办法从原理上降低。否则，如果低时延是刚需，那就不应该用微服务，而是单机 + 进程内部调用，这样子延时才会最小化。

其他细节上的问题，楼上的老哥们已经说了。

如果你是正规计算机专业出来的，并且认真听课了，就不会有这些问题。

建议把 985 计算机本科的技能树，按课程设置依次点开，从高数与物理开始逐级向上，贯穿整个计算机与科学发展史，你才能彻底弄清这些问题。因为很多问题是历史发展的问题，没经历过整个历史阶段，很多问题你单独拿出来思考，是想不出啥结果的。

上一批技术老人，大多数不是正规计算机专业，他们对搜索引擎缺少概率与实战经验，只会用现成的产品来搭建系统，甚至连这些产品的缺点都不知道，就算知道了也不知道如何解决。这些人在网络上写了各种误导人的文章，导致后人翻船。

这就是为啥很多电商系统，或者网站什么的，明明某个商品或某篇文章，有那个关键字，却搜不出来的本质原因。

因为在调研阶段，信了这帮老人的推荐，无脑上 ES 。

搜索引擎是一个非常复杂的内容，公司把这个任务交给一个没任何经验的新人，在管理上也是一种失败。

第一个问题的原理是，注册时，通过用户名与手机号，进行唯一性限制。如果客户端先行注册了，数据库那边就存在了该用户名与手机号，浏览器端注册时，发现用户名与手机号已经存在，然后反馈：用户名或手机号已经被注册。

第二个问题的原理是，数据库可以把该操作按业务或架构需求，设置为某种级别的事务性，比如串行，来保证该操作的原子性。就算两个请求是同时达到数据库服务器，因事务的原子性，两个请求任然会被强行分为一前一后，按顺序进行。

第三个问题，passport 服务必须要保证注册业务的事务性。保证不了就换程序员或 DBA 。

出于安全考虑，调试完毕后，要使用文件粉碎机之类的软件，来进行卸载与粉碎。正常卸载有一定风险能恢复出删除数据。

1.中国宽带贵，主要原因有两点。

第一是网络设备没办法完全国有化生产，导致其成本与人均收入之比，比美国高 4 倍以上。也就是说，我国人均忙活一个月，假设只能买一台千兆交换机，美国人至少能买四台。

第二是我国网络基建比国外好，我国要求村村通网，这在资本主义世界是根本无法想象的事情，没人愿意给又穷又偏远的地方建网。

第三是我国网费是公补私，也就是公司与单位贵，来补贴民用。


2.国内很多老板与创始人，创业成功大多是电梯流策略，并不是因为自己真的懂行业、懂管理、懂财务。具体表现在：

不懂算账。比如 IT 企业的核心员工，一天 200-500 元工资，网络却限速，不愿意给足额带宽。导致每天因为几十元带宽成本，企业却要承担其几百元的误工费，这些隐性投资，老板很难观察出来。

不会用人。比如招来的不负责任的网管，为了图省事，直接就按带宽÷人头来进行固定带宽限额，根本没去观察实际带宽用量，没去进行忙闲时的动态调整。另外我参观过很多家企业与公司，网管人均理论素质与职业素质双低仿佛已经是正常现象。

不会按业务进行设计。有些宽带依赖严重的岗位，实际上根本就不适合在产业园或写字楼里上班，因为这里的带宽费用太高了。比如家宽 500M 下行一个月就两三百元，到了产业园或写字楼至少翻 3 到 5 倍。还不如把这些部门直接送到能多线接入的民用小区里去，甚至想办法把民用小区的宽带直接搭到公司里来。

而且很多老板好大喜功，觉得公司做起来了，一定要在富丽堂皇的写字楼里租一层，然后所有员工都在这里上班，满满一屋子的人，看着可有成就感。


3.网络带宽问题，对于普通非 IT 企业来说，有 18 效应：百分之 10 的人，用掉百分之 80 的网络资源。对于个人来说，也有这种情况：百分之 10 的时间，需要使用峰值带宽，其余时间用不上这么多。

最后，我自己都觉得 500M 家宽，已经是我能接受的速度下限了，再慢一点就是带宽跟不上操作。看了上面的评论，很多公司限速在每人 10M 甚至 1M，一个软件下载等一天，贵司真有钱，员工工资仿佛随便开。


4.综上，几点建议。

先把公司针对带宽使用情况，进行划分。人均带宽 10M 以内的，可以划归到企业园区或写字楼，高于 10M 的，划到能进行多线电信家宽接入的小户型居民小区或公寓。建议研发与运维，人均保障至少 50M-100M 带宽，不拖累研发速度。要做这种保障，需要租赁大量支持电信家宽光纤到户的小户型（大户型浪费空间）。

带宽的限速策略建议设置为，按照带宽与人数，保障每人拥有最低带宽，而不是限制每人的最高带宽。比如，有 50 个人办公，接入带宽是 300M，那么人均就是 300÷50 = 6 。流控策略为每人最低带宽保障为 6M，不限最高速度。这种策略，高峰时段每个人能获得至少 6M 带宽保障；闲时或加班时段，公司剩余上班人数可以利用上全部带宽，不浪费。

地理位置有条件的公司，甚至可以把家宽拉到公司来用。具体方法就不说了，因为有一定风险。

1.允许别人转载，本质上是通过舍弃版权利益，来获取成就感。但是你却因为舍弃版权利益，觉得不开心。

所以你的真正需求是：既不舍弃版权利益，又能获取成就感。

那么一种可行的解决方案是：
别搞公众号了，但坚持写文章，把文章写到你自己的小说里，小说不发表。然后在小说里，创造一家公司，然后公司老板来找你合作，你把你写的文章，允许该公司转载。最后，你既能获取成就感，又没舍弃版权利益，一箭双雕。


2.他们老板来联系你，你想拒绝别人，但又不想伤和气。

方法也很简单，你直接告诉对方，不想合作，不想见面。这样就伤和气了。然后你再给别人打钱，钱款等同于你写的东西的价值，这样给予对方补偿，就不会伤和气了。