软件架构阅读笔记2
分布式数据架构:
伸缩策略：
分成三个维度：
1、按照业务类型进行垂直拆分
2、按照客户请求进行水平拆分（也就是常说的数据的sharding策略）
3、对于读远远大于写的数据进行读写分离和数据复制处理
内部交易数据的可伸缩性：
交易系统的数据主要分为三个大数据库集群：
1、主交易数据库集群，每一笔交易创建和状态的修改首先在这⾥完成，产生的变更再通过可靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数据库集群。该数据库集群的数据被水平拆分成多份，为了同时保证可伸缩性和高可靠性，每一个节点都会有与之对应的备用节点和failover节点，在出现故障的时候可以在秒级内切换到failover节点。
2、消费记录数据库集群，提供消费者更好的用户体验和需求；
3、商户查询数据库集群，提供商户更好的用户体验和需求；
对于分拆出来的各个数据节点，为了保证对上层应用系统的透明，我们研发一套数据中间产品来保证交易数据做到弹性扩容。
解决问题：大数据的处理。
数据的可靠性：
根据CAP和BASE原则，再结合支付宝系统的特点，设计了一套基于服务层面的分布式事务框架，他支持两阶段提交协议，但是做了很多的优化，在保证事务的ACID原则的前提下，确保事务的最终一致性 。叫做“柔性事物”策略。原理如下：
分布式事务框架：
实现：
1、一个完整的业务活动由一个主业务服务与若干从业务服务组成。
2、主业务服务负责发起并完成整个业务活动。
3、从业务服务提供TCC型业务操作。
4、业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的confirm操作，在业务活动取消时调用所有两阶段事务的cancel操作。
与2PC协议比较：
1、没有单独的Prepare阶段，降低协议成本
2、系统故障容忍度高，恢复简单
其中关键组件异步可靠消息策略如下：
1、若在第2、3、4步出现故障，业务系统自行决定回滚还是另起补偿机制；若在第6、7步出现异常，消息中心需要回查生产者；若在第8步出现异常，消息中心需要重试。第6步的确认消息由消息中心组件封装，应用系统无需感知。
2、此套机制保障了消息数据的完整性，进而保障了与通过异步可靠消息通讯的系统数据最终一致性。
3、某些业务的前置检查，需要消息中心提供指定条件回查机制。
总结：虽然通过这篇阅读不能学到实用的技术，但是开阔了眼界。看支付宝是如何发现问题，解决问题的。这些经验是要通过日积月累的，无数流血流泪趟雷中招锻炼出来的，没有近路可抄。
