学习

分布式数据库大多可以分为两种架构风格，一种是 NewSQL，它的代表系统是 Google Spanner；另一种是从单体数据库中间件基础上演进出来的，被称为 Prxoy 风格，没有公认的代表系统，选了

事务的特性： * 原子性：事务中的所有变更要么全部发生，要么一个也不发生。 * 一致性：事务要保持数据的完整性。 * 隔离性：多事务并行执行所得到的结果，与串行执行（一个接一个）完全相同。 * 持久性

当我们谈论分布式数据库的一致性时，实质上是在谈论数据一致性和事务一致性两个方面。 逻辑上的一份数据同时存储在多个物理副本上，自然带来了数据一致性问题。 状态一致性是指，数据所处的客观、实际状态所体

# 外部视角 OLTP 场景的通常有三个特点： 1. 写多读少，而且读操作的复杂度较低，一般不涉及大数据集的汇总计算； 2. 低延时，用户对于延时的容忍度较低，通常在 500 毫秒以内，稍微放大一些也

这是架构活动中极具里程碑意义的一个节点。项目的启动，标志着企业开始正式向一个架构活动投入各种资源。 项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认。 有了承诺，任何参与者都不

规划确认，也就是定稿架构规划文档的过程。规划确认环节的王道，就是通过精细规划来控制风险，保障全面启动前交付风险的最小化。 在定稿的过程中，你可能会和不同团队、企业外部专家产生诸多交互。这个时候你就需

架构师的取舍不是一个艺术，而是一个基于商业和技术环境的理性的思考决策。 在独立性假设之下，任务分配是个局部优化的过程，所以不需要在全局上做优化。在独立性假设之下，真正导致失败的正是你的最软肋，也就是

# 信条一：任务边界可以打破现有的执行边界。 任务分配虽然应当尊重当前问题域到执行域的映射，但却不需要完全遵照这个映射。在一个架构活动中，架构师更应该从用户思维出发，把任务交给能完成这项任务的团队。

首先要从产品定位的角度来梳理。一般来说，应该从产品经理那里拿到三个信息： 1. 客户 2. 用户 3. 核心场景 其次要从执行者定位的角度来梳理。一般来说，你需要从技术团队的管理者那里拿到以下信息：

语境是指语义的环境（Semantic Context）。同一个词在不同的语境下，语义很可能完全不同。但是大多数角色都不一定知道其他角色的存在，更不用说理解他们的语境了。 我们各自主观意识中形成的客体

什么时候需要统一语义呢？答案是当对话双方或者多方在各自表达，没有办法理解对方真实意图的时候，就需要统一语义了。 对于架构规划而言，统一语义的终极目标只有一个：项目所有参与方的需求能够被无损地表达、记

仅仅适用于互联网企业线上业务的风险决策。 我们需要从多个视角对重大风险做一个全面的挖掘: 1. 项目交付的视角。 2. 商业价值的视角。 3. 人性视角 4. 有限资源的视角 5. 其他风险 从中

可行性探索是架构师帮助企业避免重大方向失误的最后一个节点。 可行性探索的目的，就是让决策者和赞助者对架构目标是否可达，形成一个相对清晰的认知。在可行性探索的过程中，架构师需要在最短时间内发现最重大的

一个正确、合理且可达的目标，是靠多个职能之间反复讨论和反复演算得到的。这是一个发现的过程，而不是一个拍脑袋决策的过程。目标的制定要靠科学决策。目标必须基于客观事实、自然规律和现实环境的约束。 在确认

架构师在目标确认这个节点上，不仅要保障目标的正确性和合理性，还要保障目标的可达性。也就是说，目标确认是以终为始的。架构活动必须始于一个明确的目标，而一个成功的架构活动，最终也要止于这个目标。 首

架构环境的完整定义：指的是在企业的商业、技术和文化环境中，架构师为架构活动所搭建的虚拟的工作环境，包括决策环境、激励环境、资源环境、团队构成、物理和虚拟的工作空间等。 使命，使命是一个企业存在的意义

保障交付意味着架构师能够降低大型架构活动的不确定性和复杂度，最小化架构方案，最终保障高质量的交付。其中关键动作有三个：降低不确定性、控制复杂度和最小化架构方案。 不确定性的来源有多个方面。首先是目标

共识，在架构活动的上下文里，就是尽可能让多的人在限定时间里达成一致。很多人误以为共识就是投票，让少数服从多数。其实不然。投票是个表面公平，但其实非常暴力的决策方式。它是在参与者无法达成共识的情况下，依

架构师要尤其信奉原则（Work by principles），所谓信奉原则，就是采用相信过程正义的工作方式，用一组原则来指导行为和决策，而不是随心所欲地工作。放在架构活动的情境中，就表示你作出决策的

一个企业的文化，主要会在如下三个维度影响架构活动： 1. 决策方式：出现各种有争议的问题之后，争议各方最终是怎么做决策的呢？比如确定架构选型、架构设计、交付等等。 2. 沟通方式：团队上下级是怎么沟通