PS：阿里巴巴的分布式数据层平台发展的演变可谓是一部技术驱动变革的历程，经历了一个又一个的技术难题，出现了一个又一个的开源/商用产品，提高了阿里巴巴的效率。印象深刻的地方在于，我们都有一个印象就是在数据库开发和调用时，要充分利用索引，避免全表扫描。但是，作者说到在真实的业务场景中很难完全避免全表扫描，比如对于订单进行复杂的分布式条件检索的时候，就会需要采用全表扫描，将查询语句同时推送到后端的数据库中才能实现该场景。但是，因为调用量不会很频繁，而且计算的数据量并不大，所以整体上不会给DB产生太大的影响。另外一个点就是，从系统风险的角度来看，以82法则，在实际中，作者建议仅对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对于其他80%偶尔出现跨库join、全表扫描的场景，采取最为简单直接的方式往往就是最有效的方式。
Part 6 异步与缓存原则异步化
业务流程异步化：服务异步调用，提升大量远程服务线性调用带来的性能问题
数据库事务异步化：将大事务拆分成小事务，提升吞吐量和事务操作的响应时间
事务 => 核心是ACID
柔性事务 => 基础是CAP理论和BASE理论，因为互联网应用最核心的需求是高可用（BASE中的BA）
解决分布式问题的机制：①日志和补偿机制、②可靠的消息传递、③无锁实现（避免事务回滚、辅助业务变化明细表、乐观锁等）
ACID与BASE一般在系统中会结合使用，追求最终一致性
缓存
小库存商品秒杀典型架构
核心问题：处理好商品的库存的扣减，不出现超卖的情况
核心方案：
缓存商品的详细信息（包括库存），不直接访问后端数据库
商品库存使用乐观锁，避免出现超卖
商品库存控制业务流，只在下单环节才对数据库访问，降低数据库访问频率
大库存商品大促架构
核心问题：处理好库存更新的准确与用户等待时间的平衡
核心方案：
将缓存提升到为库存操作提供事务支持的角色 => 将订单交易创建环节在缓存服务器中运行，提高响应速度
借助消息队列实现缓存服务器中的库存修改线性处理
缓存服务故障时通过缓存数据和数据库订单信息还原订单处理的最新状态
PS：异步化与缓存两个技术都和我们的系统性能有很大的关联，在分布式应用架构中，如果没有这两项技术的引入，相信设计出来的应用很难有优质的性能表现。淘宝平台是一个典型的分布式服务架构，通过业务流程异步化提升了性能，分库分表后又在异步操作场景下实现了事务一致性与数据库处理性能的平衡。最后，通过适当使用缓存技术实现了商品秒杀场景下的技术架构，这都是我们需要学习和借鉴的。
小库存商品秒杀场景订单处理流程图
大库存商品秒杀场景订单处理流程图
Part 7 打造数字化运营能力业务服务化带来的问题
服务调用关系纷繁复杂，难以定位问题
不同角色的技术人员需要一些列的管控
分布式服务调用链路平台
阿里巴巴内部实现：“鹰眼”平台，JStorm流式计算引擎
核心思路：埋点和输出日志
海量日志分布式处理平台
阿里巴巴内部实现：TLog平台，日志处理流程“所见即所得”
日志收集控制：遇到大量请求时只记录其中一部分数据，而非全量收集
PS：实现初步的分布式服务体系之后，我们的平台必然会变成一个比较复杂的交互链路网，这会对我们的管控带来一些问题，比如服务调用链监控、服务运行状态是否正常，如何提供关键指标以实现精准营销等等。好在无论是商用产品还是开源产品，都有了比较成熟的技术方案，我司已经在调研学习Skywalking和ElasticSearch，以后有机会做这方面的分享。
在此推荐一波Skywalking：
在 ASP.NET Core 中集成 Skywalking APM （from savorboard 杨晓东）
Apache SkyWalking 为.NET Core带来开箱即用的分布式追踪和应用性能监控 （from Lemon 刘浩杨）
使用docker-compose 一键部署你的分布式调用链跟踪框架Skywalking （from 一线码农 黄星辰）
更多Skywalking分享：https://github.com/OpenSkywalking/Community