N100 以 6W 的功耗，性能接近 3 代 I7 ，已经很强了。

但是，如果你已经习惯了 Intel 10 代以上的 CPU ，N100 的性能，对你来说又不够看了。

建议选购 CPU 之前，一定要用自己熟悉的 CPU 的性能，拿来进行对比。

@pangdundun996

1.本来我想用转账的例子来说明，但觉得太简单了，不符合本论坛水准。

2.我举得这个例子很合适，你说的双信息系统是对的，但你说的夜间跑批清算是错的，清算早就是全天候的了，真正原因我在评论区里已经讲了。

@bthulu

Q1：现实中是否存在真正的分布式事务?
A：存在。

Q2：几个成功了, 有几个失败了, 你怎么办？
A：只要有一个失败，此次分布式事务就按失败算。分布式框架或相关驱动模组，会自动回滚所有涉及到的分布式数据库，如果你是开发，此时你会 catch 到一个分布式事务失败的 Exception ，你需要做的是，按此次业务失败进行处理。

Q3：提供成功的事务, 哪个数据库支持回滚?
A：主流的关系型数据库，必然支持回滚，这是标准。

Q4：就算支持回滚, 也会出现有几个回滚成功了, 有几个回滚失败了, 这时候你又咋办?
A：关系型数据库在正常情况下，回滚一定会成功。如果出现回滚失败，这等同于数据库软件出错，此时数据库软件会写日志告警，甚至失去响应、崩溃。如果你是运维，在数据库部署阶段，就要对这些情况进行监控。如果你只是开发，你什么都不用管，问一下运维同事就行。

以上知识在 [数据库原理与设计] 相关教程中有讲解，课程方面属于计算机系的本科课程。

@ilvsxk

我并没有提银行 APP 与云闪付 APP ，请仔细的，认真的，阅读我在上面写的评论。做技术，一定要仔细认真。

9 代 i7 的跑分，75-95W 的全负载功耗，虽然比 E5v3v4 这些洋垃圾好，但跑分还是有点寒碜。

建议，如果不缺钱，至少加点钱上 11 代 i7 吧。功耗低，性能还炸天，关键价格也不贵。

两个原因：

1.以暴雪为主的游戏厂商，极度傲慢，不关心玩家。它为了自己方便，就设计成每周一次停服维护，剥夺玩家权益。最近暴雪重新开服，又有很多玩家赶着去给暴雪送钱，我实在无法理解。

2.有很多厂商，为了所谓的版本统一，不管玩家诉求。其实很多玩家对游戏统一版本的要求并不高，游戏厂商完全可以分阶段同步更新，这样玩家就可以不用遭遇停服时间。Steam 上面就有不少联机游戏是这样做的。

如果业务复杂，建议用基于数据库的流程引擎来开发，因为方便多人协作开发+方便调试排错。

举个简单例子，APP 跑到某一步，突然崩了，此时完整的数据过程，都在数据库，你完全可以慢慢检查，最后用数据库，直接恢复现场。

@ilvsxk

银行账单延迟是银行没技术能力对 IBM Server 的老系统与 x86 的新系统做分布式事务的对接。

不懂分布式事务，写程序容易造成数据状态不一致。如果公司有的选，当然要选懂分布式事务的程序员。

举一个简单的场景，银行服务器的数据，分散在不同的物理机里。比如用户的借记卡数据在 IBM Server 上面，用户的信用卡数据在 X79 Server 上面，现在某用户通过借记卡，给自己的信用卡还款，思考一下，为什么各大银行的还款提醒，不是实时的，甚至有时候你晚上还款了，第二天银行还会给你发短信。通知你还款。

再举个更常见的场景：
Server1 保存用户订单信息，Server2 保存商品宝贝详情页。你想想为什么淘宝订单、京东订单、拼多多订单，很多年前的订单，已经看不到当时的商品详情。

内部业务主键，最好是用自增的 64 位 int ，也就是 BIGINT：
https://dev.mysql.com/doc/refman/8.4/en/integer-types.html

有些场景需要把主键传到前端，产品经理不希望别人通过调试来看出主键值，于是还需要加个 hash 。而 UUID 可以在这里一步到位，这也是为啥很多公司喜欢 UUID 的根源所在。

@zaizaizai2333

1.加个选项让用户选，这也是增加用户体验的行为，这也是卷。

2.这个问题和大公司无关，只是卷而已。无论大小公司，GUI 要想做的体贴入微，就是需要投入大量的岗位、人力与工作时长的，甚至十几年前，某家行业 APP 的 GUI ，给每个按钮、事件、业务流程，甚至提供了语音指引，那个时候整个 APP 就像加了 AI 一样，全是一条条规则+语音，用工作时间给填上去的。你没做过 GUI ，没卷过，自然不懂其中的本质。

不说行业 APP ，你自己观察一下 CS 与 王者，这么多年的发展，GUI 已经细致入微到什么程度了。这都是大量的工作时间、开会、群策群力填上去的。

本质上是因为老外人少且不卷导致的。

GUI 与用户体验，是一个堆工作量的场景，只有国内这种卷+工作时间总量极高的地方，用户体验的细节才能在集群众意见的情况下做好。

@Emiya1208

看来，你还没反省，还不知道你的问题。

我批评你，是因为你把 ZFS 这种单机系统，在生产环境里使用，这是大忌，并且你自己也说了，内存出现过故障，当时处理这个问题，停机了多久？

CephFS 虽然有各种功能缺陷，但人家不存在单点问题。你觉得它扩容与平衡存在问题，那些都是可以通过架构与算法进行改进的，不至于导致整个系统停摆。

无论是我，还是你的领导，批评你，你觉得不对，是因为你的层次，还没到达我和你的领导的层面。

好好反省下吧。

@Emiya1208 我在前面说了，ZFS 存在单点问题。你应该很幸运，5 年来，主板、内存、CPU 、电源、软件等，没出现过故障。如果你是我的员工，你用单机 ZFS 做生产环境，我知道了肯定会批评你的。

如果资源足够，分开部署 + 数据湖统一管理 + 统一备份才是王道。

分开部署可以避免集中式数据库的单点问题与冷热数据混在一起的性能处理麻烦的问题。

数据湖统一采集管理可以方便你对数据做分析与利用。

统一备份可以使用单一的存储备份一体机来降低备份成本，配合自建 OpenZFS 的实时压缩与实时去重，甚至可以做到 CDP （ Continuous Data Protection ，持续数据保护，数据库备份的高端功能，每 2-5 秒一个快照，每小时合并一次快照，由 OpenZFS 提供底层的 block 级别的实时去重可以支持几乎无限个快照恢复节点）。