从上面看来：

1.楼主不懂婚恋。

懂就不会找这样的妹子，懂就不会来这里咨询。楼主 800 天前发了差不多的帖子，这么多天，也不去认真学学婚恋知识，到现在还是这个样子。


2.楼主很自私且双标。

7 楼的发言，楼主觉得 3 、4 个小时车程近，那楼主倒是搬到妹子的城市去生活。

39 楼，这种答案这么明显的问题，还要问出来？


3.楼主甚至没把对方当人看，可能只是缺个炮友。

不然，就不会有 48 楼这种，只想谈个恋爱的发言。你这不是只想谈个恋爱，你这只是想睡妹子，又不想负责。

@singerll

1.首先感谢大佬推荐。

2.Windows 那边也有一个相同的东西，叫老毛桃 PE 。

3.用老毛桃 PE ，在 Windows ，对 U 盘进行制作，可以制作开机 U 盘。

4.制作后，U 盘下面有个叫 LMT 的文件夹。可以把需要的 ISO 全部拷贝进去。

5.然后用这个 U 盘开机，会先进入到老毛桃 PE 的 DOS 菜单，有一个选项是进入 LMT 文件夹，然后选择需要的 iso ，进行引导。

6.很多标准的电脑，新电脑，都支持这种方式。

7.但是！！！有些服务器、老电脑、mini 主机、特殊系统，不支持这种模式，用这模式引导后，会报错说找不到分区，或找不到文件。

这类设备，它们只支持最老式的，也就是一个 U 盘对应一个 iso 这种启动 U 盘。

所以，我会做两手准备，第一是肯定要有个老毛桃和你推荐的 Ventoy 这类 U 盘，方便嘛。但为了兼容性，我另外也会做一堆老式的一个 U 盘对应一个 ISO 这种，为的是兼容性。

对于一个合格的计算机大佬，我认为，必须有一大堆 U 盘，并且每个主流 Linux 发行版，都有一个专用的 U 盘。

现在 U 盘白菜价，但刻录 U 盘需要花很多时间。提前准备好吧。

1.肯定需要。

2.Linux 系统与环境的安全与升级，由运维去做。

3.Linux 系统中运行的用户代码的安全与升级，由代码的开发公司去做。

4.更简单的方法是，对服务器区域的入口，购买第七层（应用层）防火墙，比如入侵检测、WAF 这种，能分析 http 与 https 的具体流量内容。

而不是第 3 层像 iptables 或 firewall 那种。

然后做好配置与自动升级，关键是出事后可以由防火墙厂家担责。并且这些厂家也有专门团队去跟着 0day 并及时下发最新的补丁包。

5.做好等保，出事了有等保担一部分责。

另外，楼主发明的这玩意，我并不关心，因为工程中如果出现这种情况，我直接用 Oracle 整一张自增 ID 主键的表，一 一对应就行了，或者直接对 Content 集合来个 gzip -9 。

还要去找半天楼主说的这种单射函数？

吃饱撑的？游戏不好玩吗？？

另外，楼主发明的这玩意，我并不关心，因为工程中如果出现这种情况，我直接用 Oracle 整一张自增 ID 主键的表，一 一对应就行了，或者直接对 Content 集合来个 gzip -9 。

还要去找半天楼主说的这种单射函数？

吃饱撑的？游戏不好玩吗？

1.哈哈哈哈哈哈，我认真看了一下楼主两篇帖子，以及他贴出来的国外大佬的文章，以及维基百科的词条...

我突然发现，楼主说的 hash ，与我们常用的 hash ，根本就不是一回事...


2.我们所说的常用 hash ，比如 MD5 、SHA1 等，是把一个数量未知可有限可无限、每个元素长度也未知且可有限可无限的集合，映射成数量已知、每条元素长度也是固定大小的集合，这样必然会有冲突。

拿 MD5 举例：

md5( 123456 ) = 827ccb0eea8a706c4c34a16891f84e7b

md5( aabbccddeeffgghh ) = 12e95c254d1c532e0d55e765731d8f89

md5( 啊啊啊啊啊啊啊啊啊啊呸 ) = 0fffbe633a0e4060545775e84788d648

左侧包含元素 123456 的集合，元素数量可能只有 10 个，也可能是无限数量。

