距离上次写博文还是2020的年度总结，转岗之后比较忙，一直没有时间和精力产出内容。最近换到了新的部门，临近新年，分享最近看过的两篇比较有意思的博文。
单元化
最近在准备组内的分享，关于容灾相关的话题，包括数据中心容灾架构&业务降级方案设计等等。偶然在内网看到了架构同学关于单元化的分享，是个之前未接触过的知识点，看了几遍没能理解透彻，知道单元化最初的时间是来源于阿里，在网上搜索了下发现了这篇文章，读了一遍发现很多解释都非常形象，十分推荐阅读，下面是一些摘抄的笔记
因为数据库存储层瓶颈的存在再多水平扩展的服务器都无法绕开，而从整个互联网的视角看，全世界电商的交易 TPS 可以轻松上亿。这个例子带给我们一些思考：为啥几家互联网公司的 TPS 之和可以那么大，服务的用户数规模也极为吓人，而单个互联网公司的 TPS 却很难提升？究其本质，每家互联网公司都是一个独立的大型单元，他们各自服务自己的用户互不干扰。这就是单元化的基本特性，任何一家互联网公司，其想要成倍的扩大自己系统的服务能力，都必然会走向单元化之路
分库分表不仅可以对相同的库进行拆分，还可以对相同的表进行拆分，对表进行拆分的方式叫做水平拆分。不同功能的表放到不同的库里，一般对应的是垂直拆分（按照业务功能进行拆分），此时一般还对应了微服务化。这种方法做到极致基本能支撑 TPS 在万级甚至更高的访问量了。然而随着相同应用扩展的越多，每个数据库的链接数也巨量增长，这让数据库本身的资源成为了瓶颈。这个问题产生的本质是全量数据无差别的分享了所有的应用资源，比如 A 用户的请求在负载均衡的分配下可能分配到任意一个应用服务器上，因而所有应用全部都要连接 A 用户所在的分库，数据库连接数就变成笛卡尔乘积了。在本质点说，这种模式的资源隔离性还不够彻底。要解决这个问题，就需要把识别用户分库的逻辑往上层移动，从数据库层移动到路由网关层。这样一来，从应用服务器 a 进来的来自 A 客户的所有请求必然落库到 DB-A，因此 a 也不用链接其他的数据库实例了，这样一个单元化的雏形就诞生了。
比如实时风控系统，如果多地部署，某个 RZone 直接读取本地的话，很容易读取到旧的风控状态，这是很危险的。这时蚂蚁架构师们问了自己一个问题——难道所有数据受不了延时么？这个问题像是打开了新世界的大门，通过对 RZone 已有业务的分析，架构师们发现 80% 甚至更高的场景下，数据更新后都不要求立马被读取到。也就是上文提到的”写读时间差现象”，那么这就好办了，对于这类数据，我们允许每个地区的 RZone 服务直接访问本地，为了给这些 RZone 提供这些数据的本地访问能力，蚂蚁架构师设计出了 CZone。在 CZone 的场景下，写请求一般从 GZone 写入公共数据所在库，然后同步到整个 OB 集群，然后由 CZone 提供读取服务。比如支付宝的会员服务就是如此。
数学与编程
康托尔、哥德尔、图灵——永恒的金色对角线 by 刘未鹏
源于V2EX上一篇提问帖下的回复，看到标题比较好奇就添加到了阅读清单，趁着年前不那么忙在公司细细读了下。什么是对角线方法？哥德尔的不完备性定理，图灵的停机问题，lambda算子理论和神奇的Y combinator…… 作者是个搞计算机的但是文笔很好，内容层层递进，剖析问题也很准确，读起来有一种感觉：一个很难的数学问题不知不觉的就讲述完了，数学之美也仿佛不那么难理解了。下面是摘抄的一段内容
- 性质倒是找出来了，怎么构造出这个Y却又成了难题。一个办法就是使用抽象法，这是从工程学的思想的角度，也就是通过不断迭代、重构，最终找到问题的解。然而对于这里的Y combinator，接近问题解的过程却显得复杂而费力，甚至过程中的有些点上的思维跳跃有点如羚羊挂角无迹可寻。然而，在这整个Y combinator介绍完了之后我们将会介绍著名的哥德尔不完备性定理，然后我们就会发现，通过哥德尔不完备性定理证明中的一个核心构造式，只需一步自然的推导就能得出我们的Y combinator。而且，最美妙的是，还可以再往下归约，把一切都归约到康托尔当初提出的对角线方法，到那时我们就会发现原来同样如羚羊挂角般的哥德尔的证明其实是对角线方法的一个自然推论。数学竟是如此奇妙，我们由简单得无法再简单的lambda calculus系统的两条公理居然能够导出如此复杂如此令人目眩神迷的Y Combinator，而这些复杂性其实也只是荡漾在定理海洋中的涟漪，拨开复杂性的迷雾我们重又发现它们居然寓于极度的简洁之中。这就是数学之美。