CAP之间本身就是处于互斥的，只能从这三者中选两个处理，对于CA、AP、CP都有它们自己的应用场景，要结合实际进行选择。
CA因为不考虑分区容忍度，所以它的所有操作需要在同一进程内完成；AP因为放弃数据一致性，适合数据要求不高但强调用户体验的项目，如博客、新闻资讯等；CP反之放弃了可用性，适合数据要求很高的交易系统，如银行交易、电商的订单交易等，就算是用户长时间等待，也要保障数据的完整可靠。CAP原则在实际项目中的运用，对于互联网应用来说，如果为了用户体验完全放弃数据一致性这也是不可取的，毕竟数据才是应用的根本。数据集成平台需要如何解决CAP互斥性呢？保障最终一致性的措施有很多，主要包括：分布式事务和TCC一致性方案。MySQL其实有一个两阶段提交的分布式事务方案，但是该方案存在严重的性能问题。
高可用的系统数据同步方案实践
比如，一个数据库的事务与多个数据库之间的XA事务性能可能相差10倍。在XA的事务处理过程中它会长期占用锁资源，所以一开始我们并不考虑这个方案。
解决跨系统间数据一致性的难题
提到数据一致性，我们很容易想到的就是数据库中的事务操作。事务的原子性和持久性可以确保在一个事务内，操作多条数据，要么都成功，要么都失败。这样在一个系统内部，我们可以很自然地使用数据库事务来保证数据一致性。但是在微服务的今天，一项操作会涉及到跨多个系统多个数据库的时候，用单一的数据库事务就没办法解决了。另外常见的一种情况就是：存在依赖情况的系统服务，例如业务端与用户端，需要数据同步来保障跨系统服务的数据一致性，很多时候采用何种数据同步方式，来保障数据应用的时效性至关重要。
为了能够更好的描述与理解数据一致性问题，通过一个案例来实战阐述：
数据集成平台CAP原则
做数据对接需要考虑一个是单向数据对接还是双向的数据对接，如果是单向的数据对接我们只需要考虑去获取数据，也就是从目标数字化系统或是其它数字化系统从我们数字化系统上获取数据，我们通过API进行获取或是传输数据给对方。如果是我们数字化系统上注册的会员数据需要同步给对方，对方那边注册的会员数据，修改的会员资料也需要同步过来，做到数据双方的实时更新，这个就是做数据的双向对接了。不仅我们需要传输数据过去，对方也需要传输数据给我们，不过这个不需要我们提供API接口给对方，对方也提供API接口给我们，只需要一方的API接口实现数据的获取跟传输就可以了。这种数据的双向对接会用在很多的平台上，我们在进行对接的时候也要考虑我们需要的是数据的获取就可以，还是还需要把数据传送过去。如果是需要做到双向对接，而我们只考虑单向对接的话，数据就会出现问题。比如对方那边注册的会员数据同步给我们了，但是我们这边注册的会员数据没同步过去，客户就无法在对方数字化系统上登录使用。
如何做数据对接呢，这个主要是通过API进行的，也就是提供数据方编写接口文档，告知对接方应该通过哪一些的字段什么样的形式进行数据的获取。进行数字化系统搭建数据对接时不仅仅要考虑数据的获取，也要考虑到数据的传输，具体要用什么样的形式要看双方对于数据的要求。如果是不仅需要获取也需要传输的，就要将这方面的数据对接考虑上，不然对接之后，数据会出现问题，这个是一个主要注意的点。其它的，只要是有API接口，对接就基本不会有什么问题。
假设存在订单系统与库存系统，分别是金蝶云ERP与一款WMS系统之间需要进行数据对接，在实际业务中订单的创建会伴随着系统仓库模块的库存减少。两个系统为分别部署，其应用数据也存放在独立的数据库中，两个系统间通过网络API接口进行通信。
一致性的难题的分析
采用异步协程架构模式设计的数据集成平台，通过MessageQueue，消息队列中间件。MQ通过将消息的发送和接收分离来实现应用程序的异步和解偶，同时MQ屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。在业务系统设计中，我们常常会存在一个平台系统金蝶，它关联同步了许许多多的系统的对接。利用MQ可以很好的解决系统对接和数据同步问题，同时可以忽略对接系统的稳定性等诉求。
文章为作者独立观点，不代表股票交易接口观点
股民评论