而右侧包含元素 827ccb0eea8a706c4c34a16891f84e7b 的 MD5 结果集合，按照 MD5 的定义，元素数量最多只能是 2 的 128 次方个，而且每个元素的长度是固定的 128bit ，或 32 个 16 进制。


3.但楼主所说的完美 Hash：

https //en.维基百科.org/维基 /Perfect_hash_function
上面这个 URL 触发了网站屏蔽，所以只能以这种形式发出来，大家应该都懂真实 URL 吧？

是把已知元素数量（无论是否数量为无限个）、已知每个元素的集合，映射成一个元素数量比率差不多的序列，当这个序列总体长度达到数学证明的最小约为 1.44 Bit per key 时，就是最小完美 Hash （文中的 Minimal perfect hash function ），但目前已知算法，只能达到 1.56 Bit per key 。

举个例子，以下的一张表 Table ，由 2 列 组成。第一列是从 1 开始自增且唯一的主键，第二列是长度与内容都看上去像是随机，但其实是已知的字符串集合：

ID （ Key ） Content
1 123456
2 aabbccddeeffgghh
3 啊啊啊啊啊啊啊啊啊啊呸
..... ......

现在的情况是，已知右边列的内容，已知左右两列肯定有一种对应关系，但不知道左边的具体值。现在需要通过一个算法，从右侧字符串，计算出左侧 ID：

123456 -> Minimal_perfect_hash_function( x ) -> 1

aabbccddeeffgghh -> Minimal_perfect_hash_function( x ) -> 2

啊啊啊啊啊啊啊啊啊啊呸 -> Minimal_perfect_hash_function( x ) -> 3

这特喵的就是楼主想说的东西。

Minimal_perfect_hash_function 与 我们常见的 MD5 、SHA1 这类哈希，根本是不同的东西，只是名称中都包含了 HASH ，于是大家先入为主地，以为楼主在说 MD5 、SHA1 之类的主流哈希算法。楼主这种其实更像是根据 value 反推 ID key 的 index 查找算法。

最关键的一点是，楼主说的这种 Minimal_perfect_hash_function ，当第二列 Content 的长度是无限时，计算出来的 ID 列的结果集的长度也是无限的！而 MD5 、SHA1 ，就算 MD5( x )，x 集合是无限的，但计算出来后，结果集的长度是有限的。这就是最大的区别。

Perfect_hash_function 是单射，

MD5 、sha1 不是单射！

现在的情况是，已知右边列的内容，已知左右两列肯定有一种对应关系，但不知道左边的具体值。现在需要通过一个算法，从右侧字符串，计算出左侧 ID：

123456 -> Minimal_perfect_hash_function( x ) -> 1

aabbccddeeffgghh -> Minimal_perfect_hash_function( x ) -> 2

啊啊啊啊啊啊啊啊啊啊呸 -> Minimal_perfect_hash_function( x ) -> 3

这特喵的就是楼主想说的东西。

Minimal_perfect_hash_function 与 我们常见的 MD5 、SHA1 这类哈希，根本是不同的东西，只是名称中都包含了 HASH ，于是大家先入为主地，以为楼主在说 MD5 、SHA1 之类的主流哈希算法。楼主这种其实更像是根据 value 反推 ID key 的 index 查找算法。

最关键的一点是，楼主说的这种 Minimal_perfect_hash_function ，当第二列 Content 的长度是无限时，计算出来的 ID 列的结果集的长度也是无限的！而 MD5 、SHA1 ，就算 MD5( x )，x 集合是无限的，但计算出来后，结果集的长度是有限的。这就是最大的区别。

Perfect_hash_function 是单射，

MD5 、sha1 不是单射！

3.但楼主所说的完美 Hash：

https://en.维基百科.org/维基 /Perfect_hash_function

是把已知元素数量（无论是否数量为无限个）、已知每个元素的集合，映射成一个元素数量比率差不多的序列，当这个序列总体长度达到数学证明的最小约为 1.44 Bit per key 时，就是最小完美 Hash （文中的 Minimal perfect hash function ），但目前已知算法，只能达到 1.56 Bit per key 。

举个例子，以下的一张表 Table ，由 2 列 组成。第一列是从 1 开始自增且唯一的主键，第二列是长度与内容都看上去像是随机，但其实是已知的字符串集合：

ID （ Key ） Content
1 123456
2 aabbccddeeffgghh
3 啊啊啊啊啊啊啊啊啊啊呸
..... ......

