最早是 IBM 的刀箱，也就是刀片服务器，一个大概 6 - 8 U 的机架式服务器框里，有大概 10 - 12 个薄片的小服务器主板插在里面。这些小服务器使用额外的存储服务器。

这玩意优点是密度高，缺点是太贵了，而且还需要额外的存储。最早的高价值公司，地点喜欢选在地价超高的市中心，然后数据中心又喜欢建造在公司里，相当于每台服务器的占地成本非常高，这种公司就只能选刀箱这种高密度服务器。

现在是云时代，各大云厂商，以及天翼云，基本上都把数据中心建造到城郊这种土地面积很便宜的地方，此时数据中心再选择高密度的刀箱，就属于纯纯有病了。而且高密度的刀箱，其供电、散热、消防成本也很高。

Intel 有个偏执技术狂，以前管理层是哄着他，后来新的管理层也是个愣头青，得罪了他，这人直接去了 AMD ，接着 AMD 起飞了。

后来不知道咋的，这人又回到了 Intel ，只是 Intel 从此没啥大进展，反而 AMD 是越来越强。

江湖不止打打杀杀，还有人情世故。还记得 Intel 不咋重视的协处理器嘛？现在是 AMD 在数据中心的致胜法宝。

这其实是好事。有没有想过，阿里之前敢做全国性质的 DNS ，它这钱哪来的？

阿里系的电子商务的割韭菜，被拼多多干掉，云业务被运营商的低价云干掉，导致整个价格体系回归正常，自然没有余钱再来承建这种全国性质的服务。

@jack778 正确率都差不多，而且每种模型，都有自己擅长的方向与不擅长的方向。

价格并不是问题，能正确回答问题才是关键。目前连 GPT4 、Gemini pro 、Claude 3 等，都还存在各种回答错误，更别提 GPT-4o mini 了。

如果你需要一份严谨的数据文档，至少需要有：数据名称、解释说明、数据类型、数据范围、用法示例、注意事项。从这个角度来说，无论是各种行业规范、软工或系统架构理论，无论各种大公司包括 Google 、IBM 、Microsoft ，无论各种数据库软件比如 Oracle 、Mysql 、PostgreSQL 、MongoDB 等等，在座的各位...都...都没有完全实现这些规范。

每一代数据系统设计师，在面临实际预算与可用开发时间的情况下，都会犯难，对于这个问题，尽力而为吧。

1.FTP 、SFTP 、FTPS 、HTTPS 、WebDAV 、Samba 、NFS 等等，这些是文件共享接口，复制文件时，保留时间信息功能，与它无关。

2.你需要保留时间信息功能，推荐 Windows 下的企业级文件复制工具：SyncBackPro ，它有完整的关于时间的设定，百度有学习版。

1.锁性能的关键在于 CPU 、主板、内存 的主频下限，这是个木桶效应问题。

2.业务量小的系统，不需要考虑这个问题，直接用数据库的序列化事务，来处理这类数据。

3.业务量大的系统，不靠数据库来处理，而是在系统的设计阶段，就会根据第一条的机器性能，把业务进行拆分，拆分到不同的业务集群里。举个例子，用户注册的用户名唯一性查询，会按照首字母 + 数据量，进行物理数据库服务器拆分，并且这类物理数据库服务器，会选用高频设备：高频 CPU + 高频主板 + 高频内存。

先把需要处理的情况，全部罗列出来，然后挨个处理就行，举个简单例子：

1.当用户在前端，比如网页版群聊，发送一条消息时，该消息立即被渲染在前端页面，接着开始处理消息发送逻辑，同时在页面上显示该消息的状态。状态示例：
状态 1：正在发送到后端
状态 2：发送到后端失败，失败原因：XXXXX
状态 3：后端已收到数据，后端正在处理
状态 4：消息成功发送（后端处理完毕）
每种状态有自己的图标。

2.发送频率太快，则该该消息显示为状态 2：发送到后端失败，失败原因为发送频率太快。

3.网络中断，或后端服务未启动，则该消息显示为状态 2：发送到后端失败，失败原因为网络问题或后端服务未响应。

4.后端已经收到数据，后端开始处理，则该消息显示为状态 3：后端已收到数据，后端正在处理。

5.后端回复说数据处理完毕，则该消息显示为状态 4：消息成功发送（后端处理完毕）。

