项目背景

<p>[TOC]</p> <h3>CAP理论</h3> <ul> <li> <p>C：Consistency 一致性 同一数据的多个副本是否实时相同。</p> </li> <li> <p>A：Availability 可用性 可用性：一定时间内，系统返回一个明确的结果，则称为该系统可用。</p> </li> <li>P：Partition tolerance 分区容错性 将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。</li> </ul> <p>CAP理论告诉我们，在分布式系统中，C、A、P三个条件中我们最多只能选择两个。</p> <h5>究竟选择哪两个条件较为合适呢？</h5> <p>对于一个业务系统来说，可用性和分区容错性是必须要满足的两个条件，主要原因：</p> <ul> <li> <p>提升整体性能 当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统，使用多个节点提供相同的功能，从而整体上提升系统的性能，这就是使用分布式系统的第一个原因。</p> </li> <li> <p>分区容错性 单一节点 或 多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。</p> </li> <li>可用性 在大谈用户体验的今天，如果业务系统时常出现“系统异常”、响应时间过长等情况，这使得用户对系统的好感度大打折扣。</li> </ul> <p>因此，我们只能通过牺牲一致性来换取系统的可用性和分区容错性。</p> <hr /> <h3>BASE理论</h3> <p>CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。下面来介绍下BASE理论。</p> <ul> <li> <p>BA：Basic Available 基本可用 整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。 1、当举行大促时，响应时间可以适当延长 2、给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。</p> </li> <li> <p>S：Soft State：柔性状态 同一数据的不同副本的状态，可以不需要实时一致。</p> </li> <li>E：Eventual Consisstency：最终一致性 同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。</li> </ul> <hr /> <h3>消息中间件的应用场景</h3> <ul> <li>消息中间件在分布式系统中的主要作用： 异步通讯、解耦、并发缓冲</li> <li>如图：通过引入消息中间件来解耦应用间（服务间）的直接调用，同时也会起到异步通讯和缓冲并发的作用 <img src="https://www.showdoc.cc/server/api/common/visitfile/sign/5b00b9dd100d0c82a0abcc49aa666535?showdoc=.jpg" alt="" /></li> </ul> <hr /> <h3>消息发送和投递的不可靠性</h3> <p>分布式部署环境下，需要通过网络进行通讯，可能会因为网络波动，引起数据不一致。 <img src="https://www.showdoc.cc/server/api/common/visitfile/sign/e3efd1bb2d473d78d7196acef2213c1e?showdoc=.jpg" alt="" /></p> <h3>JMS标准中的XA协议方式是否可以保障发送一致性？</h3> <p>JMS协议标准的API中，有很多支持XA协议（基于两阶段提交协议）的全局事务型接口。 JMS中的XA系列接口，可以提供分布式事务支持。 但引用了XA方式的分布式事务，又会带来很多的局限：</p> <ul> <li>要求业务操作的资源必须支持XA协议（并不是所有资源都支持XA）</li> <li>两阶段提交协议的成本</li> <li>持久化成本等DTP模型的局限性（全局锁定，成本高，性能低） <h5>引入XA，违背了柔性事务的初衷！</h5></li> </ul>