2.我们所说的常用 hash ，比如 MD5 、SHA1 等，是把一个数量未知可有限可无限、每个元素长度也未知且可有限可无限的集合，映射成数量已知、每条元素长度也是固定大小的集合，这样必然会有冲突。

拿 MD5 举例：

md5( 123456 ) = 827ccb0eea8a706c4c34a16891f84e7b

md5( aabbccddeeffgghh ) = 12e95c254d1c532e0d55e765731d8f89

md5( 啊啊啊啊啊啊啊啊啊啊呸 ) = 0fffbe633a0e4060545775e84788d648

左侧包含元素 123456 的集合，元素数量可能只有 10 个，也可能是无限数量。

而右侧包含元素 827ccb0eea8a706c4c34a16891f84e7b 的 MD5 结果集合，按照 MD5 的定义，元素数量最多只能是 2 的 128 次方个，而且每个元素的长度是固定的 128bit ，或 32 个 16 进制。

1.哈哈哈哈哈哈，我认真看了一下楼主两篇帖子，以及他贴出来的国外大佬的文章，以及维基百科的词条...

我突然发现，楼主说的 hash ，与我们常用的 hash ，根本就不是一回事...

建议先玩一下 Factorio 这款游戏，以可视化的方式展示这类问题。

@msg7086

1.软件问题：

1.1 软件不可能是 100%稳定的，无论是 ESXi 还是 PVE 或者别的什么。

1.2 正版软件比盗版稳定，主要是 3 点：有补丁、有培训、有厂家技术支持。

1.3 软件系统有个通病，功能越多，越复杂，测试调试也越麻烦，测试能覆盖的百分比越低，软件系统也越不稳定。一旦炸了，就越容易丢数据，越难恢复。

特别是 VMware 企业级的备份与恢复，还是 EMC 提供的技术支持，这种跨了厂子，更容易出问题。EMC 的备份软件来备份 VMware ，以前老版本会小概率失败。

VMware 全家桶的功能比 PVE 要多得多，如果从功能数量上来说，VMware 全家桶，如果炸了，说不定比 VirtualBox 还要麻烦，根本就不需要和 PVE 比。

就像我回复楼上某个弟兄，如果能用 Docker ，尽量别用虚拟化。


2.供电问题：

2.1 机房供电理论上无法做到 100%保障，就像数据备份一样，谷歌推荐 1 份数据至少要有 3 个副本，也只是说企业级常用情况下足够了，并不是 100%安全。

2.2 你客户的机房供电问题，是你客户的不专业造成的，这事与你没啥关系，你也不需要帮他们洗。

2.3 你的客户，我盲猜要不是不专业，要不就是为了高性价比，做成了以下结构：

一路市电 + 发电机 -> UPS -> 机架 -> 服务器，这样导致只要一环炸了，服务器就全炸。而且服务器的两路电源也成了摆设，这种结构早期国内大多也是这种情况。

注释：正规服务器至少有 2 个电源，任意一个电源单独工作都可以给整个服务器供电，任意一个电源挂掉都不影响服务器正常工作。

但这种结构，优点也很明显，就是节约钱，并且各种半吊子电工也能搞定。

后来专业的商业机房供电，一般是 2 路，结构如下：

市电 A + 发电机 A -> UPS A -> 机架 PDU A -> 服务器电源 A

市电 B + 发电机 B -> UPS B -> 机架 PDU B -> 服务器电源 B

注释：PDU 是专用于机柜的高档插排。

这种结构，就算是炸一路，服务器也能正常工作，虽然不是 100%保障，但我目前还没听说过，这种结构导致全炸事故。


3.逻辑问题。

3.1 我在 27 楼引入 VMware 全家桶这个概念，是因为你在 23 楼拿 VMware ESXi 与 PVE 比较。我认为这种比较，对 VMware 不公平，因为它们不是对等产品。

3.2 断电丢数据，本来就是理所当然的事情。因为除了系统设计上支持断电之外，没有哪个系统与软件，能保证自己断电后仍然正常，包括地球上 TOP 1 数据库：Oracle 。

