adjust

Architecture.md

@@ -1634,6 +1634,67 @@ public class R implements Serializable {
 
 
 
+# 多数据中心
+
+## 同城多机房
+
+### 机房共用注册中心
+
+所有机房共用一个服务注册中心，所有的请求由它统一分发，应用指向同一个数据库主库。
+
+> 要突破单机房的容量限制，最直观的解决办法就是再建新的机房，机房之间通过专线连成同一个内部网络。应用可以部署一部分节点到第二个机房，数据库也可以将主备库交叉部署到不同的机房。这一阶段，只是解决了机房容量不足的问题，两个机房逻辑上仍是一个整体。
+
+缺点：
+
+> 1. 服务层逻辑上是无差别的应用节点，**每一次 RPC 调用都有一半的概率跨机房**；
+> 2. 每个特定的数据库主库只能位于一个机房，所以宏观上也一定有一半的数据库访问是跨机房的。
+
+
+
+### 机房独占注册中心
+
+每个机房独占一个服务注册中心，所有的请求独立分发，应用指向同一个数据库主库。
+
+> 改进后的同城多机房架构，依靠不同服务注册中心，将应用层逻辑隔离开。只要一笔请求进入一个机房，应用层就一定会在一个机房内处理完。当然，由于数据库主库只在其中一边，所以这个架构仍然不解决一半数据访问跨机房的问题。
+
+> 这个架构下，只要在入口处调节进入两个机房的请求比例，就可以精确控制两个机房的负载比例。基于这个能力，可以实现全站蓝绿发布。
+
+
+
+## 两地三中心
+
+> - 城市 1：idc1（registry1 + leader） + idc2（registry2 + replica1）。所有的服务都访问 leader 数据库
+> - 城市 2：idc3（registry3 + replica2） 另一个城市为备份的中心，访问replica，隔离对 leader 的依赖
+
+两地三中心的两种形态:
+
+- 同城热备，异地冷备（蚂蚁就是采用这种方案，通常每个 idc 平摊流量）
+- 同城灾备，异地灾备（一个中心是活的，另有一个同城灾备，一个异地灾备）
+
+### “ 双活 ” 或 “ 多活 ” 数据中心
+
+多个或两个数据中心都处于运行当中，运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力，所以称为 “双活 ” 和 “ 多活 ”。
+
+
+
+### 传统数据中心和灾备中心
+
+生产数据中心投入运行，灾备 数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。
+
+
+
+异地灾备机房距离数据库主节点距离过远、访问耗时过长，异地备节点数据又不是强一致的，**所以无法直接提供在线服务**。
+
+
+
+在扩展能力上，由于跨地区的备份中心不承载核心业务，不能解决核心业务跨地区扩展的问题；在成本上，灾备系统仅在容灾时使用，资源利用率低，成本较高；在容灾能力上，由于灾备系统冷备等待，容灾时可用性低，切换风险较大。
+
+
+
+两地三中心看起来很美好，其实无法解决立刻切换的问题-**异地延迟无法消除**。
+
+
+
 # OAuth2.0
 
 `OAuth2.0` 的授权简单理解其实就是获取令牌（`token`）的过程，`OAuth` 协议定义了四种获得令牌的授权方式（`authorization grant` ）如下：

Solution.md

@@ -1376,6 +1376,15 @@ Zipkin有四大核心组件
 
 
 
+**设计Token**
+
+- 要申请，一次有效性，可以限流
+- 使用删除操作来判断Token。删除成功代表校验通过
+- 如果用 select+delete 来校验 Token，会存在并发问题，不建议使用，但可以用lua保证原子性
+- 设置短期过期时间，如5分钟
+
+
+
 ### 基于MySQL实现
 
 这种实现方式是利用 mysql 唯一索引的特性。示意图如下：