JAVA小白分布式系统CAP原理浅析

         作为一个Java小白,目前所用的技术能够开发一个简易的单体Web项目，随着Java技术的迭代发展,以及环境的变化,一个单体项目以及不能够满足需求.当用户量和请求量的暴增,服务器的QPS呈指数级增长,单体系统会面临着性能方面的问题.

        为了解决这种将来可能会面临的问题，作为一名大学生在闲暇之余浅浅的对于分布式系统进行了学习并尝试做开发。

        由于单体项目整体的项目模块都是耦合在一起的,复杂程度高,如果将单体项目中的各个模块进行拆分,每个系统之间通过网络进行通信和协调，对外表现如一个系统,其实各个模块都是独立部署在各自的服务器上。如果将各个模块更加细粒度的拆分则就是经典的微服务架构风格。

        那么使用分布式的理念来开发系统,有哪些优势?在下认为,如果一个类似于用户下单的业务，他牵扯到的业务逻辑除了下单这个主流程之外，肯定为有一些前置的逻辑判断，比如判断订单状态，判断商品项的状态以及当前的用户信息等等，在单体项目中这是在一个方法中进行，如果我们把这些子任务交给其他系统进行,用官方语言说明就是将一个特定的计算任务划分为若干个并行运行的子任务，把这些子任务分散到不同的节点上，使它们同时在这些节点上运行，加快计算速度。并且，分布式系统具有计算迁移功能，如果某个节点上的负载太重，则可把其中一些作业移到其他节点去执行，从而减轻该节点的负载。并且分布式系统的可用性一定是高的，用集群来搭建的话，如果一个节点失效，那么其他节点可以继续进行，在单体项目中就无法实现。

        虽然分布式系统有诸多好处，那么也必然会面临一些问题和选择，比如一个分布式系统必然会面临到一个数据同步的问题，也就是数据的一致性问题，在与数据打交道的一些项目中，数据的真实性，一致性，及时性都是需要考虑的问题，那么分布式系统既然是针对于高并发的应用场景，那么对于海量数据的处理必然也应该是值得关注的一个问题。

        所以大家都在谈的CAP理论是对于理解分布式系统理念的一个非常有帮助的东西。采用维基百科上对于CAP理论的翻译：

CAP分为：
一致性(Consistency) :等同于所有节点访问同一份最新的数据副本
可用性（Availability)∶每次请求都能获取到非错的响应——但不能保证获取的数据为最新数据
分区容错性(Partition Tolerance)︰以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。(更易懂的解释:分区容忍性是尽管任意数量的消息被节点间的网络丢失或延迟，系统仍然正常运行)

        如此好的特性却不能同时满足，也是CAP理论的经典结论:在一个分布式系统中，要么AP，要么CP，要么AC，但是不存在CAP。那么为什么分区容忍性是一定要保证呢？是因为在网络环境中，网络波动，出现丢包等现象是常事所以分区容错性是必须要实现的。

        那么对于AP，还是CP如何进行选择呢？笼统的说,对于NoSQL数据库．更加注重可用性．所以就会是一个AP系统。对于分布式关系型数据库，必须要保证一致性，所以就会是一个CP系统。
但世事无绝对，虽然无法将三种特性同时实现，但我们仍然要辩证的来看待这一个理论，虽然无法将C，A完全实现，但仍然可以对其进行一定的"降级处理"。具体业务实现待我实操过后再来分享。

        那么基于CAP理论中的一致性和可用性的权衡结果,得出了BASE这样的一种结论，也就是Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）。

        BASE是基于CAP定理逐步演化而来的，其核心思想就是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性，由此来平衡CAP理论。基本可用就是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。而弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。那么最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。