3.3 一个系统，在设计与实现上，是可以支持断电不丢数据的，但这是一个系统工程，需要从硬件、操作系统以及软件、数据库等各层次都要进行专门设计，甚至硬盘也要修改业务逻辑，并且系统整体性能会很低，不丢数据也并不是说业务没问题，掉电前最后一部分业务也会快速失败。这套系统因为性能低，所以在经济上不可行，大部分通用系统与软件，不会去这样设计与实现，而是希望外部环境去保障不断电，同时通过备份来保障数据安全性。目前很多系统甚至有一种叫 CDP 的技术，每隔 3-5 秒进行一次差异备份，然后每小时进行一次差异备份的汇总。

3.4 我说我做过虚拟化设计，是针对你在 54 楼，你说你做了很多年的 VMware 二开、运维、安装、处理问题。你想通过这些证明你对 VMware 问题比我熟悉，质疑我的专业性，质疑我是在胡说八道，我才解释这些，来说明我是在认证和你讨论。

@msg7086

1.我想当然？我拍脑瓜假设？？别双标好吧老弟？

你在 34 楼提出：就稳定性来说 vCenter 和 PVE 真的是不能比。你这不是想当然？你这不是拍脑袋假设？然后我在 35 楼问你要证据，你给过没？


2.你真的回答问题了？

你在 34 楼提出：客户大概有 20%的时间是 vCenter 炸了、VMFS 也经常炸，我在 35 楼问你具体原因，

你在 36 楼说 ESXi 会紫屏崩溃，你觉得这是回答？你要想怪 ESXi ，你得找出 ESXi 为啥紫屏崩溃。找出原因后还要进行 AB 测试来验证这种说法。


3.你真的懂全责划分？

连机房电力供应出问题，导致丢数据，导致虚拟机损坏，你把这锅丢给 VMware ？


4.你真懂机房供电问题？

你说 UPS 的配电板挂了，服务器就断电，那请问服务器的冗余电源是怎么接的？市电与发电机就没独立的配电板了？

所以我在上面说了，客户不专业，没经过培训，配个电都不专业，这锅还甩给 VMware ？

正经的机房，是多路供电的，这你知道吗？至少要有双路市电、发电机、UPS 。3 路供电不说百分百 SLA ，总比你说的那些炸一路就全炸的客户机房要强吧？


5.当你不了解别人的情况下，别轻易觉得自己咋滴咋滴。你只是给 VMware 做二开，只是装过 ESXi 与 vCenter ，说白了你就是个产品用户而已。我都不好意思说我大二在不知道 VMware 的情况下，就把它最初的那一套虚拟化、自动化伸缩扩容的东西设计出来了，你明白用户与设计者的差距吗？

你以为三甲就靠谱？好几年前，托关系去某三甲找了某病最好的教授，开的药我也照单全收。

但我吃药前，会自己先去查询禁忌症，结果发现一堆严重问题，这教授也没给我说，会有这些严重的禁忌。

养老诈骗是真的毁了很多家庭，2 个月前，一个国企退休男职工，他老婆就是上了情感骗子的档，把家里的储蓄全被骗了，还贷了很多款。

最后这女的自 sha 了，留下了老公和孩子。

楼主你只是被封号，很多人是家破人亡。

你能吃苦从电路开始学起嘛？

@CatCode

1.测试肯定是 ESXi 、PVE 这类彻底虚拟化的系统更方便，有一种玩法是：

高主频 CPU + 高主频内存条 + m.2 nvme SSD raid 0 ，可以打在线快照（开机时打快照），极端方便。比如你打个在线快照，接着 rm -rf /，然后立即恢复，机器配置好，甚至可以做到秒级恢复。这个问题上，Docker 就不合适。

2.但是，高性价比、快捷地部署生产系统，docker 却又比是完胜。因为目前虚拟化发展到现在，出现了各种妖魔鬼怪的平台，除了大家在上面提到的 ESXi 、PVE 、Hyper-V 之外，还有阿里云、腾讯云、百度云、华为云、电信天翼云、联通沃云、移动云、深信服信服云等等。

这些云中，很多云为了设置门槛与壁垒，不支持通用虚拟机文件，互不能导入整体虚拟机，有些云甚至连 ghost 备份出来的 xx.gho 这种磁盘文件，都无法进行恢复。

所以，这种情况下，docker 就成了快速导入、导出、部署的最佳选择了。这么多云，今天这个云做活动，明天那个云又降价，后天这个云又涨价。用 docker ，甚至可以做到像高频交易一样，在高性价比的云里反复横跳，给公司或工作室节约大量的资金。