互联网行业是大势所趋，从招聘工资水平即可看出，那么如何提升自我技能，满足互联网行业技能要求？需要以目标为导向，进行技能提升，本文主要针对高并发分布式系统设计、架构(数据一致性)做了分析，祝各位早日走上属于自己的"成金之路"。
目录：
问题分析
概念解读
Most Simple原理解读
eBey、去哪儿、蘑菇街分布式事务案例分析
参考资料
1.问题解析
要想做架构，必须识别出问题，即是谁的问题，什么问题。
明显的，分布式架构解决的是高并发的问题，高并发下服务高可用和数据一致性问题问题；当规模规模较小时，单库HA即可满足请求，当业务规模持续增加，单库已经无法满足业务需求，业界主流做法，是对业务进行分表、分库，那么原来的有些业务，现在则要在一个事务中，保证两个库同时操作成功或操作不成功(一个库成功，一个库失败，要么重新尝试失败库操作直到成功，要么回滚成功库)。随之而来的问题既是如何保证分库时业务操作的数据一致性。理解高并发分布式架构、分布式系统数据一致性的问题、起源是第一步。
这里多啰嗦一点，分库后，每个库可以采取不同的语言，以时下很流行的微服务向外提供服务；但是业务量不大的情况下，使用微服务到增加了复杂性及技术成本。明白技术的起源，针对不同的业务量，采取适当的架构、以最恰当的方式承载业务，是架构师必须具备的能力。
2.常见概念解读：
a.关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
b.Base(basically available, soft state, eventually consistent)：一种 Acid 的替代方案，BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。化学理论中ACID是酸、Base恰好是碱。
c.CAP定律：在分布式系统中，同时满足"CAP定律"中的"一致性"、"可用性"和"分区容错性"三者是不可能的。
d.强一致：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性，常见的RDBMS。
e.弱一致性：系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
f.最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
为保证可用性，互联网分布式架构将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。
※幂等性(Idempotence)：分布式架构的基石，即同一个操作无论请求多少次，其结果都相同。
典型的是HTTP，Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
每个概念实际所解决的是人遇到的某个特定的问题，发现其背后所代表的问题，是理解高并发分布式架构、分布式系统数据一致性第二步。
3.Most Simple原理解读
假设有一个从账户取钱的远程API（可以是HTTP的，也可以不是），我们暂时用类函数的方式记为：
bool withdraw(account_id, amount)
withdraw的语义是从account_id对应的账户中扣除amount数额的钱；如果扣除成功则返回true，账户余额减少amount；如果扣除失败则返回false，账户余额不变。
值得注意的是：和本地环境相比，我们不能轻易假设环境的可靠性。
一种典型的场景是withdraw请求已经被服务器端正确处理，但服务器端的返回结果由于网络等原因被掉丢了，导致客户端无法得知处理结果。如果是在网页上，一些不恰当的设计可能会使用户认为上一次操作失败了，然后刷新页面，这就导致了withdraw被调用两次，账户也被多扣了一次钱。如图1所示：
一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把withdraw变成幂等的，比如：
int create_ticket()
bool idempotent_withdraw(ticket_id, account_id, amount)
create_ticket的语义是获取一个服务器端生成的唯一的处理号ticket_id，它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个ticket_id，一个ticket_id表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果。这样，idempotent_withdraw就符合幂等性了，客户端就可以放心地多次调用。
基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤：1.调用create_ticket()获取ticket_id；2.调用idempotent_withdraw(ticket_id, account_id, amount)。虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，加上idempotent_withdraw是幂等的，所以任何一步由于网络等原因失败或超时，客户端都可以重试，直到获得结果。如图所示：
互联网高并发分布式集群缓存JavaWeb开发J2EE项目开发java架构师