这书是7月18号团队内部买的，到现在(8月15日)过去了将近一个月了，这一个月之中陆陆续续地将这本书给慢慢看完了。总的来说是本好书，讲述了阿里技术发展的历程，和把阿里的各种中间件介绍了一遍（甚至你会怀疑这本书就是介绍中间件的），但比较好的是，作者把为什么要做这个中间件，中间件的实现思路都简单地描述出来了，对扩展思路挺好的。同时也感受到阿里这么多年下来的技术沉淀真不是盖的，没有做不到，只有想不到。
现在我们要对订单表进行拆分，那分库分表键是以 用户ID 来切分还是以 订单号 来切分呢？
1.若采用订单号来切分的话，订单数据的分布就会比较均匀，不会出现某张表数据过大的情况
2.若采用用户ID来切分的话，因为有些卖家的订单量是很多的，容易造成某个库或表的数据量很大，数据分布不均匀
若从上述分析来看，可能将分库分表键以订单号来切分是一个不错的选择，但是实际情况没那么简单，卖家查看自己当天或某段时间内的订单时(这还是比较高频率的)，此时因为查询条件没有订单号，因此只能向每个数据库都执行一遍sql，获取出数据，再进行组装(若查询条件有订单号，则可以将订单号取模，定位到数据所在的数据库地址)。这样会造成查询速度效率低下的问题。
为了解决这个问题，一般会额外建一张用户ID-订单关联表(也称为 异构索引表 )，在查询卖家最近订单时，先通过异构索引表获取用户相关的订单，再拿这些订单号去查，避免出现要去每个库中查的问题。
而阿里这边，异构索引表是可以通过精卫平台同步建立的，精卫平台是一个数据库中间件，用户在DB变更时，可以通过精卫平台，进行一些额外的DB操作。一般来说，我们建立异步索引表肯定会通过业务层去建立的，因为这样安全，可以通过代码处理异常。
MQ需要保证本地事务提交与消息发送是同时成功的，不能存在某方失败的情况，并且采用MQ的方法需要编写业务代码对整个事务的流程进行控制，其必须能支持正向补偿和反向回滚，接口必须是 幂等 的！
经典的两段式提交方法，TCC的意义为(TRY-CONFIRM-CANCEL)。
阿里内部有开发一套自己的TCC中间件，叫TXC，其与传统的两段式提交不同的是，在CONFIRM阶段，本地事务就会提交，同时TXC系统需要生成UNDO和REDO的日志，用于本地事务回滚和回滚数据检查，通过这种方式，能 减少确认阶段对锁的占用 。
但是其存在一个问题是事务隔离性只有READ_UNCOMMIT(读未提交)，即会造成脏读，目前从书上还未得知怎么提升事务隔离级别。貌似是通过乐观锁或者加一个注解来提升事务隔离性？猜测若要提升事务隔离性，应该也只能使用经典的TCC方式了。
TXC这种事务隔离级别低的方式，对性能提升很大，其与正常单库效率仅降低13%，而TCC分布式事务一般会使事务处理能力降低一个量级。
在秒杀活动中，对某件秒杀商品的库存修改量非常频繁，造成数据热点的问题，此时可以考虑增加一张库存预减表，下单时，往库存预存表中增加一条记录，而商品的实际库存=商品库存量-预减数量。
阿里通过中间件“鹰眼”来实现链路跟踪的功能，实现思路是前端传入一个 标识ID ,然后经过各个服务时(服务框架需要进行改造，因为需要打印出特定的日志)，打印出拥有该标识ID的日志，然后通过日志收集，并进行实时计算处理，整理归纳出该标识ID的请求链路。
进行资金相关的操作时，考虑冻结金额，确保该金额可以在该事务中使用。