这本书主要讲述了阿里的全球化实践中的一些思考，最近无意中在图书馆看到这本书，正好最近也在做相关内容，把自己看完的一些感悟做些分享。
一、什么是全球化
说的广一点，即用户分布在全球任意一个地方，全世界的人、公司等交互及整整合的过程。
二、全球化对技术的要求
或者说全球化要解决哪些问题。
1、性能
即用户访问我们的服务时，响应时间不能太慢。
2、可用性
当一台机器、一个集群，直到一个机房挂掉保证服务仍然是可用的。
3、数据一致性
全球化业务的场景复杂，其中一个是部分数据要打通，如欧洲用户可以在美国下单，这就涉及到数据的多地读写问题，进而带来一致性的问题。
感想：
其中可用性的方案在国内已经有异地多活等经验，不过在海外复杂的网络条件下对系统提出更高的要求，实际情况可能是异地跨几千公里了。
三、设计原则
1、单一数据Master
即一条数据在任何时间点只能由一个机房进行写操作。
2、一键恢复
出现问题时，系统有能力一键恢复到上一个稳定状态。
3、简单可管理
任何系统管理员操作的地方只要简单的输入即可。
感想：
其中第一条原则中保证前面说的数据一致性，第二条是保证可用性
四、具体场景分析
1、路由表设计
路由表主要解决将用户就近访问的问题，因为用户可以被调度到任意机房，则用户和机房的配置必须有个地方保存起来，并且可以修改。
路由表的初始设计
这里并未说明路由表是如何持久化的，应该是通过一个关系型数据库如mysql就可以做到，因为这个修改的场景不多，大部分请求可以通过缓存解决。文章中有专门讲到路由表实际运行中保存在内存，并且讲了如何优先内存使用空间，这个不是我们要讲的重点，有兴趣的同学可以查看原书。
第一版的时候每个应用都加载一份路由表，这样带来2个问题：内存的增加和数据一致性的问题，前面说了路由表修改的场景是比较少的，但还是有，因此修改之后如何让成千上万台机器同时保证路由正确是这个方案下需要解决的问题。
那能不能将数据保存一份，然后通过RPC的形式服务呢，因为路由查询是一个基础的功能，调用量巨大，这样会对系统的性能影响大，也增加了很多机器成本。
解决方案：
增加一个中间状态，这个状态与变更前和变更后的状态兼容。
具体解决办法是增加“禁写”状态，在这个状态下，用户不能在任何机房进行写操作，等所有路由表更新完成后，才放开写操作。
路由表推送一致性设计
上面讲了路由表如何保证所有机器数据的一致性，是通过增加中间状态来完成，那如何确保每台机器的路由表都更新完了呢，这里用到了Zookeeper做协调。
所有机器在SessionList目录下建立一个临时节点；
每一次变更都会增加版本号，保存到CurrentVersion节点；
所有节点都在CurrentVersion节点建立Watcher，用于监控新版本的变更；
当有新版本到来时，所有节点从Tair(阿里内部的KV存储，相当于Redis)来获取数据；
节点更新完后，会将机器名称写入AckList目录下的CurrentVersion子目录；
变更程序只要判断AckList目录下氖机器节点和SessionList目录下所有节点，就知道变更是否全部更新完毕。
这里还有个细节问题，即肯定有新机器加入或退出，而Zookeeper保证最终一致性，另外还有网络抖动，如何在网络连接有问题的场景下，机器也能拉取最新的路由数据呢？
关于网络抖动的情况，这时客户端会抛异常，可以基于这个异常加载最新的路由表即可。
Zookeeper提供“穿透”读的方法，即直接读取最新数据，新机器加入的场景可以让建立临时节点，再直接读取最新数据，然后进行确认，也可以保证数据一致性。
感想：
1）、关于一致性的问题，这里增加了“禁写”的状态，即让系统停下来，我们才能准确地度量它，这个可以做为强一致性设计的一个重要原则。
2）、非功能性设计主要是考虑异常场景下的处理，路由表的最终一致性还要考虑新节点加入，网络异常的情况，只要充分考虑这些场景，并总结通用的潜在风险才能保证最终的效果。
2、用户视角数据类型及处理办法
1）只读数据
用户行为不会触发数据变更，便用户需要读取数据，如商品；
对于这类数据不做强一致保证，通过异步复制的方式解决。
2）独享数据
只有一个用户可以对数据进行变更，如购物车、订单之类。
本地读写就可。
3）共享数据
多个用户需要共同变更同一条数据时，像订单，用户要，卖家也要操作。
优先级最高的用户区域作为Master，可进行本地读写，或数据异步复制至所需区域，具体分列表页和详情，前者一致性要求不高，本地读取，后者跨区访问。
4）全局共享数据
像库存，每个用户都可以操作。
对于这类数据，最重要的是保证单一Master操作。建议用网络质量最好的机房存放，在此基础上可以最大化地寻找优化方案，案例中采用的是优先扣本地库存，本地库存没有了，再扣中央库存。
举个例子，总共100个库存，现在要在欧洲、美国、印度3机房开售，因为欧洲机房网络质量最好，所以欧洲机房为中央库存，假设它放60个，其它2个机房各放20个，用户下单时先扣本机房的，扣完了再到欧洲机房扣。这里还用到了大数据进行提前预测，尽量减少实际的跨机房操作。
感想：
1、数据要分场景来看，强一致和非强一致要求场景的方案肯定不一样；
2、实在要集中化处理的数据，看能不能分到各节点一些，保证一部分请求可以在本机房处理，另外通过历史数据和大数据的知识不减少最后的跨机房操作。
