人类最宝贵的财富就是知识，而知识传播的媒介不是体液也不是 DNA ，而是书籍。

不过，看不看书，还真是个人的选择。越是文明富强的时代，个人意愿就越会得到尊重。

IT 技术与商业，是两个不同的赛道。

如果想在 IT 技术方向赚钱，你需要同时学习 IT 技术与商业。商业上很多理论与经验会违背 IT 技术方向的做法。

1.隐私：只要能进行 self-host 的知识库，都符合这个条件。

2.方便数据同步：必然是使用数据库作为后端的知识库，比如 joplin ，因为 obsidian 这类基于文件的知识库，很难控制同步带来的一致性问题。

@jhdxr

在讨论隐私与安全之前，能不能麻烦你，先介绍一下，你刷机用的镜像，是从什么渠道来的，作者又是谁。

@my101du

1.从你的描述来看，你需要去了解一下跑分的原理。

2.i5-5200U 的单核性能只有 N100 的 78%，多核性能只有 N100 的一半。

如果你觉得 N100 不如 i5-5200U 流畅，然后就下断言说 N100 不如 i5-5200U ，我只能建议你，去学习如何分析性能瓶颈，如何测试其他设备比如存储介质，如何进行公平测试等等知识。

@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 ，请仔细的，认真的，阅读我在上面写的评论。做技术，一定要仔细认真。

两个原因：

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

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

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

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