Access the internet scientifically, by 耗子叔

连 Kubernetes 集群中怎么弄都有介绍，niubility。

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

在计算机科学中只有两件难事：缓存失效和命名。

• 这两件事其实都是在说一致性，一个是逻辑一致性，一个是数据一致性。
• 命名则关乎业务内在逻辑，如果想不出合适的名字，说明没想清楚，各种逻辑混在一起（多个业务重合？控制与业务耦合？）。此时需要继续分离关注点，不过说起来容易，做起来却不易。
• 缓存则是数据一致性，尤其在分布式环境中，受 CAP 理论的约束，很难保证异步系统之间的状态一致。

Reference：Martin Fowler · TwoHardThings

我在 2022 年 3 月 28 号那天发了一条说说：不要试着去改变别人。

发现 Fenng 老师在 3 月 30 号也写了类似的话题，《我给朋友提意见，他们都不听》。

所以，这就是人性吧，每个人都有自己的尺子，对或者不对，别人很难改变。作为普通人，我们尽量少一点偏见，多一点理解。

如果理解不了，不如选择尊重 Ta 们。

一年过去了四分之一，这三个月我有成长吗？

生活，工作，学习各方面有哪些新的思考？

早上骑车，发现柳絮已经开始满天飞了。

不要试着去改变一个（成年）人，Ta 不会因你几句话就改变，不会。为何我总是控制不住自己要去说，去批评呢？明明知道说了也不会有用。

反思，反思，反思。多关注自己的问题，改变别人先改变自己。自己多读书，多思考，多写作，用行动来证明自己，修身养性。

当别人批评自己时，要控制好自己的情绪，是不是自己确实有问题，是不是自己做的还不够。告诉自己，不要急着反驳，观点不一致是很正常的事情，我们每个人都有知识盲区，要知道“自己不知道”。

我慢慢觉得，一个人如果改变，可能有由外到内的刺激，但更多的是由内到外的觉醒。如果想提醒别人，是否有更好的方式，比如迂回一点，借助对对方有影响的人物的生平事迹，名言等。

“自立的背后是无边的孤独”，我自立了吗？

昨晚看了《蜘蛛侠: 英雄无归》，当看到三代 spider-man 同框时，真的是感慨万分。电影剧本虽一般，但情怀真是杠杠滴。

对于我来说，一代 spider-man 基本没啥印象，因为那时在读高中，别说影院，连网吧都没去过，都不知道有蜘蛛侠，更别说漫威。

二代 spider-man 出来的时候，我已经工作了，印象中是去电影院看的，细节也已忘的差不多。

三代 spider-man 则是伴随着漫威宇宙的崛起从而出现在大家的面前，而 spider-man 和 iron-man 的这条线也是让人感慨不已。

电影中，有一个场景：三代女主从楼上掉下来，三代 spider-man 去接，没接住，此时二代 spider-man 替补上去，接住了。如果没有看过二代 spider-man 的《超凡蜘蛛侠》，可能无法理解这个场景。因为在那个时空里，也是一样的场景，二代 spider-man 因为没有接住女友，从而失去了挚爱。这一次，导演算是让他重新弥补了这个遗憾，泪目。

markdown 上下标的两种方式：

之前我用的都是下面这种方式，即 html tag：

原文：

测试上标<sup>U123</sup>，如何？
测试下标<sub>low</sub>，如何？

效果：

测试上标^U123，如何？
测试下标_low，如何？

今天我发现，可以更简单一些：

原文：

测试上标^U123^，如何？
测试下标~low~，如何？

效果：

测试上标^U123，如何？
测试下标_low，如何？

看到星球上有人分享了语雀上一个读书大佬，我点击进去看了一下，很震撼，非常敬佩。

他的个人书馆简介是：读书是学习，摘抄是整理，写作是创造。

非常认同，突然想到另一句话：A reader lives a thousand lives before he dies.The man who never reads lives only one.

共勉。

《如何权衡关系数据库与NoSQL数据库》 简单总结：

1、RDMS

• 通过定义关系，数据库自身完成了很多业务逻辑计算，并通过 ACID 保证事务，从而为上面的应用层释放了生产力，所以数据库往往也是高并发系统的瓶颈。
• 统一的 SQL 语言屏蔽了底层不同 RDMS 之间的差异，从而为应用层提供统一的、几乎没有差异的 API
• 利用索引、缓存等特性，关系数据库支持亿级以下的数据量时，性能并不差；而并发度，一般可以支持上千个并发连接
• 内存的数据结构多样，无法合并到数据库表中的一个字段，需要配合 ORM 框架进行映射
• 由于业务关系是在表中预定义好字段，所以一旦变动数据模型，代码需要跟着改，存量数据还要迁移
• 关系数据库水平伸缩（AKF X 轴），主从分离后，主库写压力还是很大，而沿着 AKF Z 轴按分库分表拆分，ACID 又无法保证。

2、NoSQL

• NoSQL 放弃了与分布式环境相悖的 ACID 事务，提供另一种聚合数据模型，基于 BASE 的柔性事务实现高并发可伸缩
• 在分布式事务中，ACID 的 C 要以满足 CAP 中的 C （副本的一致性）为前提
• 既然 NoSQL 没法自己搞定 ACID，所以需要应用层处理事务，比如 2PC，3PC，消息队列，TCC，SAGA 等方案
• NoSQL 主要四类：k/v 数据库（如 Redis），Document-oriented 数据库（如 MongoDB），Column-oriented 数据库（如 Cassandra），Graph 数据库（如 Neo4j）,日常使用的主要是前三种。
• NoSQL 可伸缩性好，可以基于 k/v 模型沿着 AKF Z 轴扩展到上万个节点
• 数据分片后，可以基于 MapReduce 思想，提高并行计算能力
• 冗余备份，系统容灾能力更好
• 如果每个 key 对应的 value 已经满足了数据要求，则单机性能会比关系数据库更好

3、其他

• 关系数据库是为了单机而设计的，如果把 ACID 事务延伸到分布式系统中，那实现成本会影响到服务的基本可用性
• PostgreSQL 数据库的默认事务级别为 READ COMMITTED，MySQL 数据库的默认事务级别为 REPEATABLE READ
• NoSQL 是对 RDMS 的补充，尤其在分布式事务中

"Aha! Amazing!"

使用了 macOS 12.3 和 iPadOS 15.4 带来的通用控制功能后，我不得不手动点个赞。

非常喜欢这个功能，一个写文章，一个查资料，双剑合璧，赞。

当然，现在还没有深入使用，期待。