@archxm

Passmark 上面的跑分，是经过实际测试得到的，而且上面还有样本数，它就是最大的科学精神。

甚至很多新款 CPU 的性能信息，也是在这个网站首发。

你觉得他是迷信，我只能说，这年头不认识 Passmark ，你要多去学习基本常识。

以前大家喜欢刷机，原因是智能机贵，且原版系统缺乏很多必要的功能，并且大家相对于安全与稳定来说，更关注新功能。

现在不一样了，首先智能机很便宜，而且就算不 root ，不刷机，铺天盖地的 APP ，很难找不到你想要的功能。而且现在大家更注重隐私、安全、稳定性，所以刷机只会越来越小众。

另一个例子，现在大家更喜欢笔记本与迷你电脑，用大机箱台式机的人会越来越少。

@bthulu

1.我在前面说的，是规则，像 RFC 一样，是大家都需要遵循的规范，而不是某款关系型数据库的专有功能。

2.从你这个提问来看，你应该不是科班的。如果你对这个话题感兴趣，可以补习一下相关知识：
https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns.htm

@archxm

1.我说的结论，数据来源于 passmark 。

2.根据 passmark 的数据，N100 无论单核还是全核，都比 i5-2500K 强。不知道你觉得 i5-2500K 比 N100 强，何来的证据，搞技术讲究证据，不要凭个人感觉。

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

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

好好反省下吧。