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 ，被读取通讯录，进行骗钱威胁；还有哥们在微信群吵架，直接实名制，在微信群报自己地址，放手枪图片，让对方来打架的。大家就当笑话看，只要你无所谓，其实根本就没啥。别过分担心了。

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

@findex 不是矿盘，这些是数据中心的企业级盘，朋友拿来送我。

我总觉得 OpenZFS 存在问题。以下是一个完整的 OpenZFS 结构，运行在志强 CPU + RECC 内存上，并启用了实时压缩与实时去重。内存与所有磁盘，在上机之前，都做了检查：

数据盘：HDD-4TB * 5 ，提供约 20 TB 数据存储量。

校验盘：HDD-4TB * 2 ，RAIDZ2 。

热备盘：HDD-4TB * 1 。

SSD-Cache 盘：SATA3-SSD-镁光-Micro-M600-512GB * 1 。

NVME-SSD-WriteBuffer 盘：QichenNVME-512GB * 2 （ Mirror ）。

运行了十几天，就 boom 了 1 个盘，然后热备盘顶上来。再过了十几天，全 boom 了，但集群仍然能用：

https://pastebin.com/xsR3sWSh

我觉得存储这玩意，数据量到达一定量后，建议还是使用多物理机的分布式存储，安全些。

没公网 IPv4 时，zerotier/tailscale 有免费额度。这才是它们的核心竞争力。

如果都有公网 IPv4 ，更好的选择是企业级 VPN 方案。

如果收费，淘宝上一堆自建端口映射的服务，比这两玩意稳定。

有没有一种可能，这点数据量，什么都不用考虑，机器就能扛下来？

假设 1 分钟生成一百万个自增 ID ，平均每秒 16666 个自增 ID 。

Redis benchmark ，https://openbenchmarking.org/test/pts/redis ，i3-8100T ，每秒 123 万个 request 。

另外自从 SATA-SSD 普及以来，有没有发现，关于数据库性能的讨论，越来越少了？ nvme-SSD 普及后，这类讨论几乎绝迹了。原因是，1 块正规的 SATA-SSD ，性能是 HDD 的 100 多倍，甚至 pcie5-nvme 能达到 2 千多倍。

建议学软件开发的，一定要经常关注硬件性能测试。

这是很基础且很常见的网工场景，典型的例子是虚拟化集群系统，实现方式是服务器多网口 + 每个网口不同网段 + 每个网口不同 vlan 或 vxlan 。有时候甚至厂家的部署工程师，为了不干扰用户私有网段，会给虚拟化系统的内部的业务配置 1.1.1.x 这样的网段。

任何接入方案都可能有漏洞。企业级的安全做法是，多层接入方案，来提高整体安全性。比如 Linux 的 VPN + OpenBSD 的 SSH + Windows 的 RDP ，3 套连接方案一起用，再加上 fail2ban + 地域 IP 白名单 + IPS ，3 层安全，不仅黑客进不去，自己也进不去。你就说安不安全。

1.让开发或熟悉业务的 DBA ，先写个把数据库的数据，全部导出的脚本。把该脚本放入 crontab 定期执行，执行后把结果写日志。运维工具，实时监控日志，如果日志中发现 Error 、fail 、timeout 等字符，就告警。这种备份方式，只是用来兜底的，出故障后，运维千万不要直接用这种方式得到的备份，进行恢复。如果只剩下这种备份了，交给开发去恢复。

2.把数据库做成多节点（多副本节点），形成一个 HA 集群，单个节点故障后，Client 自动访问别的节点，类似于 Oracle RAC 的工作模式。这种模式，单节点故障后，不需要开发介入，运维可以直接进行替换故障节点，类似于 raid 磁盘故障时的操作。银行级别的数据库，也是需要使用这种结构的。