有些人会觉得，压测不就是一两台渣渣服务器，甚至渣渣 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.他们老板来联系你，你想拒绝别人，但又不想伤和气。

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

上面一堆人还没搞清楚原因就给建议..

1.Mysql 支持事务但性能不够，Redis 性能够但不支持事务。

2.Redis 性能之所以够用，本质是因为相对于 Mysql，Redis 砍掉了数据安全与事务功能，这样全跑在内存里，又不要考虑事务，速度不快才怪。

3.题主的需求：Mysql 数据更新之后，要求 Redis 必须和数据库一致，本质上是要给 Redis 增加事务，还要让 Redis 接受 Mysql 的控制，这是不现实的。

================
几种方案：

1.Mysql 数据只做新增，不查不改不删，然后推送到 Redis，Redis 做只查，然后允许 Mysql 与 Redis 存在短期内的不一致。这是大厂，包括谷歌的标准玩法。

2.有钱能增加机器，并且业务支持并行写入或并行读取，则可以根据业务，把系统设计为对并行写入优化但会增加读取时间，或者设计为对并行读取优化但会增加写入时间。

3.非常有钱，直接上 Oracle 最新版，支持内存表，虽然没 Redis 快，但比 mysql 快得多，还支持事务。

这种问题，建议按经济实力去考虑。

1.如果经济条件欠发达，建议用时间换成本的做法：

3 个表：用户表、关键词表、关键词与用户对应表。

每个表都不能有重复的，来节约存储空间与内存，但牺牲的是计算量、计算时间。



2.如果经济条件发达，玩法就完全不一样了，核心原则就变成了节约时间：

2.1 用户数据相关的 2 种表：

2.1.1 用户表：
可以重复的用户表。用户数据录入到这个表，但不从这个表取数据。

不可重复的用户表，数据是从上表，通过最终一致性 + 散列分布式 + 流式处理到该表里。数据取出也是从这个表取，这样子处理，取出速度最快。

2.2.2 用户-关键词表：
该表本质是用于节约时间，是一种冗余表。这种表也同上，做两款，一款拿来录入数据，允许重复；一款拿来高速取出数据，不允许数据重复。

2.2 关键词数据相关的表：
同与上面的用户数据表，一共 2 种：关键词表与冗余的关键词-用户表。做法也同上，每种表也做重复与不重复两套。


总结一下，以上一共 8 个表，为节约时间服务，也就是为高速取出数据服务，牺牲了存储空间与内存。

另外，如果存储用的是高级存储设备或做了软阵列或分布式副本提速，需要考虑数据录入速率与存储底层条带化结构（ raid 0 ）或分布式散列结构的关系，以及数据取出时与存储底层镜像化（ raid 1 ）或分布式副本化的关系。也就是在读写时，画个流程图，思考一下底层存取逻辑与读写性能的关系。

你可以自己写个程序，生成 16 位大小写加符号的密码。理论上，除非量子计算机，否则全球计算机一起破解，以现在的算力，百年内破不了。

当然，这种密码，不方便记忆，也不方便存储。

对此我有更好的建议：

自定义前缀 + 可记录的包含大小写 /符号 /数字的复杂密码 + 固定算法加盐。

其中自定义前缀与固定算法，要选方便背诵的，记在脑子里。

固定算法还要选方便口算的。


举个例子，对于本站的密码：

自定义前缀：passWd2020 。这种好背诵吧？背诵下来，别写在任何纸质笔记本上，也别写在云笔记里。

可记录的包含大小写 /符号 /数字的复杂密码：v2Ex_#xH9dY7 。这种密码，可以写在纸质笔记本上，也可以写在云笔记里。

固定算法：把密码的最后一位，如果是字母，则大小写翻转，然后结尾再加固定字符串"2333"；如果密码最后一位是数字，则加上乘以 4 的 intToString 字符串，再加固定字符串"2333"

因为密码最后一个数字是 7，因此乘以 4，intToString 后是"28"，再加"2333"，因此固定算法产生的最终字符串为 282333

最后，拼起来：

passWd2020 + v2Ex_#xH9dY7 + 282333

这种密码方案，既安全，又能记录在云笔记里。

1.中国的广告，很多多少夸大其词，不止拼多多。以前淘宝与京东都有类似行为。

2.拼多多在这些优惠方面，是比较坑，但是它的月卡是真的香，而且拼多多上面很多与京东同类的产品，是可以以 5 折-7 折价格买到。

凡事都有优缺点，成年人看问题要全面。

传统软件功能多，业务复杂。一旦复杂起来，就很难追求极致的性能。这是软件开发的原理，没办法的。

Blackwater 如果发展起来，功能增多后，同样也会面临这个问题。

看看早期的 nginx 、redis 、mongodb 、mysql，Java 、.Net 、CPP，甚至 CPU 、GPU 的发展史，也都遇到过这些问题。

这个分人来看的。

有些人是天生喜欢小朋友，有钱又有闲，这种人要孩子是对生活质量的提高。

但反之，就绝对不建议要小孩了。

我买房买车都是全款。

原因很简单，省事。买完就不用操心了。