NAS 这种玩意，定位是家庭数据中心，这种定位是无关数据重要性的，默认数据丢了无所谓，大部分 NAS 设别，连个 ECC 内存都没有，定期数据清洗也没有，商家为了赚钱，是不会告诉你这些的。

如果你真的关心数据，需要按照企业级数据的办法来做：

1.所有设备必须上 ECC 内存。

2.所有数据必须要有额外的校验数据，不能简单的进行镜像。

3.所有数据必须要有 3 副本。

4.必须要有定期的全盘数据清洗。

你思考一下，当你的数据上了这一套后，这成本，你能否扛得住。

1.与费用有关的，多开会，多做记录，是正确的做法，因为这能在发生事故后进行全责分摊。毕竟人无完人，对于复杂事情不可能考虑周全，发生麻烦事情在所难免。

2.不过，你这情况，才 5 个显示器，是否有些儿戏，系统设计 + 流程图 + 编码 + debug + 查资料 + IM 协作，5 个显示器是不够的。建议至少上 10 个显示器，21.5 寸壁挂屏 + 上下显示器支架。如果有条件，可以考虑 12 个屏。

1.洋垃圾的 TPD 并未超过 13 、14 代 CPU ，你嫌声音大，先考虑一下散热设备的投入是否到位，可以去参考 13 、14 代的 i9 是怎么散热的。

2.电子设备一分钱一分货，没什么性价比高不高的方案。你出多少预算，就有多少性能。

我订阅了能订阅的所有平台，经过对比发现，每个平台，都有自己的强项与弱项，同一个问题经常发生 A 能答好但 B 答不好的情况。如果用作生产，建议都订阅，然后让他们开会，选择最好的那个回答。

@qazwsxkevin

他犯罪，你去告他，假设他要坐牢 10 年。

他觉得坐牢 10 年，人生废了，进去前把你全家带走。

完事后，他还是犯罪，你全家却没了，你觉得这笔起诉划算？

作为成年，思考要全面，别像个小朋友一样非黑即白。

@securityCoding

支持挂载 SSD ，这只是一个功能，与备份机制无关。

云厂商底层，仍然是硬件阵列卡。

如果需要备份，最佳策略是，根据备份的要求与预算，直接找云厂商谈，问他们要方案。

历史的做法是消息总线，类似于消息中间件。

想简单搞搞可以直接抓日志，但缺点是实时性差，容易存在业务数据与日志数据不一致等问题。

想要要求高一点，就得改写业务，把监控集成到业务代码里，但这工作量就巨大了，你需要对每个业务调用进行分析、埋点。

这事不好说。

1.开发为了方便，的确存在在开发或调试期间，将某些账号、远程权限打开，方便维护。当然也有可能是为了偷钱，在没有证据的情况下，没办法弄清楚。

2.现在这个大环境，建议不要闹僵，私下找对方，和对方认真讲一下，把钱补回来就行了，这年头谁都不容易，你坚持走法律，如果对方走到绝路，删代码删数据自爆，对双方都不好。法律的本质是惩治，惩治也是一把双刃剑，不要乱用。

1.生产环境，数据是需要 3 个副本的。有 raid 的存储，只能算一套。另外还需要存储备份一体机，最后再来一套磁带或冷备盘，这样基本的 3 副本就形成了。

2.raid 存储是需要热备盘的，热备盘的意思是，平时作为冗余盘，当 raid 中有盘坏了，热备盘会立即自动顶上去。热备盘的作用是，把故障的维护响应时间降低为零，为运维争取处理时间，因为运维不可能 7*24 盯着系统。

1.这就是为什么，高手在互联网上吵架，会使用完整的小号，包括小号身份证、小号手机号、小号手机、小号微信、小号 QQ 等等，而且这些小号之间还没有关联。

普通人，不在互联网上吵架，根本不需要这些东西，因为这些东西的养号成本不低。

但如果你喜欢在网上吵架，就一定要准备一套这样的身份了。

2.你这都是很小的事情了。有哥们用自己微信黄聊，安装 APP ，被读取通讯录，进行骗钱威胁；还有哥们在微信群吵架，直接实名制，在微信群报自己地址，放手枪图片，让对方来打架的。大家就当笑话看，只要你无所谓，其实根本就没啥。别过分担心了。

你现在唯一要做的是，思考以下，自己是否喜欢在互联网上吵架。喜欢的话，尽早准备一套小号。