1.360 安全卫士就是喜欢改各种浏览器首页，这没得洗。

2.360 安全卫士很多小工具，又特别好用。比如流量防火墙里的查看连接，比如云查毒，比如软件管家一键把所有软件升级，比如流氓软件的拦截等等，我至今没找到更好的替代品。

3.综上，利弊分析后，我建议留下 360 安全卫士，容忍它修改首页以及偶尔弹广告的小问题。

小插曲，上次我也因为这个问题，想直接换 Google Chrome 了，但我发现：

Google Chrome 没办法双击关闭 tab 标签，试了很多扩展都不行。用按键精灵的方案我觉得过于奇葩不能忍。

Google Chrome 很多功能与服务都需要梯子，没梯子的话算个残疾。我虽然有梯子，但频繁切换也很烦。

4 个端以下走向日葵，安装后登陆，设置无人值守。虽然我对贝锐科技没啥好感，但它公司产品的入门版直接免费，的确很厚道。

4-50 个端用 zerotier，电信网络实测没问题，国内公共 moon 节点貌似是在上海，转发带宽足够，良心。

50 个端以上考虑 frp + 云主机吧。不建议用 openvpn 组网，连我这种高手都对 openvpn 的配置与安装烦得要死，普通人估计得炸。

@lance26

比如在 linux - eclipse - cpp 环境下，要创建一个容纳 6 个 ascii 字符的 char 数组，然后脑子一热，写成：char * charArray = new char[6]....

正确答案应该是 new char[7]，因为 C/CPP 的 char 需要一个额外的 0 来作为结尾，平时 string 用多了容易忘记这破事。

这种问题，linux - clipse - cpp 与 太阳系最强 IDE：Visual Studio 都没办法给出智能警告。

招式永远会变动，但基本原理却常年只是那些。

建议花时间把底层原理与细节，弄清楚，这样就算出了新玩意，也能大概率地从新玩意的字面意思猜测运行原理，接着推算出新玩意的优缺点，然后就可以考虑新玩意的最佳实践方案了。

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

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

(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 。

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