大数据体系【概念认知】系列-1：一致性 (未完)

2019独角兽企业重金招聘Python工程师标准>>>

     

前言：

      毫无疑问，一致性是大数据体系最为关键的几个技术要点之一，要设计，架构，实施一个大数据的组件，首先就先需要把

基本的几个概念给我清晰了。否则一切就是瞎扯。乱了章法，毫无逻辑。

     如果说Nosql 这个东西是大数据体系下的范畴，那么在讨论大数据整个体系之前，请首先探讨一下Nosql本身，如果我们要用【概念】来肢解NOSQL，那么最主要，需要实现，用来支撑Nsql作为大数据体系下生存的设计要点有如下：

        1： 简单的数据模型

            这个不同于分布式数据库，大多数的NoSQL系统采用了更加简单的数据模型，不管是MongoDB，Hbase，Redis，Memcache，还是其他的Nosql，都采取了【简单数据模型】，怎么简单？ 通常而言，每一个记录都拥有唯一的Key，查询的结果也就是Value，而且系统对于查询的支持也紧紧只到了记录级别的原子级，很少有Nosql支持外键和跨记录，跨segment的关系维护，这种一次操作获取单个记录的约定极大的增强了系统的可扩展性，消除了分布式事务的开销

        2：元数据和应用数据的分离

        ‍ 通常而言，Nosql需要维护两种数据: 元数据和应用数据，元数据是用于系统管理的，用来描述整个集群中间的状态的信息，如整个Nsql 机群的节点数和数据映射。而应用数据，就是通常你的业务系统，实际需求使用的数据，看场合不同而不同。

        3：弱一致性

            弱一致性？ 为什么一致性还需要分强弱？究竟一致性分几种，Nosql 是如何实现的？

        3：高水平扩展能力和低端硬件集群

            有效的降低成本，扩大的集群整体能力。

数据一致性理论

        1：CAP理论

                     1.1：CAP 概念

                       构图如下：

                            

                     1.1.1 一致性：

                        用简单的话语来解析一致性，就是系统在执行某项的操作以后还处于一致

的状态，比如：你更新以后，所有的用户都该读取到最新的值，这样的系统被认为具有强一致性。

                    

                    1.1.2：可用性

                      可用性：这个更简单了，什么是可用？我找你NoSQL取一个值，你不能三分钟转圈圈还不给我吧

，这个就叫不可用，可不可用有两个最基本的判定：

                        在“一定时间”，“返回一定的结果”。

                        在“一定的时间之内”这个是相当的有必要好的，要不然任何支付啊，交易啊，数据信息传递都是超时的存在。

                        “返回结果”，这个更加重要了，你不可能告诉前端，嘿，底层肯定会在一定时间内有动作的，但是这个动作

不给你数据，给你“excetpion...”

                    1.1.3：分区的容错性：

                        分区这个功能你可以完全的理解为一张大饼，被划分为多块，对数据的读取仿佛就是在吃这张大饼，本质上是若干个独立的分区，而分区之间互相连通但是没有依赖，可以动态的加入和离开。

                    1.2：令人头疼的满足关系

                            CAP这三大性质，是在分布式系统环境之中设计和部署时所需要考虑的单个重要的系统需求，通常而言，不能够同时的满足这三大性，举一个小小的例子：来说明，看图说话：

A，B就是两Client，真个系统目前只有2台机器，V0为数据，2台机器上都有V0，是一个副本存在。

                        

1：首先 A 更新了一下VO的值，比如更新为字符串：newString

2：既然V0跟新了，那么作为一个副本的存在，在G2上的V0也需要更新

3：正式更新：G1开始不断的发射消息到G2

4：G2中的值被改变，并且B开始读取到最新的一个值：newString. 图中表示为 v1：代表 value1

ok,一切顺利。如下图所示

而现实总是太残酷，你在更新的过程之中，过程3被中断了。也就是数据没有正确的被发射过去 ，此时数据就处于了一个不一致的状态。B读取到的数据就不是一个最新版的数据。

    CAP的模型告诉了我们一个事实，要想保证容错性质，那么就很有可能不能保证一致性。有的人会说，解决这个问题很简单，我们对于这个传递更新的操作做一个 同步操作不就好了？

        事实上来说，如果不加同步，G1-》G2的更新是不可知的。完全可能处于延迟，中断的状态。能保证“A“，”P”

当是是不能保证一直性“C"  一定满足。加上了同步之后，是能够保证一致性“c"了，但是消耗的时间增加了，在网络规模较

大的情况之下，当节点的数量成百上千的时候，这个开销被放大了，以至于服务是可用，但是没有使用的价值了。也就是说

“A“可用性不能保证了。

三个不能同时满足，那么我们就看看是否能够保证简单的满足2个：

    

                 1.3：CAP的取舍    

                      1.3.1：放弃P -牺牲分区容错性

                            如果你想避免容错性问题，最简单的方式，当然是将所有的数据都放置在一台机器之上，虽然无法保证

                    100%系统都可用，但是至少不会出现由分区带来的效果。

                      1.3.2：放弃A-放弃可用性

                                    放弃可用性是指在遇到了容错性的问题的过程之中，好不犹豫的以保证容错，一致性为先，即便服务不                                  能提供，即便服务肯定会超时。                        

                      1.3.3：放弃C-放弃-一致性

                             放弃一致性在这里并不是指不再保证我们的多个副本之间的一致，而是指只是暂时允许不一致的状态，在                             供服务使用之前来保证最终的一致性就可以了。

       

               

        2：数据一致性模型

                    强一致性

                                要求你无论在哪一台机器上来提交自己的数据，之后的提交都将获得最新的数据，对于一台机器而言，你只有一个副，当然在本地接受到以后就立即满足了强一致性，对于多副本的数据来说，那么就需要采取分布式的事务协议，如两段式提交，或Paxos

                       弱一致性

                            弱，是相对于强一致性而言的，弱一致性只需要保证Client在一定的时间窗口之后能读取到当前更新的数据。

                       最终一致性

                            最终一致性是弱一致性的一种分类，只需要保证在用户最终使用的过程之中,最终能够读取到即可。

                                    由最终一致性的概念又演化出来了：

                                       因果一致性

                                       读写一致性

                                       会话一致性

                                       单调读一致性

                                       时间轴一致性                    

    

        3：BASE模型

        4：数据一致性实现技术

                4.1：Quorum 系统的NWE策越

                4.2：两阶段提交协议

                4.3：时间戳

                4.4：PAXOS理论

                4.5：向量时钟理论

            

  

        

    

 

转载于:https://my.oschina.net/infiniteSpace/blog/333459