通知设置 新通知
亚马逊云存储之S3(Simple Storage Service简单存储服务)
zkbhj 发表了文章 • 0 个评论 • 1584 次浏览 • 2018-01-26 17:19
S3是Simple Storage Service的缩写，即简单存储服务。亚马逊的名词缩写也都遵循这个习惯，例如Elastic Compute Cloud缩写为EC2等等。其他组织类似的命名有W3C，如果我们也follow这个习惯则IEEE会被写为IE3，CCTV就是C2TV，好像有点罗嗦了。
S3说的玄乎一点可以叫云存储，通俗一点就是大网盘。其概念类似于分布式文家系统，同Google的GFS应该在一个层面。
S3的定义如下
Amazon S3 is a web service that enables you to store data in the cloud. You can then download the data or use the data with other AWS services, such as Amazon Elastic Cloud Computer (EC2).
看来除了做网盘之用，S3存储的数据还可以被其他的亚马逊高层服务直接引用，这一点比国内的简单的网盘提供商高不少，亚马逊大网盘是其整体Solution中的有机组成部分。
基本概念
1、bucket – 类比于文件系统的目录
A bucket is a container for objects stored in Amazon S3. Every object is contained in a bucket. For example, if the object named photos/puppy.jpg is stored in the johnsmith bucket, then it is addressable using the URL http://johnsmith.s3.amazonaws.com/photos/puppy.jpg
似乎目录不能嵌套，也就是不能有子目录，官方的说法是起到namespace的作用，是访问控制的基本单位，其实丫还是个目录。
2、Object – 类比文件系统的文件
对象中带有对象名名，对象属性，对象本身最大5G，其实也还是个文件。
目前object有Versioning的属性（即对象不同历史版本的cache概念），这个是文件系统不具备的，在早期看到的S3资料中没有这一概念，应该是演进的结果，其面对的应该是有版本控制的需求的用户。
3、Keys – 类比文件名
key的样式也是URL，记住亚马逊的服务都是使用Web Service或REST方式访问的。
例如，http://doc.s3.amazonaws.com/20 ... .wsdl
其中‘doc’就是目录名（桶名），”2006-03-01/AmazonS3.wsdl”是文件名（对象名）。
如果引入了version则bucket + key + version唯一标示一个版本的文件。
4、Versioning – 类比CVS中的一个版本
下面是一些实现原理的描述。
<图片缺失...>
同名文件的写入，并不覆盖已有文件而是增加了一个最新的文件版本。
同样下面的删除也不真正删除，而是mark了删除标记。
<图片缺失...>
当最新版本mark为deleted之后，对该对象的get操作返回404错误，除非明确指定一个历史版本。
当然也可以指定版本永久删除其中一个拷贝。
5、Regions – 文件存储的地理位置
这个也是文件系统中不存在的，就是不同的地理区域，用户可以指定将文件存在某个国家的服务器。我个人认为，这不是一个很好的概念，作为云的提供商，应该对于应用屏蔽这些部署细节。工程实现同技术理想还是有差距。目前其可以指定的server位置有美国、爱尔兰、新加坡等地。
接口API
常用的API就是读、写、增、删、改、查等等。使用标准的SOAP和REST定义。
尤其一提的是对于对象的获取，除了用http直接按照C/S方式获取之外，亚马逊支持BT协议，也就是说提供种子。从用户角度想，亚马逊会 charge更少的钱，但同时亚马逊自身也会减负。bt下载的速度就不太稳定了，基本取决于种子“质量”也就是取决于对文件感兴趣的人的多寡。例如命名为 “XX门”估计文件下载能够快很多。
数据有什么用
当数据上传到aws云之后，可以很多服务可以使用例如。
Amazon ElasticCompute Cloud
Amazon Elastic MapReduce
Amazon Import/Export等。
一点遗憾
没有看到如何实现分布式文件系统的资料，这是了解其Scale以及可靠性等的关键，或许亚马逊没有google大方，没有提供类似GFS之类的底层机制实现文档。
参考
http://aws.amazon.com/s3/#functionality
http://docs.amazonwebservices. ... 3-01/
http://developer.amazonwebserv ... %3D24
http://www.kernelchina.org/con ... %25A1 查看全部
S3说的玄乎一点可以叫云存储，通俗一点就是大网盘。其概念类似于分布式文家系统，同Google的GFS应该在一个层面。
S3的定义如下
Amazon S3 is a web service that enables you to store data in the cloud. You can then download the data or use the data with other AWS services, such as Amazon Elastic Cloud Computer (EC2).
看来除了做网盘之用，S3存储的数据还可以被其他的亚马逊高层服务直接引用，这一点比国内的简单的网盘提供商高不少，亚马逊大网盘是其整体Solution中的有机组成部分。
基本概念
1、bucket – 类比于文件系统的目录
A bucket is a container for objects stored in Amazon S3. Every object is contained in a bucket. For example, if the object named photos/puppy.jpg is stored in the johnsmith bucket, then it is addressable using the URL http://johnsmith.s3.amazonaws.com/photos/puppy.jpg
似乎目录不能嵌套，也就是不能有子目录，官方的说法是起到namespace的作用，是访问控制的基本单位，其实丫还是个目录。
2、Object – 类比文件系统的文件
对象中带有对象名名，对象属性，对象本身最大5G，其实也还是个文件。
目前object有Versioning的属性（即对象不同历史版本的cache概念），这个是文件系统不具备的，在早期看到的S3资料中没有这一概念，应该是演进的结果，其面对的应该是有版本控制的需求的用户。
3、Keys – 类比文件名
key的样式也是URL，记住亚马逊的服务都是使用Web Service或REST方式访问的。
例如，http://doc.s3.amazonaws.com/20 ... .wsdl
其中‘doc’就是目录名（桶名），”2006-03-01/AmazonS3.wsdl”是文件名（对象名）。
如果引入了version则bucket + key + version唯一标示一个版本的文件。
4、Versioning – 类比CVS中的一个版本
下面是一些实现原理的描述。
<图片缺失...>
同名文件的写入，并不覆盖已有文件而是增加了一个最新的文件版本。
同样下面的删除也不真正删除，而是mark了删除标记。
<图片缺失...>
当最新版本mark为deleted之后，对该对象的get操作返回404错误，除非明确指定一个历史版本。
当然也可以指定版本永久删除其中一个拷贝。
5、Regions – 文件存储的地理位置
这个也是文件系统中不存在的，就是不同的地理区域，用户可以指定将文件存在某个国家的服务器。我个人认为，这不是一个很好的概念，作为云的提供商，应该对于应用屏蔽这些部署细节。工程实现同技术理想还是有差距。目前其可以指定的server位置有美国、爱尔兰、新加坡等地。
接口API
常用的API就是读、写、增、删、改、查等等。使用标准的SOAP和REST定义。
尤其一提的是对于对象的获取，除了用http直接按照C/S方式获取之外，亚马逊支持BT协议，也就是说提供种子。从用户角度想，亚马逊会 charge更少的钱，但同时亚马逊自身也会减负。bt下载的速度就不太稳定了，基本取决于种子“质量”也就是取决于对文件感兴趣的人的多寡。例如命名为 “XX门”估计文件下载能够快很多。
数据有什么用
当数据上传到aws云之后，可以很多服务可以使用例如。
Amazon ElasticCompute Cloud
Amazon Elastic MapReduce
Amazon Import/Export等。
一点遗憾
没有看到如何实现分布式文件系统的资料，这是了解其Scale以及可靠性等的关键，或许亚马逊没有google大方，没有提供类似GFS之类的底层机制实现文档。
参考
http://aws.amazon.com/s3/#functionality
http://docs.amazonwebservices. ... 3-01/
http://developer.amazonwebserv ... %3D24
http://www.kernelchina.org/con ... %25A1 查看全部
S3是Simple Storage Service的缩写，即简单存储服务。亚马逊的名词缩写也都遵循这个习惯，例如Elastic Compute Cloud缩写为EC2等等。其他组织类似的命名有W3C，如果我们也follow这个习惯则IEEE会被写为IE3，CCTV就是C2TV，好像有点罗嗦了。
S3说的玄乎一点可以叫云存储，通俗一点就是大网盘。其概念类似于分布式文家系统，同Google的GFS应该在一个层面。
S3的定义如下
看来除了做网盘之用，S3存储的数据还可以被其他的亚马逊高层服务直接引用，这一点比国内的简单的网盘提供商高不少，亚马逊大网盘是其整体Solution中的有机组成部分。
基本概念
1、bucket – 类比于文件系统的目录
似乎目录不能嵌套，也就是不能有子目录，官方的说法是起到namespace的作用，是访问控制的基本单位，其实丫还是个目录。
2、Object – 类比文件系统的文件
对象中带有对象名名，对象属性，对象本身最大5G，其实也还是个文件。
目前object有Versioning的属性（即对象不同历史版本的cache概念），这个是文件系统不具备的，在早期看到的S3资料中没有这一概念，应该是演进的结果，其面对的应该是有版本控制的需求的用户。
3、Keys – 类比文件名
key的样式也是URL，记住亚马逊的服务都是使用Web Service或REST方式访问的。
例如，http://doc.s3.amazonaws.com/20 ... .wsdl
其中‘doc’就是目录名（桶名），”2006-03-01/AmazonS3.wsdl”是文件名（对象名）。
如果引入了version则bucket + key + version唯一标示一个版本的文件。
4、Versioning – 类比CVS中的一个版本
下面是一些实现原理的描述。
<图片缺失...>
同名文件的写入，并不覆盖已有文件而是增加了一个最新的文件版本。
同样下面的删除也不真正删除，而是mark了删除标记。
<图片缺失...>
当最新版本mark为deleted之后，对该对象的get操作返回404错误，除非明确指定一个历史版本。
当然也可以指定版本永久删除其中一个拷贝。
5、Regions – 文件存储的地理位置
这个也是文件系统中不存在的，就是不同的地理区域，用户可以指定将文件存在某个国家的服务器。我个人认为，这不是一个很好的概念，作为云的提供商，应该对于应用屏蔽这些部署细节。工程实现同技术理想还是有差距。目前其可以指定的server位置有美国、爱尔兰、新加坡等地。
接口API
常用的API就是读、写、增、删、改、查等等。使用标准的SOAP和REST定义。
尤其一提的是对于对象的获取，除了用http直接按照C/S方式获取之外，亚马逊支持BT协议，也就是说提供种子。从用户角度想，亚马逊会 charge更少的钱，但同时亚马逊自身也会减负。bt下载的速度就不太稳定了，基本取决于种子“质量”也就是取决于对文件感兴趣的人的多寡。例如命名为 “XX门”估计文件下载能够快很多。
数据有什么用
当数据上传到aws云之后，可以很多服务可以使用例如。
Amazon ElasticCompute Cloud
Amazon Elastic MapReduce
Amazon Import/Export等。
一点遗憾
没有看到如何实现分布式文件系统的资料，这是了解其Scale以及可靠性等的关键，或许亚马逊没有google大方，没有提供类似GFS之类的底层机制实现文档。
参考
http://aws.amazon.com/s3/#functionality
http://docs.amazonwebservices. ... 3-01/
http://developer.amazonwebserv ... %3D24
http://www.kernelchina.org/con ... %25A1
S3说的玄乎一点可以叫云存储，通俗一点就是大网盘。其概念类似于分布式文家系统，同Google的GFS应该在一个层面。
S3的定义如下
Amazon S3 is a web service that enables you to store data in the cloud. You can then download the data or use the data with other AWS services, such as Amazon Elastic Cloud Computer (EC2).
看来除了做网盘之用，S3存储的数据还可以被其他的亚马逊高层服务直接引用，这一点比国内的简单的网盘提供商高不少，亚马逊大网盘是其整体Solution中的有机组成部分。
基本概念
1、bucket – 类比于文件系统的目录
A bucket is a container for objects stored in Amazon S3. Every object is contained in a bucket. For example, if the object named photos/puppy.jpg is stored in the johnsmith bucket, then it is addressable using the URL http://johnsmith.s3.amazonaws.com/photos/puppy.jpg
似乎目录不能嵌套，也就是不能有子目录，官方的说法是起到namespace的作用，是访问控制的基本单位，其实丫还是个目录。
2、Object – 类比文件系统的文件
对象中带有对象名名，对象属性，对象本身最大5G，其实也还是个文件。
目前object有Versioning的属性（即对象不同历史版本的cache概念），这个是文件系统不具备的，在早期看到的S3资料中没有这一概念，应该是演进的结果，其面对的应该是有版本控制的需求的用户。
3、Keys – 类比文件名
key的样式也是URL，记住亚马逊的服务都是使用Web Service或REST方式访问的。
例如，http://doc.s3.amazonaws.com/20 ... .wsdl
其中‘doc’就是目录名（桶名），”2006-03-01/AmazonS3.wsdl”是文件名（对象名）。
如果引入了version则bucket + key + version唯一标示一个版本的文件。
4、Versioning – 类比CVS中的一个版本
下面是一些实现原理的描述。
<图片缺失...>
同名文件的写入，并不覆盖已有文件而是增加了一个最新的文件版本。
同样下面的删除也不真正删除，而是mark了删除标记。
<图片缺失...>
当最新版本mark为deleted之后，对该对象的get操作返回404错误，除非明确指定一个历史版本。
当然也可以指定版本永久删除其中一个拷贝。
5、Regions – 文件存储的地理位置
这个也是文件系统中不存在的，就是不同的地理区域，用户可以指定将文件存在某个国家的服务器。我个人认为，这不是一个很好的概念，作为云的提供商，应该对于应用屏蔽这些部署细节。工程实现同技术理想还是有差距。目前其可以指定的server位置有美国、爱尔兰、新加坡等地。
接口API
常用的API就是读、写、增、删、改、查等等。使用标准的SOAP和REST定义。
尤其一提的是对于对象的获取，除了用http直接按照C/S方式获取之外，亚马逊支持BT协议，也就是说提供种子。从用户角度想，亚马逊会 charge更少的钱，但同时亚马逊自身也会减负。bt下载的速度就不太稳定了，基本取决于种子“质量”也就是取决于对文件感兴趣的人的多寡。例如命名为 “XX门”估计文件下载能够快很多。
数据有什么用
当数据上传到aws云之后，可以很多服务可以使用例如。
Amazon ElasticCompute Cloud
Amazon Elastic MapReduce
Amazon Import/Export等。
一点遗憾
没有看到如何实现分布式文件系统的资料，这是了解其Scale以及可靠性等的关键，或许亚马逊没有google大方，没有提供类似GFS之类的底层机制实现文档。
参考
http://aws.amazon.com/s3/#functionality
http://docs.amazonwebservices. ... 3-01/
http://developer.amazonwebserv ... %3D24
http://www.kernelchina.org/con ... %25A1
几种常见的效应理论
zkbhj 发表了文章 • 0 个评论 • 1448 次浏览 • 2017-12-27 10:05
效应理论
效应，或效果，是指在有限环境下，一些因素和一些结果而构成的一种因果现象，多用于对一种自然现象和社会现象的描述，效应一词使用的泛围较广，并不一定指严格的科学定理、定律中的因果关系。
蝴蝶效应
1、蝴蝶效应是气象学家洛伦兹1963年提出来的。
其大意为：一只南美洲亚马孙河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可能在两周后引起美国德克萨斯引起一场龙卷风。其原因在于：蝴蝶翅膀的运动，导致其身边的空气系统发生变化，并引起微弱气流的产生，而微弱气流的产生又会引起它四周空气或其他系统产生相应的变化，由此引起连锁反映，最终导致其他系统的极大变化。
此效应说明，事物发展的结果，对初始条件具有极为敏感的依赖性，初始条件的极小偏差，将会引起结果的极大差异。
“蝴蝶效应”在社会学界用来说明：一个坏的微小的机制，如果不加以及时地引导、调节，会给社会带来非常大的危害，戏称为“龙卷风”或“风暴”；一个好的微小的机制，只要正确指引，经过一段时间的努力，将会产生轰动效应，或称为“革命”。
2、蝴蝶效应。什么是蝴蝶效应？1979年12月，洛伦兹在华盛顿的美国科学促进会的一次讲演中提出：一只蝴蝶在巴西扇动翅膀，有可能会在美国的德克萨斯引起一场龙卷风。他的演讲和结论给人们留下了极其深刻的印象。从此以后，所谓“蝴蝶效应”之说就不胫而走，名声远扬了。
“蝴蝶效应”之所以令人着迷、令人激动、发人深省，不但在于其大胆的想象力和迷人的美学色彩，更在于其深刻的科学内涵和内在的哲学魅力。
从科学的角度来看，“蝴蝶效应”反映了混沌运动的一个重要特征：系统的长期行为对初始条件的敏感依赖性。
经典动力学的传统观点认为：系统的长期行为对初始条件是不敏感的，即初始条件的微小变化对未来状态所造成的差别也是很微小的。可混沌理论向传统观点提出了挑战。混沌理论认为在混沌系统中，初始条件的十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。我们可以用在西方流传的一首民谣对此作形象的说明。这首民谣说：
丢失一个钉子，坏了一只蹄铁；
坏了一只蹄铁，折了一匹战马；
折了一匹战马，伤了一位骑士；
伤了一位骑士，输了一场战斗；
输了一场战斗，亡了一个帝国。
马蹄铁上一个钉子是否会丢失，本是初始条件的十分微小的变化，但其“长期”效应却是一个帝国存与亡的根本差别。这就是军事和政治领域中的所谓“蝴蝶效应”，听起来有点不可思议，但是确实能够造成这样的恶果。一些看似极微小的事情，却有可能造成集体内部的分崩离析，一定要防微杜渐，否则，悔之晚矣。
“蝴蝶效应”启示录，古往今来知多少？
破窗效应
政治学家威尔逊和犯罪学家凯琳提出了一个“破窗理论”。这个理论认为：如果有人打坏了一个建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户玻璃。久而久之，这些破窗户就给人造成一种无序的感觉。结果在这种公众麻木不仁的氛围中，犯罪就会滋生、繁荣。“破窗理论”不仅仅在社会管理中有所应用，而且也被用在了现代企业管理中。
近因效应
最近、最后的印象，往往是最强烈的，可以冲淡在此之前产生的各种因素，这就是近因效应。有这样一个例子：面试过程中，主考官告诉考生可以走了，可当考生要离开考场时，主考官又叫住他，对他说，你已回答了我们所提出的问题，评委觉得不怎么样，你对此怎么看？其实，考官做出这么一种设置，是对毕业生的最后一考，想借此考察一下应聘者的心理素质和临场应变能力。如果这一道题回答得精彩，大可弥补此前面试中的缺憾；如果回答得不好，可能会由于这最后的关键性试题而使应聘者前功尽弃。
青蛙效应
从前有一则水煮青蛙的寓言：如果把一只青蛙放在沸水中，它便会纵身而出；如果把一只青蛙放进温水中，它会感到舒舒服服的。然后你再慢慢升温，即使升至摄氏80°，青蛙也仍然会若无其事地待在那水里。随着温度的继续上升至90°- 100°时，青蛙就会变得越来越虚弱，在此情况下，青蛙已经失去自我脱险的能力了，直至把它煮熟为止。在第二种状况下，青蛙为什么不能自我摆脱险境呢？这是因为青蛙内部感应自下而上威胁的器官，只能感应出激烈的环境变化，而对缓慢、渐进的环境变化却不能及时做出感应。这就是一种“青蛙效应”。
“青蛙效应”告诉我们一个道理：“生于忧患，死于安逸。”
美人效应
罗马一家自助餐厅的老板想出一个赚小费的妙计。他请来一位非常漂亮的姑娘，坐在柜台边收钱，以便使男客们神魂颠倒，慷慨解囊。谁知那位姑娘上班后没过几天，就对老板说：“我想，我不如以前漂亮了。”老板忙问：“这是怎么回事呢？”“现在，所有的男客都在柜台边反复地数找给他们的零钱。”
鲶鱼效应
西班牙人爱吃沙丁鱼，但沙丁鱼很娇贵，极不适应离开大海后的环境。用不了多久就会死掉。为延长它的活命期，当地渔民想出了一个办法，将几条沙丁鱼的天敌鲶鱼放在运输容器里。为了躲避天敌的吞食，沙丁鱼在有限的空间里快速游动，反而保持了旺盛的生命力。这就是经济学上讲的鲶鱼效应。为了更好地生存发展下去，惧者必然会比其他人更用功，而越用功，跑的就越快。
晕轮效应
晕轮原指月亮被光环笼罩时产生的模糊不清的现象。晕轮效应是一种普通存在的心理现象，即对一个人进行评价时，往往会因对他的某一品质特征的强烈、清晰的感知，而掩盖了其他方面的品质。
毕业生在求职应聘中，如果能够巧妙地运用这种晕轮效应，把自身的优势充分地展现出来，一定会给招聘考官留下深刻的印象，赢得对方的赏识，取得面试的成功。比如，当招聘者问及你的英语水平时，你便用英语熟练地与其交谈，必然会引起招聘者的极大兴趣，很可能当场便与你拍板“成交”。但在运用这一效应时一定要注意，不能刻意制造“光环”效果，那种虚妄做出的行为，往往适得其反。
木桶效应
在管理学上有一个著名的“木桶理论”，是指用一个木桶来装水，如果组成木桶的木板参差不齐，那么它能盛下的水的容量不是由这个木桶中最长的木板来决定的，而是由这个木桶中最短的木板决定的，所以它又被称为“短板效应”。由此可见，在事物的发展过程中，“短板”的长度决定其整体发展程度。正如，一件产品质量的高低，取决于那个品质最次的零部件，而不是取决于那个品质最好的零部件；一个组织的整体素质高低，不是取决于这个组织的最优秀分子的素质，而是取决于这个组织中最一般分子的素质一样。……此种现象在管理学中通常被称为“木桶效应”。
“木桶效应”对你有何启示？
马太效应
《圣经》马太福音章节中有这样一段故事:“一个人要往外国去，就叫了仆人来，把他的家业交给他们。按着各人的才干，给他们银子。一个给了五千，一个给了二千，一个给了一千。就往外国去了。那领五千的，随既拿去做买卖，另外赚了五千。那领二千的，也照样另赚了二千。 但那领一千的，去掘开地，把主人的银子埋藏了。过了许久，那些仆人的主人来了，和他们算账。那领五千银子的，又带着那另外的五千来，说，主阿，你交给我五千银子，请看，我又赚了五千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领二千的也来说，主阿，你交给我二千银子，请看，我又赚了二千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领一千的，也来说，主阿，我知道你是忍心的人，没有种的地方要收割，没有散的地方要聚敛。我就害怕，去把你的一千银子埋藏在地里。请看，你的原银在这里。主人回答说，你这又恶又懒的仆人，你既知道我没有种的地方要收割，没有散的地方要聚敛。就当把我的银子放给兑换银钱的人，到我来的时候，可以连本带利收回。夺过他这一千来，给那有一万的。凡有的，还要加给他，叫他有馀。没有的，连他所有的，也要夺过来。”
科学家罗卜特.默特把故事中的现象称为“马太效应”——即任何个人、群体或地区，一旦在某一方面获得成功和进步，就会产生一种积累优势，就会有更多的机会取得更大的成功和进步。
现实生活中“马太效应”无处不在。
狄德罗效应
18世纪的法国哲学家狄德罗在朋友送他一件华贵的睡袍后，穿在家里，总觉得家具颜色不对，地毯的针脚也粗得吓人，于是为了与睡袍配套，旧的东西先后更新，终于跟上了睡袍的档次。经济学家将其称为“狄德罗效应”，又称“配套效应”。
沉锚效应
鲁迅先生曾于1927年在《无声的中国》一文中写下了这样一段文字："中国人的性情总是喜欢调和、折中的，譬如你说，这屋子太暗，说在这里开一个天窗，大家一定是不允许的，但如果你主张拆掉屋顶，他们就会来调和，愿意开天窗了。”这种先提出很大的要求，接着提出较小较少的要求，在心理学上被称为"沉锚效应"。
如你想让你的朋友陪你出去玩，若说：“陪我出去玩好吗？”朋友不一定去。但如果说：“出去走走，随你的便，是去喝咖啡，唱卡拉OK，还是逛书店？”他很可能选定他最喜欢的，如“逛书店”而陪你出门。
再如早上喝豆浆时，如果服务员问：“先生要不要加鸡蛋”，“加”与“不加”即是“沉锚”。但若问“请问先生，加一个鸡蛋还是两个鸡蛋？”则“一个”或“两个”便是“沉锚”了。显然第二个问题更有利于促销，这就是沉锚效应在起作用。
一对未确定关系的情人，如果说“我们相处一段，看是否合适”，就不如说“相互关爱吧，我们能走到一起”具有沉锚效应。
研究沉锚效应是人际交往、谈判与经商不可缺少的课程。
从众效应
从众效应是一种追随别人的行为的常见的心理效应。这种效应有时是积极的，如别人献血你也去献；有时是消极的，如看到别人在公园摘花，自己也跟着去摘花。
有这么一个实验：某高校举办一次特殊的活动，请德国化学家展示他最近发明的某种挥发性液体。当主持人将满脸大胡子的“德国化学家”介绍给阶梯教师里的学生后，化学家用沙哑的嗓音向同学们说：“我最近研究出了一种强烈挥发性的液体，现在我要进行实验，看要用多长时间能从讲台挥发到全教室，凡闻到一点味道的，马上举手，我要计算时间。”说着，他打开了密封的瓶塞，让透明的液体挥发……不一会，后排的同学，前排的同学，中间的同学都先后举起了手。不到2分钟，全体同学举起了手。
此时，“化学家”一把把大胡子扯下，拿掉墨镜，原来他是本校的德语老师。他笑着说：“我这里装的是蒸馏水！”
这个实验，生动的说明了同学之间的从众效应——看到别人举手，也跟着举手，但他们并不是撒谎，而是受“化学家”的言语暗示和其他同学举手的行为暗示，似乎真的闻到了一种味道，于是举起了手。
有一个晴朗的夜晚，满天星斗，许多人站在车站站台上等待即将到来的火车。此时，一个人仰着脖子晃动着脑袋往天上寻看，在一旁的人好奇的以为他看到的人造卫星、流星或不明飞行物，也跟着向天空动张西望。其实，这位先生只是脖颈酸痛，他是在做放松活动，并非观察天空。那些跟着仰望星空的人实际上是被从众效应左右了。
积极的从众效应可以互相激励情绪，作出勇敢之举；消极的从众效应则互相壮胆干坏事——如看到别人乱穿马路，不少人也跟着走捷径。有人正是利用从众效应来行骗人之术，最生动的例子是玩所谓的“三张牌”，让人押宝。猜红桃A在哪里，可押50元、100元、200元。此时总有三五个人抢着参与，而不明真相的人不知道他们是“托儿”，被从众效应激化，也参加押宝。当然，结果肯定要输——因为最初参与的三五人同庄家全是一伙的。
聚众闹事行为多是由于个性化效应和从众效应激发起来的冲动行为。
过度理由效
应有这样一个有趣的故事：一位老人在一个小乡村里休养，但附近却住着一些十分顽皮的孩子，他们天天互相追逐打闹，喧哗的吵闹声使老人无法好好休息，在屡禁不止的情况下，老人想出了一个办法。
他把孩子们都叫到一起，告诉他们谁叫的声音越大，谁得到的报酬就越多，他每次都根据孩子们吵闹的情况给予不同的奖励。到孩子们已经习惯于获取奖励的时候，老人开始逐渐减少所给的奖励，最后无论孩子们怎么吵，老人一分钱也不给。
结果，孩子们认为受到的待遇越来越不公正，认为"不给钱了谁还给你叫"，再也不到老人所住的房子附近大声吵闹。
这就是由于社会心理学上所说的"过度理由效应"。每个人都力图使自己和别人的行为看起来合理，因而总是为行为寻找原因，一旦找到足够的原因，人们就很少再继续找下去，而且，在寻找原因时，总是先找那些显而易见的外在原因，因此，如果外部原因足以对行为做出解释时，人们一般就不再去寻找内部的原因了。
行为如果只用外在理由来解释，那么，一旦外在理由不再存在，这种行为也将趋于终止，因此，如果我们希望某种行为得以保持，就不要给它足够的外部理由。
公司老板如果希望自己的职员努力工作，就不要给予职员太多的物质奖励，而要让职员认为他自己勤奋、上进，喜欢这份工作，喜欢这家公司；希望孩子努力学习的家长，也不能用太多的金钱和奖品去奖励孩子的好成绩，而要让孩子觉得自己喜欢学习，学习是有趣的事。
查看全部
效应，或效果，是指在有限环境下，一些因素和一些结果而构成的一种因果现象，多用于对一种自然现象和社会现象的描述，效应一词使用的泛围较广，并不一定指严格的科学定理、定律中的因果关系。
蝴蝶效应
1、蝴蝶效应是气象学家洛伦兹1963年提出来的。
其大意为：一只南美洲亚马孙河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可能在两周后引起美国德克萨斯引起一场龙卷风。其原因在于：蝴蝶翅膀的运动，导致其身边的空气系统发生变化，并引起微弱气流的产生，而微弱气流的产生又会引起它四周空气或其他系统产生相应的变化，由此引起连锁反映，最终导致其他系统的极大变化。
此效应说明，事物发展的结果，对初始条件具有极为敏感的依赖性，初始条件的极小偏差，将会引起结果的极大差异。
“蝴蝶效应”在社会学界用来说明：一个坏的微小的机制，如果不加以及时地引导、调节，会给社会带来非常大的危害，戏称为“龙卷风”或“风暴”；一个好的微小的机制，只要正确指引，经过一段时间的努力，将会产生轰动效应，或称为“革命”。
2、蝴蝶效应。什么是蝴蝶效应？1979年12月，洛伦兹在华盛顿的美国科学促进会的一次讲演中提出：一只蝴蝶在巴西扇动翅膀，有可能会在美国的德克萨斯引起一场龙卷风。他的演讲和结论给人们留下了极其深刻的印象。从此以后，所谓“蝴蝶效应”之说就不胫而走，名声远扬了。
“蝴蝶效应”之所以令人着迷、令人激动、发人深省，不但在于其大胆的想象力和迷人的美学色彩，更在于其深刻的科学内涵和内在的哲学魅力。
从科学的角度来看，“蝴蝶效应”反映了混沌运动的一个重要特征：系统的长期行为对初始条件的敏感依赖性。
经典动力学的传统观点认为：系统的长期行为对初始条件是不敏感的，即初始条件的微小变化对未来状态所造成的差别也是很微小的。可混沌理论向传统观点提出了挑战。混沌理论认为在混沌系统中，初始条件的十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。我们可以用在西方流传的一首民谣对此作形象的说明。这首民谣说：
丢失一个钉子，坏了一只蹄铁；
坏了一只蹄铁，折了一匹战马；
折了一匹战马，伤了一位骑士；
伤了一位骑士，输了一场战斗；
输了一场战斗，亡了一个帝国。
马蹄铁上一个钉子是否会丢失，本是初始条件的十分微小的变化，但其“长期”效应却是一个帝国存与亡的根本差别。这就是军事和政治领域中的所谓“蝴蝶效应”，听起来有点不可思议，但是确实能够造成这样的恶果。一些看似极微小的事情，却有可能造成集体内部的分崩离析，一定要防微杜渐，否则，悔之晚矣。
“蝴蝶效应”启示录，古往今来知多少？
破窗效应
政治学家威尔逊和犯罪学家凯琳提出了一个“破窗理论”。这个理论认为：如果有人打坏了一个建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户玻璃。久而久之，这些破窗户就给人造成一种无序的感觉。结果在这种公众麻木不仁的氛围中，犯罪就会滋生、繁荣。“破窗理论”不仅仅在社会管理中有所应用，而且也被用在了现代企业管理中。
近因效应
最近、最后的印象，往往是最强烈的，可以冲淡在此之前产生的各种因素，这就是近因效应。有这样一个例子：面试过程中，主考官告诉考生可以走了，可当考生要离开考场时，主考官又叫住他，对他说，你已回答了我们所提出的问题，评委觉得不怎么样，你对此怎么看？其实，考官做出这么一种设置，是对毕业生的最后一考，想借此考察一下应聘者的心理素质和临场应变能力。如果这一道题回答得精彩，大可弥补此前面试中的缺憾；如果回答得不好，可能会由于这最后的关键性试题而使应聘者前功尽弃。
青蛙效应
从前有一则水煮青蛙的寓言：如果把一只青蛙放在沸水中，它便会纵身而出；如果把一只青蛙放进温水中，它会感到舒舒服服的。然后你再慢慢升温，即使升至摄氏80°，青蛙也仍然会若无其事地待在那水里。随着温度的继续上升至90°- 100°时，青蛙就会变得越来越虚弱，在此情况下，青蛙已经失去自我脱险的能力了，直至把它煮熟为止。在第二种状况下，青蛙为什么不能自我摆脱险境呢？这是因为青蛙内部感应自下而上威胁的器官，只能感应出激烈的环境变化，而对缓慢、渐进的环境变化却不能及时做出感应。这就是一种“青蛙效应”。
“青蛙效应”告诉我们一个道理：“生于忧患，死于安逸。”
美人效应
罗马一家自助餐厅的老板想出一个赚小费的妙计。他请来一位非常漂亮的姑娘，坐在柜台边收钱，以便使男客们神魂颠倒，慷慨解囊。谁知那位姑娘上班后没过几天，就对老板说：“我想，我不如以前漂亮了。”老板忙问：“这是怎么回事呢？”“现在，所有的男客都在柜台边反复地数找给他们的零钱。”
鲶鱼效应
西班牙人爱吃沙丁鱼，但沙丁鱼很娇贵，极不适应离开大海后的环境。用不了多久就会死掉。为延长它的活命期，当地渔民想出了一个办法，将几条沙丁鱼的天敌鲶鱼放在运输容器里。为了躲避天敌的吞食，沙丁鱼在有限的空间里快速游动，反而保持了旺盛的生命力。这就是经济学上讲的鲶鱼效应。为了更好地生存发展下去，惧者必然会比其他人更用功，而越用功，跑的就越快。
晕轮效应
晕轮原指月亮被光环笼罩时产生的模糊不清的现象。晕轮效应是一种普通存在的心理现象，即对一个人进行评价时，往往会因对他的某一品质特征的强烈、清晰的感知，而掩盖了其他方面的品质。
毕业生在求职应聘中，如果能够巧妙地运用这种晕轮效应，把自身的优势充分地展现出来，一定会给招聘考官留下深刻的印象，赢得对方的赏识，取得面试的成功。比如，当招聘者问及你的英语水平时，你便用英语熟练地与其交谈，必然会引起招聘者的极大兴趣，很可能当场便与你拍板“成交”。但在运用这一效应时一定要注意，不能刻意制造“光环”效果，那种虚妄做出的行为，往往适得其反。
木桶效应
在管理学上有一个著名的“木桶理论”，是指用一个木桶来装水，如果组成木桶的木板参差不齐，那么它能盛下的水的容量不是由这个木桶中最长的木板来决定的，而是由这个木桶中最短的木板决定的，所以它又被称为“短板效应”。由此可见，在事物的发展过程中，“短板”的长度决定其整体发展程度。正如，一件产品质量的高低，取决于那个品质最次的零部件，而不是取决于那个品质最好的零部件；一个组织的整体素质高低，不是取决于这个组织的最优秀分子的素质，而是取决于这个组织中最一般分子的素质一样。……此种现象在管理学中通常被称为“木桶效应”。
“木桶效应”对你有何启示？
马太效应
《圣经》马太福音章节中有这样一段故事:“一个人要往外国去，就叫了仆人来，把他的家业交给他们。按着各人的才干，给他们银子。一个给了五千，一个给了二千，一个给了一千。就往外国去了。那领五千的，随既拿去做买卖，另外赚了五千。那领二千的，也照样另赚了二千。 但那领一千的，去掘开地，把主人的银子埋藏了。过了许久，那些仆人的主人来了，和他们算账。那领五千银子的，又带着那另外的五千来，说，主阿，你交给我五千银子，请看，我又赚了五千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领二千的也来说，主阿，你交给我二千银子，请看，我又赚了二千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领一千的，也来说，主阿，我知道你是忍心的人，没有种的地方要收割，没有散的地方要聚敛。我就害怕，去把你的一千银子埋藏在地里。请看，你的原银在这里。主人回答说，你这又恶又懒的仆人，你既知道我没有种的地方要收割，没有散的地方要聚敛。就当把我的银子放给兑换银钱的人，到我来的时候，可以连本带利收回。夺过他这一千来，给那有一万的。凡有的，还要加给他，叫他有馀。没有的，连他所有的，也要夺过来。”
科学家罗卜特.默特把故事中的现象称为“马太效应”——即任何个人、群体或地区，一旦在某一方面获得成功和进步，就会产生一种积累优势，就会有更多的机会取得更大的成功和进步。
现实生活中“马太效应”无处不在。
狄德罗效应
18世纪的法国哲学家狄德罗在朋友送他一件华贵的睡袍后，穿在家里，总觉得家具颜色不对，地毯的针脚也粗得吓人，于是为了与睡袍配套，旧的东西先后更新，终于跟上了睡袍的档次。经济学家将其称为“狄德罗效应”，又称“配套效应”。
沉锚效应
鲁迅先生曾于1927年在《无声的中国》一文中写下了这样一段文字："中国人的性情总是喜欢调和、折中的，譬如你说，这屋子太暗，说在这里开一个天窗，大家一定是不允许的，但如果你主张拆掉屋顶，他们就会来调和，愿意开天窗了。”这种先提出很大的要求，接着提出较小较少的要求，在心理学上被称为"沉锚效应"。
如你想让你的朋友陪你出去玩，若说：“陪我出去玩好吗？”朋友不一定去。但如果说：“出去走走，随你的便，是去喝咖啡，唱卡拉OK，还是逛书店？”他很可能选定他最喜欢的，如“逛书店”而陪你出门。
再如早上喝豆浆时，如果服务员问：“先生要不要加鸡蛋”，“加”与“不加”即是“沉锚”。但若问“请问先生，加一个鸡蛋还是两个鸡蛋？”则“一个”或“两个”便是“沉锚”了。显然第二个问题更有利于促销，这就是沉锚效应在起作用。
一对未确定关系的情人，如果说“我们相处一段，看是否合适”，就不如说“相互关爱吧，我们能走到一起”具有沉锚效应。
研究沉锚效应是人际交往、谈判与经商不可缺少的课程。
从众效应
从众效应是一种追随别人的行为的常见的心理效应。这种效应有时是积极的，如别人献血你也去献；有时是消极的，如看到别人在公园摘花，自己也跟着去摘花。
有这么一个实验：某高校举办一次特殊的活动，请德国化学家展示他最近发明的某种挥发性液体。当主持人将满脸大胡子的“德国化学家”介绍给阶梯教师里的学生后，化学家用沙哑的嗓音向同学们说：“我最近研究出了一种强烈挥发性的液体，现在我要进行实验，看要用多长时间能从讲台挥发到全教室，凡闻到一点味道的，马上举手，我要计算时间。”说着，他打开了密封的瓶塞，让透明的液体挥发……不一会，后排的同学，前排的同学，中间的同学都先后举起了手。不到2分钟，全体同学举起了手。
此时，“化学家”一把把大胡子扯下，拿掉墨镜，原来他是本校的德语老师。他笑着说：“我这里装的是蒸馏水！”
这个实验，生动的说明了同学之间的从众效应——看到别人举手，也跟着举手，但他们并不是撒谎，而是受“化学家”的言语暗示和其他同学举手的行为暗示，似乎真的闻到了一种味道，于是举起了手。
有一个晴朗的夜晚，满天星斗，许多人站在车站站台上等待即将到来的火车。此时，一个人仰着脖子晃动着脑袋往天上寻看，在一旁的人好奇的以为他看到的人造卫星、流星或不明飞行物，也跟着向天空动张西望。其实，这位先生只是脖颈酸痛，他是在做放松活动，并非观察天空。那些跟着仰望星空的人实际上是被从众效应左右了。
积极的从众效应可以互相激励情绪，作出勇敢之举；消极的从众效应则互相壮胆干坏事——如看到别人乱穿马路，不少人也跟着走捷径。有人正是利用从众效应来行骗人之术，最生动的例子是玩所谓的“三张牌”，让人押宝。猜红桃A在哪里，可押50元、100元、200元。此时总有三五个人抢着参与，而不明真相的人不知道他们是“托儿”，被从众效应激化，也参加押宝。当然，结果肯定要输——因为最初参与的三五人同庄家全是一伙的。
聚众闹事行为多是由于个性化效应和从众效应激发起来的冲动行为。
过度理由效
应有这样一个有趣的故事：一位老人在一个小乡村里休养，但附近却住着一些十分顽皮的孩子，他们天天互相追逐打闹，喧哗的吵闹声使老人无法好好休息，在屡禁不止的情况下，老人想出了一个办法。
他把孩子们都叫到一起，告诉他们谁叫的声音越大，谁得到的报酬就越多，他每次都根据孩子们吵闹的情况给予不同的奖励。到孩子们已经习惯于获取奖励的时候，老人开始逐渐减少所给的奖励，最后无论孩子们怎么吵，老人一分钱也不给。
结果，孩子们认为受到的待遇越来越不公正，认为"不给钱了谁还给你叫"，再也不到老人所住的房子附近大声吵闹。
这就是由于社会心理学上所说的"过度理由效应"。每个人都力图使自己和别人的行为看起来合理，因而总是为行为寻找原因，一旦找到足够的原因，人们就很少再继续找下去，而且，在寻找原因时，总是先找那些显而易见的外在原因，因此，如果外部原因足以对行为做出解释时，人们一般就不再去寻找内部的原因了。
行为如果只用外在理由来解释，那么，一旦外在理由不再存在，这种行为也将趋于终止，因此，如果我们希望某种行为得以保持，就不要给它足够的外部理由。
公司老板如果希望自己的职员努力工作，就不要给予职员太多的物质奖励，而要让职员认为他自己勤奋、上进，喜欢这份工作，喜欢这家公司；希望孩子努力学习的家长，也不能用太多的金钱和奖品去奖励孩子的好成绩，而要让孩子觉得自己喜欢学习，学习是有趣的事。
查看全部
效应理论
效应，或效果，是指在有限环境下，一些因素和一些结果而构成的一种因果现象，多用于对一种自然现象和社会现象的描述，效应一词使用的泛围较广，并不一定指严格的科学定理、定律中的因果关系。
蝴蝶效应
1、蝴蝶效应是气象学家洛伦兹1963年提出来的。
其大意为：一只南美洲亚马孙河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可能在两周后引起美国德克萨斯引起一场龙卷风。其原因在于：蝴蝶翅膀的运动，导致其身边的空气系统发生变化，并引起微弱气流的产生，而微弱气流的产生又会引起它四周空气或其他系统产生相应的变化，由此引起连锁反映，最终导致其他系统的极大变化。
此效应说明，事物发展的结果，对初始条件具有极为敏感的依赖性，初始条件的极小偏差，将会引起结果的极大差异。
“蝴蝶效应”在社会学界用来说明：一个坏的微小的机制，如果不加以及时地引导、调节，会给社会带来非常大的危害，戏称为“龙卷风”或“风暴”；一个好的微小的机制，只要正确指引，经过一段时间的努力，将会产生轰动效应，或称为“革命”。
2、蝴蝶效应。什么是蝴蝶效应？1979年12月，洛伦兹在华盛顿的美国科学促进会的一次讲演中提出：一只蝴蝶在巴西扇动翅膀，有可能会在美国的德克萨斯引起一场龙卷风。他的演讲和结论给人们留下了极其深刻的印象。从此以后，所谓“蝴蝶效应”之说就不胫而走，名声远扬了。
“蝴蝶效应”之所以令人着迷、令人激动、发人深省，不但在于其大胆的想象力和迷人的美学色彩，更在于其深刻的科学内涵和内在的哲学魅力。
从科学的角度来看，“蝴蝶效应”反映了混沌运动的一个重要特征：系统的长期行为对初始条件的敏感依赖性。
经典动力学的传统观点认为：系统的长期行为对初始条件是不敏感的，即初始条件的微小变化对未来状态所造成的差别也是很微小的。可混沌理论向传统观点提出了挑战。混沌理论认为在混沌系统中，初始条件的十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。我们可以用在西方流传的一首民谣对此作形象的说明。这首民谣说：
丢失一个钉子，坏了一只蹄铁；
坏了一只蹄铁，折了一匹战马；
折了一匹战马，伤了一位骑士；
伤了一位骑士，输了一场战斗；
输了一场战斗，亡了一个帝国。
马蹄铁上一个钉子是否会丢失，本是初始条件的十分微小的变化，但其“长期”效应却是一个帝国存与亡的根本差别。这就是军事和政治领域中的所谓“蝴蝶效应”，听起来有点不可思议，但是确实能够造成这样的恶果。一些看似极微小的事情，却有可能造成集体内部的分崩离析，一定要防微杜渐，否则，悔之晚矣。
“蝴蝶效应”启示录，古往今来知多少？
破窗效应
政治学家威尔逊和犯罪学家凯琳提出了一个“破窗理论”。这个理论认为：如果有人打坏了一个建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户玻璃。久而久之，这些破窗户就给人造成一种无序的感觉。结果在这种公众麻木不仁的氛围中，犯罪就会滋生、繁荣。“破窗理论”不仅仅在社会管理中有所应用，而且也被用在了现代企业管理中。
近因效应
最近、最后的印象，往往是最强烈的，可以冲淡在此之前产生的各种因素，这就是近因效应。有这样一个例子：面试过程中，主考官告诉考生可以走了，可当考生要离开考场时，主考官又叫住他，对他说，你已回答了我们所提出的问题，评委觉得不怎么样，你对此怎么看？其实，考官做出这么一种设置，是对毕业生的最后一考，想借此考察一下应聘者的心理素质和临场应变能力。如果这一道题回答得精彩，大可弥补此前面试中的缺憾；如果回答得不好，可能会由于这最后的关键性试题而使应聘者前功尽弃。
青蛙效应
从前有一则水煮青蛙的寓言：如果把一只青蛙放在沸水中，它便会纵身而出；如果把一只青蛙放进温水中，它会感到舒舒服服的。然后你再慢慢升温，即使升至摄氏80°，青蛙也仍然会若无其事地待在那水里。随着温度的继续上升至90°- 100°时，青蛙就会变得越来越虚弱，在此情况下，青蛙已经失去自我脱险的能力了，直至把它煮熟为止。在第二种状况下，青蛙为什么不能自我摆脱险境呢？这是因为青蛙内部感应自下而上威胁的器官，只能感应出激烈的环境变化，而对缓慢、渐进的环境变化却不能及时做出感应。这就是一种“青蛙效应”。
“青蛙效应”告诉我们一个道理：“生于忧患，死于安逸。”
美人效应
罗马一家自助餐厅的老板想出一个赚小费的妙计。他请来一位非常漂亮的姑娘，坐在柜台边收钱，以便使男客们神魂颠倒，慷慨解囊。谁知那位姑娘上班后没过几天，就对老板说：“我想，我不如以前漂亮了。”老板忙问：“这是怎么回事呢？”“现在，所有的男客都在柜台边反复地数找给他们的零钱。”
鲶鱼效应
西班牙人爱吃沙丁鱼，但沙丁鱼很娇贵，极不适应离开大海后的环境。用不了多久就会死掉。为延长它的活命期，当地渔民想出了一个办法，将几条沙丁鱼的天敌鲶鱼放在运输容器里。为了躲避天敌的吞食，沙丁鱼在有限的空间里快速游动，反而保持了旺盛的生命力。这就是经济学上讲的鲶鱼效应。为了更好地生存发展下去，惧者必然会比其他人更用功，而越用功，跑的就越快。
晕轮效应
晕轮原指月亮被光环笼罩时产生的模糊不清的现象。晕轮效应是一种普通存在的心理现象，即对一个人进行评价时，往往会因对他的某一品质特征的强烈、清晰的感知，而掩盖了其他方面的品质。
毕业生在求职应聘中，如果能够巧妙地运用这种晕轮效应，把自身的优势充分地展现出来，一定会给招聘考官留下深刻的印象，赢得对方的赏识，取得面试的成功。比如，当招聘者问及你的英语水平时，你便用英语熟练地与其交谈，必然会引起招聘者的极大兴趣，很可能当场便与你拍板“成交”。但在运用这一效应时一定要注意，不能刻意制造“光环”效果，那种虚妄做出的行为，往往适得其反。
木桶效应
在管理学上有一个著名的“木桶理论”，是指用一个木桶来装水，如果组成木桶的木板参差不齐，那么它能盛下的水的容量不是由这个木桶中最长的木板来决定的，而是由这个木桶中最短的木板决定的，所以它又被称为“短板效应”。由此可见，在事物的发展过程中，“短板”的长度决定其整体发展程度。正如，一件产品质量的高低，取决于那个品质最次的零部件，而不是取决于那个品质最好的零部件；一个组织的整体素质高低，不是取决于这个组织的最优秀分子的素质，而是取决于这个组织中最一般分子的素质一样。……此种现象在管理学中通常被称为“木桶效应”。
“木桶效应”对你有何启示？
马太效应
《圣经》马太福音章节中有这样一段故事:“一个人要往外国去，就叫了仆人来，把他的家业交给他们。按着各人的才干，给他们银子。一个给了五千，一个给了二千，一个给了一千。就往外国去了。那领五千的，随既拿去做买卖，另外赚了五千。那领二千的，也照样另赚了二千。 但那领一千的，去掘开地，把主人的银子埋藏了。过了许久，那些仆人的主人来了，和他们算账。那领五千银子的，又带着那另外的五千来，说，主阿，你交给我五千银子，请看，我又赚了五千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领二千的也来说，主阿，你交给我二千银子，请看，我又赚了二千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领一千的，也来说，主阿，我知道你是忍心的人，没有种的地方要收割，没有散的地方要聚敛。我就害怕，去把你的一千银子埋藏在地里。请看，你的原银在这里。主人回答说，你这又恶又懒的仆人，你既知道我没有种的地方要收割，没有散的地方要聚敛。就当把我的银子放给兑换银钱的人，到我来的时候，可以连本带利收回。夺过他这一千来，给那有一万的。凡有的，还要加给他，叫他有馀。没有的，连他所有的，也要夺过来。”
科学家罗卜特.默特把故事中的现象称为“马太效应”——即任何个人、群体或地区，一旦在某一方面获得成功和进步，就会产生一种积累优势，就会有更多的机会取得更大的成功和进步。
现实生活中“马太效应”无处不在。
狄德罗效应
18世纪的法国哲学家狄德罗在朋友送他一件华贵的睡袍后，穿在家里，总觉得家具颜色不对，地毯的针脚也粗得吓人，于是为了与睡袍配套，旧的东西先后更新，终于跟上了睡袍的档次。经济学家将其称为“狄德罗效应”，又称“配套效应”。
沉锚效应
鲁迅先生曾于1927年在《无声的中国》一文中写下了这样一段文字："中国人的性情总是喜欢调和、折中的，譬如你说，这屋子太暗，说在这里开一个天窗，大家一定是不允许的，但如果你主张拆掉屋顶，他们就会来调和，愿意开天窗了。”这种先提出很大的要求，接着提出较小较少的要求，在心理学上被称为"沉锚效应"。
如你想让你的朋友陪你出去玩，若说：“陪我出去玩好吗？”朋友不一定去。但如果说：“出去走走，随你的便，是去喝咖啡，唱卡拉OK，还是逛书店？”他很可能选定他最喜欢的，如“逛书店”而陪你出门。
再如早上喝豆浆时，如果服务员问：“先生要不要加鸡蛋”，“加”与“不加”即是“沉锚”。但若问“请问先生，加一个鸡蛋还是两个鸡蛋？”则“一个”或“两个”便是“沉锚”了。显然第二个问题更有利于促销，这就是沉锚效应在起作用。
一对未确定关系的情人，如果说“我们相处一段，看是否合适”，就不如说“相互关爱吧，我们能走到一起”具有沉锚效应。
研究沉锚效应是人际交往、谈判与经商不可缺少的课程。
从众效应
从众效应是一种追随别人的行为的常见的心理效应。这种效应有时是积极的，如别人献血你也去献；有时是消极的，如看到别人在公园摘花，自己也跟着去摘花。
有这么一个实验：某高校举办一次特殊的活动，请德国化学家展示他最近发明的某种挥发性液体。当主持人将满脸大胡子的“德国化学家”介绍给阶梯教师里的学生后，化学家用沙哑的嗓音向同学们说：“我最近研究出了一种强烈挥发性的液体，现在我要进行实验，看要用多长时间能从讲台挥发到全教室，凡闻到一点味道的，马上举手，我要计算时间。”说着，他打开了密封的瓶塞，让透明的液体挥发……不一会，后排的同学，前排的同学，中间的同学都先后举起了手。不到2分钟，全体同学举起了手。
此时，“化学家”一把把大胡子扯下，拿掉墨镜，原来他是本校的德语老师。他笑着说：“我这里装的是蒸馏水！”
这个实验，生动的说明了同学之间的从众效应——看到别人举手，也跟着举手，但他们并不是撒谎，而是受“化学家”的言语暗示和其他同学举手的行为暗示，似乎真的闻到了一种味道，于是举起了手。
有一个晴朗的夜晚，满天星斗，许多人站在车站站台上等待即将到来的火车。此时，一个人仰着脖子晃动着脑袋往天上寻看，在一旁的人好奇的以为他看到的人造卫星、流星或不明飞行物，也跟着向天空动张西望。其实，这位先生只是脖颈酸痛，他是在做放松活动，并非观察天空。那些跟着仰望星空的人实际上是被从众效应左右了。
积极的从众效应可以互相激励情绪，作出勇敢之举；消极的从众效应则互相壮胆干坏事——如看到别人乱穿马路，不少人也跟着走捷径。有人正是利用从众效应来行骗人之术，最生动的例子是玩所谓的“三张牌”，让人押宝。猜红桃A在哪里，可押50元、100元、200元。此时总有三五个人抢着参与，而不明真相的人不知道他们是“托儿”，被从众效应激化，也参加押宝。当然，结果肯定要输——因为最初参与的三五人同庄家全是一伙的。
聚众闹事行为多是由于个性化效应和从众效应激发起来的冲动行为。
过度理由效
应有这样一个有趣的故事：一位老人在一个小乡村里休养，但附近却住着一些十分顽皮的孩子，他们天天互相追逐打闹，喧哗的吵闹声使老人无法好好休息，在屡禁不止的情况下，老人想出了一个办法。
他把孩子们都叫到一起，告诉他们谁叫的声音越大，谁得到的报酬就越多，他每次都根据孩子们吵闹的情况给予不同的奖励。到孩子们已经习惯于获取奖励的时候，老人开始逐渐减少所给的奖励，最后无论孩子们怎么吵，老人一分钱也不给。
结果，孩子们认为受到的待遇越来越不公正，认为"不给钱了谁还给你叫"，再也不到老人所住的房子附近大声吵闹。
这就是由于社会心理学上所说的"过度理由效应"。每个人都力图使自己和别人的行为看起来合理，因而总是为行为寻找原因，一旦找到足够的原因，人们就很少再继续找下去，而且，在寻找原因时，总是先找那些显而易见的外在原因，因此，如果外部原因足以对行为做出解释时，人们一般就不再去寻找内部的原因了。
行为如果只用外在理由来解释，那么，一旦外在理由不再存在，这种行为也将趋于终止，因此，如果我们希望某种行为得以保持，就不要给它足够的外部理由。
公司老板如果希望自己的职员努力工作，就不要给予职员太多的物质奖励，而要让职员认为他自己勤奋、上进，喜欢这份工作，喜欢这家公司；希望孩子努力学习的家长，也不能用太多的金钱和奖品去奖励孩子的好成绩，而要让孩子觉得自己喜欢学习，学习是有趣的事。
效应，或效果，是指在有限环境下，一些因素和一些结果而构成的一种因果现象，多用于对一种自然现象和社会现象的描述，效应一词使用的泛围较广，并不一定指严格的科学定理、定律中的因果关系。
蝴蝶效应
1、蝴蝶效应是气象学家洛伦兹1963年提出来的。
其大意为：一只南美洲亚马孙河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可能在两周后引起美国德克萨斯引起一场龙卷风。其原因在于：蝴蝶翅膀的运动，导致其身边的空气系统发生变化，并引起微弱气流的产生，而微弱气流的产生又会引起它四周空气或其他系统产生相应的变化，由此引起连锁反映，最终导致其他系统的极大变化。
此效应说明，事物发展的结果，对初始条件具有极为敏感的依赖性，初始条件的极小偏差，将会引起结果的极大差异。
“蝴蝶效应”在社会学界用来说明：一个坏的微小的机制，如果不加以及时地引导、调节，会给社会带来非常大的危害，戏称为“龙卷风”或“风暴”；一个好的微小的机制，只要正确指引，经过一段时间的努力，将会产生轰动效应，或称为“革命”。
2、蝴蝶效应。什么是蝴蝶效应？1979年12月，洛伦兹在华盛顿的美国科学促进会的一次讲演中提出：一只蝴蝶在巴西扇动翅膀，有可能会在美国的德克萨斯引起一场龙卷风。他的演讲和结论给人们留下了极其深刻的印象。从此以后，所谓“蝴蝶效应”之说就不胫而走，名声远扬了。
“蝴蝶效应”之所以令人着迷、令人激动、发人深省，不但在于其大胆的想象力和迷人的美学色彩，更在于其深刻的科学内涵和内在的哲学魅力。
从科学的角度来看，“蝴蝶效应”反映了混沌运动的一个重要特征：系统的长期行为对初始条件的敏感依赖性。
经典动力学的传统观点认为：系统的长期行为对初始条件是不敏感的，即初始条件的微小变化对未来状态所造成的差别也是很微小的。可混沌理论向传统观点提出了挑战。混沌理论认为在混沌系统中，初始条件的十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。我们可以用在西方流传的一首民谣对此作形象的说明。这首民谣说：
丢失一个钉子，坏了一只蹄铁；
坏了一只蹄铁，折了一匹战马；
折了一匹战马，伤了一位骑士；
伤了一位骑士，输了一场战斗；
输了一场战斗，亡了一个帝国。
马蹄铁上一个钉子是否会丢失，本是初始条件的十分微小的变化，但其“长期”效应却是一个帝国存与亡的根本差别。这就是军事和政治领域中的所谓“蝴蝶效应”，听起来有点不可思议，但是确实能够造成这样的恶果。一些看似极微小的事情，却有可能造成集体内部的分崩离析，一定要防微杜渐，否则，悔之晚矣。
“蝴蝶效应”启示录，古往今来知多少？
破窗效应
政治学家威尔逊和犯罪学家凯琳提出了一个“破窗理论”。这个理论认为：如果有人打坏了一个建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户玻璃。久而久之，这些破窗户就给人造成一种无序的感觉。结果在这种公众麻木不仁的氛围中，犯罪就会滋生、繁荣。“破窗理论”不仅仅在社会管理中有所应用，而且也被用在了现代企业管理中。
近因效应
最近、最后的印象，往往是最强烈的，可以冲淡在此之前产生的各种因素，这就是近因效应。有这样一个例子：面试过程中，主考官告诉考生可以走了，可当考生要离开考场时，主考官又叫住他，对他说，你已回答了我们所提出的问题，评委觉得不怎么样，你对此怎么看？其实，考官做出这么一种设置，是对毕业生的最后一考，想借此考察一下应聘者的心理素质和临场应变能力。如果这一道题回答得精彩，大可弥补此前面试中的缺憾；如果回答得不好，可能会由于这最后的关键性试题而使应聘者前功尽弃。
青蛙效应
从前有一则水煮青蛙的寓言：如果把一只青蛙放在沸水中，它便会纵身而出；如果把一只青蛙放进温水中，它会感到舒舒服服的。然后你再慢慢升温，即使升至摄氏80°，青蛙也仍然会若无其事地待在那水里。随着温度的继续上升至90°- 100°时，青蛙就会变得越来越虚弱，在此情况下，青蛙已经失去自我脱险的能力了，直至把它煮熟为止。在第二种状况下，青蛙为什么不能自我摆脱险境呢？这是因为青蛙内部感应自下而上威胁的器官，只能感应出激烈的环境变化，而对缓慢、渐进的环境变化却不能及时做出感应。这就是一种“青蛙效应”。
“青蛙效应”告诉我们一个道理：“生于忧患，死于安逸。”
美人效应
罗马一家自助餐厅的老板想出一个赚小费的妙计。他请来一位非常漂亮的姑娘，坐在柜台边收钱，以便使男客们神魂颠倒，慷慨解囊。谁知那位姑娘上班后没过几天，就对老板说：“我想，我不如以前漂亮了。”老板忙问：“这是怎么回事呢？”“现在，所有的男客都在柜台边反复地数找给他们的零钱。”
鲶鱼效应
西班牙人爱吃沙丁鱼，但沙丁鱼很娇贵，极不适应离开大海后的环境。用不了多久就会死掉。为延长它的活命期，当地渔民想出了一个办法，将几条沙丁鱼的天敌鲶鱼放在运输容器里。为了躲避天敌的吞食，沙丁鱼在有限的空间里快速游动，反而保持了旺盛的生命力。这就是经济学上讲的鲶鱼效应。为了更好地生存发展下去，惧者必然会比其他人更用功，而越用功，跑的就越快。
晕轮效应
晕轮原指月亮被光环笼罩时产生的模糊不清的现象。晕轮效应是一种普通存在的心理现象，即对一个人进行评价时，往往会因对他的某一品质特征的强烈、清晰的感知，而掩盖了其他方面的品质。
毕业生在求职应聘中，如果能够巧妙地运用这种晕轮效应，把自身的优势充分地展现出来，一定会给招聘考官留下深刻的印象，赢得对方的赏识，取得面试的成功。比如，当招聘者问及你的英语水平时，你便用英语熟练地与其交谈，必然会引起招聘者的极大兴趣，很可能当场便与你拍板“成交”。但在运用这一效应时一定要注意，不能刻意制造“光环”效果，那种虚妄做出的行为，往往适得其反。
木桶效应
在管理学上有一个著名的“木桶理论”，是指用一个木桶来装水，如果组成木桶的木板参差不齐，那么它能盛下的水的容量不是由这个木桶中最长的木板来决定的，而是由这个木桶中最短的木板决定的，所以它又被称为“短板效应”。由此可见，在事物的发展过程中，“短板”的长度决定其整体发展程度。正如，一件产品质量的高低，取决于那个品质最次的零部件，而不是取决于那个品质最好的零部件；一个组织的整体素质高低，不是取决于这个组织的最优秀分子的素质，而是取决于这个组织中最一般分子的素质一样。……此种现象在管理学中通常被称为“木桶效应”。
“木桶效应”对你有何启示？
马太效应
《圣经》马太福音章节中有这样一段故事:“一个人要往外国去，就叫了仆人来，把他的家业交给他们。按着各人的才干，给他们银子。一个给了五千，一个给了二千，一个给了一千。就往外国去了。那领五千的，随既拿去做买卖，另外赚了五千。那领二千的，也照样另赚了二千。 但那领一千的，去掘开地，把主人的银子埋藏了。过了许久，那些仆人的主人来了，和他们算账。那领五千银子的，又带着那另外的五千来，说，主阿，你交给我五千银子，请看，我又赚了五千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领二千的也来说，主阿，你交给我二千银子，请看，我又赚了二千。主人说，好，你这又良善又忠心的仆人。你在不多的事上有忠心，我把许多事派你管理。可以进来享受你主人的快乐。那领一千的，也来说，主阿，我知道你是忍心的人，没有种的地方要收割，没有散的地方要聚敛。我就害怕，去把你的一千银子埋藏在地里。请看，你的原银在这里。主人回答说，你这又恶又懒的仆人，你既知道我没有种的地方要收割，没有散的地方要聚敛。就当把我的银子放给兑换银钱的人，到我来的时候，可以连本带利收回。夺过他这一千来，给那有一万的。凡有的，还要加给他，叫他有馀。没有的，连他所有的，也要夺过来。”
科学家罗卜特.默特把故事中的现象称为“马太效应”——即任何个人、群体或地区，一旦在某一方面获得成功和进步，就会产生一种积累优势，就会有更多的机会取得更大的成功和进步。
现实生活中“马太效应”无处不在。
狄德罗效应
18世纪的法国哲学家狄德罗在朋友送他一件华贵的睡袍后，穿在家里，总觉得家具颜色不对，地毯的针脚也粗得吓人，于是为了与睡袍配套，旧的东西先后更新，终于跟上了睡袍的档次。经济学家将其称为“狄德罗效应”，又称“配套效应”。
沉锚效应
鲁迅先生曾于1927年在《无声的中国》一文中写下了这样一段文字："中国人的性情总是喜欢调和、折中的，譬如你说，这屋子太暗，说在这里开一个天窗，大家一定是不允许的，但如果你主张拆掉屋顶，他们就会来调和，愿意开天窗了。”这种先提出很大的要求，接着提出较小较少的要求，在心理学上被称为"沉锚效应"。
如你想让你的朋友陪你出去玩，若说：“陪我出去玩好吗？”朋友不一定去。但如果说：“出去走走，随你的便，是去喝咖啡，唱卡拉OK，还是逛书店？”他很可能选定他最喜欢的，如“逛书店”而陪你出门。
再如早上喝豆浆时，如果服务员问：“先生要不要加鸡蛋”，“加”与“不加”即是“沉锚”。但若问“请问先生，加一个鸡蛋还是两个鸡蛋？”则“一个”或“两个”便是“沉锚”了。显然第二个问题更有利于促销，这就是沉锚效应在起作用。
一对未确定关系的情人，如果说“我们相处一段，看是否合适”，就不如说“相互关爱吧，我们能走到一起”具有沉锚效应。
研究沉锚效应是人际交往、谈判与经商不可缺少的课程。
从众效应
从众效应是一种追随别人的行为的常见的心理效应。这种效应有时是积极的，如别人献血你也去献；有时是消极的，如看到别人在公园摘花，自己也跟着去摘花。
有这么一个实验：某高校举办一次特殊的活动，请德国化学家展示他最近发明的某种挥发性液体。当主持人将满脸大胡子的“德国化学家”介绍给阶梯教师里的学生后，化学家用沙哑的嗓音向同学们说：“我最近研究出了一种强烈挥发性的液体，现在我要进行实验，看要用多长时间能从讲台挥发到全教室，凡闻到一点味道的，马上举手，我要计算时间。”说着，他打开了密封的瓶塞，让透明的液体挥发……不一会，后排的同学，前排的同学，中间的同学都先后举起了手。不到2分钟，全体同学举起了手。
此时，“化学家”一把把大胡子扯下，拿掉墨镜，原来他是本校的德语老师。他笑着说：“我这里装的是蒸馏水！”
这个实验，生动的说明了同学之间的从众效应——看到别人举手，也跟着举手，但他们并不是撒谎，而是受“化学家”的言语暗示和其他同学举手的行为暗示，似乎真的闻到了一种味道，于是举起了手。
有一个晴朗的夜晚，满天星斗，许多人站在车站站台上等待即将到来的火车。此时，一个人仰着脖子晃动着脑袋往天上寻看，在一旁的人好奇的以为他看到的人造卫星、流星或不明飞行物，也跟着向天空动张西望。其实，这位先生只是脖颈酸痛，他是在做放松活动，并非观察天空。那些跟着仰望星空的人实际上是被从众效应左右了。
积极的从众效应可以互相激励情绪，作出勇敢之举；消极的从众效应则互相壮胆干坏事——如看到别人乱穿马路，不少人也跟着走捷径。有人正是利用从众效应来行骗人之术，最生动的例子是玩所谓的“三张牌”，让人押宝。猜红桃A在哪里，可押50元、100元、200元。此时总有三五个人抢着参与，而不明真相的人不知道他们是“托儿”，被从众效应激化，也参加押宝。当然，结果肯定要输——因为最初参与的三五人同庄家全是一伙的。
聚众闹事行为多是由于个性化效应和从众效应激发起来的冲动行为。
过度理由效
应有这样一个有趣的故事：一位老人在一个小乡村里休养，但附近却住着一些十分顽皮的孩子，他们天天互相追逐打闹，喧哗的吵闹声使老人无法好好休息，在屡禁不止的情况下，老人想出了一个办法。
他把孩子们都叫到一起，告诉他们谁叫的声音越大，谁得到的报酬就越多，他每次都根据孩子们吵闹的情况给予不同的奖励。到孩子们已经习惯于获取奖励的时候，老人开始逐渐减少所给的奖励，最后无论孩子们怎么吵，老人一分钱也不给。
结果，孩子们认为受到的待遇越来越不公正，认为"不给钱了谁还给你叫"，再也不到老人所住的房子附近大声吵闹。
这就是由于社会心理学上所说的"过度理由效应"。每个人都力图使自己和别人的行为看起来合理，因而总是为行为寻找原因，一旦找到足够的原因，人们就很少再继续找下去，而且，在寻找原因时，总是先找那些显而易见的外在原因，因此，如果外部原因足以对行为做出解释时，人们一般就不再去寻找内部的原因了。
行为如果只用外在理由来解释，那么，一旦外在理由不再存在，这种行为也将趋于终止，因此，如果我们希望某种行为得以保持，就不要给它足够的外部理由。
公司老板如果希望自己的职员努力工作，就不要给予职员太多的物质奖励，而要让职员认为他自己勤奋、上进，喜欢这份工作，喜欢这家公司；希望孩子努力学习的家长，也不能用太多的金钱和奖品去奖励孩子的好成绩，而要让孩子觉得自己喜欢学习，学习是有趣的事。
分布式系统理论基础 - 一致性、2PC和3PC
zkbhj 发表了文章 • 0 个评论 • 1450 次浏览 • 2017-12-23 21:10
狭义的分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。广义的分布式系统是一个相对的概念，正如Leslie Lamport所说：
What is a distributed systeme. Distribution is in the eye of the beholder.
To the user sitting at the keyboard, his IBM personal computer is a nondistributed system.
To a flea crawling around on the circuit board, or to the engineer who designed it, it's very much a distributed system.
一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。
一致性(consensus)
何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将。
假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：
全认同(agreement): 所有N个节点都认同一个结果值合法(validity): 该结果必须由N个节点中的节点提出可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去
有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？
但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：
消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)节点宕机(fail-stop): 节点持续宕机，不会恢复节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分拜占庭将军问题(byzantine failure)[2]: 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息
我: 老王，今晚7点老地方，搓够48圈不见不散！
……
（第二天凌晨3点） 隔壁老王: 没问题！ // 消息延迟
我: ……
----------------------------------------------
我: 小张，今晚7点老地方，搓够48圈不见不散！
小张: No ……
（两小时后……）
小张: No problem！ // 宕机节点恢复
我: ……
-----------------------------------------------
我: 老李头，今晚7点老地方，搓够48圈不见不散！
老李: 必须的，guang'chang'wu走起！ // 拜占庭将军
（这是要打麻将呢？还是要广场舞？还是一边打麻将一边广场舞……）还能不能一起愉快地玩耍...
我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：
异步环境(asynchronous)下，节点宕机(fail-stop)异步环境(asynchronous)下，节点宕机恢复(fail-recover)、网络分化(network partition)
2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓（这句我喜欢）。
一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility)已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。
FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。
工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。
2PC
2PC(tow phase commit)两阶段提交，顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：
2PC, phase one
在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。
2PC, phase two
在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。
在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？
coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。
从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。
3PC
3PC(three phase commit)即三阶段提交，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？
在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：
能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态
相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：
图片截取自wikipedia
coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。
participant如果在不同阶段宕机，我们来看看3PC如何应对：
阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务
因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。
小结
以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。
原文阅读：https://www.cnblogs.com/bangerlee/p/5268485.html 查看全部
What is a distributed systeme. Distribution is in the eye of the beholder.
To the user sitting at the keyboard, his IBM personal computer is a nondistributed system.
To a flea crawling around on the circuit board, or to the engineer who designed it, it's very much a distributed system.
一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。
一致性(consensus)
何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将。
假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：
全认同(agreement): 所有N个节点都认同一个结果值合法(validity): 该结果必须由N个节点中的节点提出可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去
有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？
但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：
消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)节点宕机(fail-stop): 节点持续宕机，不会恢复节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分拜占庭将军问题(byzantine failure)[2]: 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息
我: 老王，今晚7点老地方，搓够48圈不见不散！
……
（第二天凌晨3点） 隔壁老王: 没问题！ // 消息延迟
我: ……
----------------------------------------------
我: 小张，今晚7点老地方，搓够48圈不见不散！
小张: No ……
（两小时后……）
小张: No problem！ // 宕机节点恢复
我: ……
-----------------------------------------------
我: 老李头，今晚7点老地方，搓够48圈不见不散！
老李: 必须的，guang'chang'wu走起！ // 拜占庭将军
（这是要打麻将呢？还是要广场舞？还是一边打麻将一边广场舞……）还能不能一起愉快地玩耍...
我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：
异步环境(asynchronous)下，节点宕机(fail-stop)异步环境(asynchronous)下，节点宕机恢复(fail-recover)、网络分化(network partition)
2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓（这句我喜欢）。
一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility)已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。
FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。
工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。
2PC
2PC(tow phase commit)两阶段提交，顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：
2PC, phase one
在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。
2PC, phase two
在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。
在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？
coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。
从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。
3PC
3PC(three phase commit)即三阶段提交，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？
在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：
能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态
相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：
图片截取自wikipedia
coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。
participant如果在不同阶段宕机，我们来看看3PC如何应对：
阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务
因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。
小结
以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。
原文阅读：https://www.cnblogs.com/bangerlee/p/5268485.html 查看全部
狭义的分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。广义的分布式系统是一个相对的概念，正如Leslie Lamport所说：
一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。
一致性(consensus)
何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将。
假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：
有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？
但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：
我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：
2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓（这句我喜欢）。
一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility)已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。
FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。
工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。
2PC
2PC(tow phase commit)两阶段提交，顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：
2PC, phase one
在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。
2PC, phase two
在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。
在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？
coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。
从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。
3PC
3PC(three phase commit)即三阶段提交，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？
在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：
能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态
相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：
图片截取自wikipedia
coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。
participant如果在不同阶段宕机，我们来看看3PC如何应对：
阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务
因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。
小结
以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。
原文阅读：https://www.cnblogs.com/bangerlee/p/5268485.html
What is a distributed systeme. Distribution is in the eye of the beholder.
To the user sitting at the keyboard, his IBM personal computer is a nondistributed system.
To a flea crawling around on the circuit board, or to the engineer who designed it, it's very much a distributed system.
一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。
一致性(consensus)
何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见，比如牌友怎么商定几点在哪打几圈麻将。
假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：
- 全认同(agreement): 所有N个节点都认同一个结果
- 值合法(validity): 该结果必须由N个节点中的节点提出
- 可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去
有人可能会说，决定什么时候在哪搓搓麻将，4个人商量一下就ok，这不很简单吗？
但就这样看似简单的事情，分布式系统实现起来并不轻松，因为它面临着这些问题：
- 消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)
- 节点宕机(fail-stop): 节点持续宕机，不会恢复
- 节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见
- 网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分
- 拜占庭将军问题(byzantine failure)[2]: 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息
我: 老王，今晚7点老地方，搓够48圈不见不散！还能不能一起愉快地玩耍...
……
（第二天凌晨3点） 隔壁老王: 没问题！ // 消息延迟
我: ……
----------------------------------------------
我: 小张，今晚7点老地方，搓够48圈不见不散！
小张: No ……
（两小时后……）
小张: No problem！ // 宕机节点恢复
我: ……
-----------------------------------------------
我: 老李头，今晚7点老地方，搓够48圈不见不散！
老李: 必须的，guang'chang'wu走起！ // 拜占庭将军
（这是要打麻将呢？还是要广场舞？还是一边打麻将一边广场舞……）
我们把以上所列的问题称为系统模型(system model)，讨论分布式系统理论和工程实践的时候，必先划定模型。例如有以下两种模型：
- 异步环境(asynchronous)下，节点宕机(fail-stop)
- 异步环境(asynchronous)下，节点宕机恢复(fail-recover)、网络分化(network partition)
2比1多了节点恢复、网络分化的考量，因而对这两种模型的理论研究和工程解决方案必定是不同的，在还没有明晰所要解决的问题前谈解决方案都是一本正经地耍流氓（这句我喜欢）。
一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统24*7无间断对外服务。FLP定理(FLP impossibility)已经证明在一个收窄的模型中(异步环境并只存在节点宕机)，不能同时满足 safety 和 liveness。
FLP定理是分布式系统理论中的基础理论，正如物理学中的能量守恒定律彻底否定了永动机的存在，FLP定理否定了同时满足safety 和 liveness 的一致性协议的存在。
工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。
2PC
2PC(tow phase commit)两阶段提交，顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：
2PC, phase one
在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。
2PC, phase two
在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。
在异步环境(asynchronous)并且没有节点宕机(fail-stop)的模型下，2PC可以满足全认同、值合法、可结束，是解决一致性问题的一种协议。但如果再加上节点宕机(fail-recover)的考虑，2PC是否还能解决一致性问题呢？
coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来，我们把新增的这一角色叫协调者备份(coordinator watchdog)。coordinator宕机一定时间后，watchdog接替原coordinator工作，通过问询(query) 各participant的状态，决定阶段2是提交还是中止。这也要求 coordinator/participant 记录(logging)历史状态，以备coordinator宕机后watchdog对participant查询、coordinator宕机恢复后重新找回状态。
从coordinator接收到一次事务请求、发起提议到事务完成，经过2PC协议后增加了2次RTT(propose+commit)，带来的时延(latency)增加相对较少。
3PC
3PC(three phase commit)即三阶段提交，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？
在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到participant宕机恢复。这引出两个疑问：
能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态
相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：
图片截取自wikipedia
coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。
participant如果在不同阶段宕机，我们来看看3PC如何应对：
阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务
因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。
小结
以上介绍了分布式系统理论中的部分基础知识，阐述了一致性(consensus)的定义和实现一致性所要面临的问题，最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。
原文阅读：https://www.cnblogs.com/bangerlee/p/5268485.html
滑动窗口机制
zkbhj 发表了文章 • 0 个评论 • 1446 次浏览 • 2017-12-21 14:16
窗口机制
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：
分析：
①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；
②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；
③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；
④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；
⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；
⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；
⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；
⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收窗口>1；选择重传协议：发送窗口>1,接收窗口>1。
比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
查看全部
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：
分析：
①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；
②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；
③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；
④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；
⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；
⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；
⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；
⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收窗口>1；选择重传协议：发送窗口>1,接收窗口>1。
比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
查看全部
窗口机制
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：
分析：
①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；
②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；
③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；
④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；
⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；
⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；
⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；
⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收窗口>1；选择重传协议：发送窗口>1,接收窗口>1。
比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：
分析：
①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；
②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；
③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；
④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；
⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；
⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；
⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；
⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收窗口>1；选择重传协议：发送窗口>1,接收窗口>1。
比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
如何理解AB测试
zkbhj 发表了文章 • 0 个评论 • 1387 次浏览 • 2017-12-20 14:12
AB测试的概念定义如下：
AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
ABtest一个总的目的和意图是，判断哪种UI或rerank策略更优，通过事实的依据（ CTR或下单率）判断哪种策略更符合用户的习惯和需求。
一、需求驱使
我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。
下面看一个例子：
在展示“格林秀上午酒店”这个poi时有客户端两种UI：
方案A：如左图，评分展示星状图片，消费人数再右边；
方案B：如右图，只展示评分分数，后边添加消费人数；
我们很难知道那种方案比较好，那我们可以做个实验，把a和B方案同时放到线上的生产环境，让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用报表如下图，通过大自然的优胜劣汰法则，我们可以通过CTR或下单率等指标看哪个方案更符合设计目标。
二、系统模型
abtest实验可以分成两种，客户端client实验和服务端server实验，客户端实验一般来说只是UI上的实验，比如上面的例子，纯粹是展示端的策略；而服务端的实验是返回给client数据的内容做实验，比如推荐的策略，订单列表rerank策略等。下面通过client和服务端的实验分别做介绍。
（1）客户端实验：
方案1:
ABTest业务流程描述：
（1）客户端在需要获取ABTest策略的地方，通过RPC接口获取uuid在ABTest1这个实验下的规则：{
"data": [
{
"name": "test1",//实验key
"strategy": "strategy1", //策略key，客户端根据策略key选择策略方案
"flow": "flow1", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
}
其中testkey参数可以是多个ABTest实验的key：abtest1,abtest2。
（2）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1__strategy1__flow1，Nginx将utm_compaign打印到access日志。
（3）客户端在另一个需要获取ABTest策略的地方，通过http接口/get/abtest/{testkey}/{uuid} 获取uuid在ABTest2这个实验下的规则：{
"data": [
{
"name": "abtest2",//实验key，
"strategy": "strategy2", //策略key，客户端根据策略key选择策略方案
"flow": "flow2", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
}
（4）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1_strategy1__flow1___abtest2__strategy2__flow2，实验&策略&流量组采用两个下划线分隔，多个实验间采用三个下划线分隔。
（5）Nginx将URL中的utm_compaign打印到access日志，flume收集Nginx access 日志，同步到Hadoop，最后导入Hive。
（6）PM在报表系统，通过规则维度查询点击、转化报表。
这样导致的问题是url中utm_compaign的F字段过长，当实验到达一定数量的时候会出现，url过长，抓包会发现。实际上，客户端只关心我在某个界面中这次请求（uuid＋ci＋platform）命中的实验及策略，连utm_campaign都懒得拼接。
如URL中有utm_campaign=Fab_homepagewebview0717__b__d___ab_b_food_57_purepoilist_extinfo__a__a___ab_b_selectlist_paidui__a__leftflow___ab_i550poi_ktv__d__leftflow___ab_i_5_9_travelpoidetail__b__a___ab_i550poi_xxyl__d__d___ab_mingdiangexinghua0707__j__j___ab_waimaiwending__b__b___ab_b_travelsearchhot__a__a___ab_ifoodadvert__b__b___ab_pindaoqugexinghua0708__e__e___ab_itriphotpoi__b__leftflow___ab_i_6_0_webview__a__a___ab_b_travelpoilistrank__b__b2___ab_i_group_5_7_search_chunpoi__b__b1___ab_i_group_5_8_spdy__b__b___ab_ihotelqianzhi__b__b___i_group_5_2_deallist_poitype__d__d___ab_i550poi_shfw__d__leftflow___ab_ihotelpoilist__b__b___ab_itravelsearch0814__b__leftflow___ab_i_group_6_0_search_hotword__b__leftflow___ab_sieve_multiple_staticscore__base__base___ab_h_hotel_search_hot__b__b___ab_i_group_5_9_onsite__a__leftflow___ab_i_group_pingjiapush__a__a___ab_b_catesearchreplace__b__b___ab_b_deal_sieve_migrate__b__b___ab_i_group_travelhomepage0630__a__a___ab_i550poi_lr__d__leftflow___ab_b_searchmaiton__c__c___ab_groupcontext__a__a___ab_maidan_distance_first__smartfirst__smartfirst___ab_i_group_5_9notificationtest__a__a___ab_dealzhanshi__a__a1___ab_i_group_5_8_dns__a__leftflow___ab_ihotelbkdetail__a__a___ab_v1_po1_sieve_migrate__search__search
基于这个痛点，我们采用另一种上报方式；
方案二
流程：
（1）（客户端的工作）：app启动或切换城市，会请求abtest服务后台，获得所有的实验的以及命中的策略缓存在app中。
（2）(abtest后台的工作)：abtest接收一个uuid＋ci＋pt的请求，返回给app所有的实验的以及命中的策略，同时将这次请求和结果通过flume_agent收集日志，同步到Hadoop，最后导入Hive。
（3）（客户端的工作）：在第1步的请求中的获得的所有的实验的以及命中的策略缓存在app中。
（4）(客户端的工作) : 进入到一个做ab实验的界面，按照第3步命中的实验的策略＋展示的业务数据处理展示逻辑。
（5）（客户端的工作：）：会把第4步这个界面的信息和埋点信息上传到数据中心的原始日志，异步步少重试的方式上报埋点，按HTTP GET/POST 日志收集方式，MGE，MGP，MPT的信息定义可以。移动页面流跟踪事件，这些事件封装为MPT事件，具体格式如下：</pre><pre name="code" class="javascript">"nm":"MPT",//页面流跟踪事件(PageTrack)
"val":{
"root": //层级前缀
"name": //页面名/组件名/弹窗名
"content": //数据请求URL内容/弹窗内容
"type": //page/alert
}
"nm":"MGE",//Event跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"cid": //页面名 ||||类别 category id
"act": //动作名 ||||动作 action
"lab": //动作描述 ||||注释 label
"val": //页面描述 ||||权值 value
}
"nm":"MGP",//页面跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"root": //层级前缀（非必需）
"name": //页面名/组件名/弹窗名（必须）
"content": //数据请求URL内容/弹窗内容（必须）
"type": //page/alert
} （6）（数据组的工作）：应用系统可以通过flume，将原始日志同步到Hadoop，最后导入Hive表，通过关联的条件将两个hive表关联，同时关联一些点击下单等数据，清洗数据成报表。
方案一和方案二的比较：
（1）方案一的缺点是会添加客户端RD的URL拼接工作，致命的是实验到达一定个数，访问页面过深URL过长导致被截断（sa控制http的url的长度和header大小）
（2）方案一的有点是，数据组RD清洗数据比较方便，只需收集ngixn日志，对url进行清洗即可产生报表，只需要关联点单点击等报表。
（3）方案二的优点是，通过各自打埋点成原始日志到hadoop平台方式，客户端只关心自己命中的策略以及处理的业务逻辑，与业务无关的事情切入较少。
（4）方案二的缺点是，客户打的埋点需要跟abtest后台的表进行关联，关联的逻辑不固定，添加了清洗数据的复杂度。
最后基于系统长期的发展，采取了方案二，前期使用的方案一将在app的新版本中废弃。
（2）服务端实验：
其实服务端的实验跟客户端的实验的是类似的，只需要添加额外的工作：在服务端请求abtest后台，需要知道本次请求以及实验命中的策略，并将结果返回给客户端。
原文地址：http://blog.csdn.net/weiguang_ ... 03239 查看全部
AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
ABtest一个总的目的和意图是，判断哪种UI或rerank策略更优，通过事实的依据（ CTR或下单率）判断哪种策略更符合用户的习惯和需求。
一、需求驱使
我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。
下面看一个例子：
在展示“格林秀上午酒店”这个poi时有客户端两种UI：
方案A：如左图，评分展示星状图片，消费人数再右边；
方案B：如右图，只展示评分分数，后边添加消费人数；
我们很难知道那种方案比较好，那我们可以做个实验，把a和B方案同时放到线上的生产环境，让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用报表如下图，通过大自然的优胜劣汰法则，我们可以通过CTR或下单率等指标看哪个方案更符合设计目标。
二、系统模型
abtest实验可以分成两种，客户端client实验和服务端server实验，客户端实验一般来说只是UI上的实验，比如上面的例子，纯粹是展示端的策略；而服务端的实验是返回给client数据的内容做实验，比如推荐的策略，订单列表rerank策略等。下面通过client和服务端的实验分别做介绍。
（1）客户端实验：
方案1:
ABTest业务流程描述：
（1）客户端在需要获取ABTest策略的地方，通过RPC接口获取uuid在ABTest1这个实验下的规则：{
"data": [
{
"name": "test1",//实验key
"strategy": "strategy1", //策略key，客户端根据策略key选择策略方案
"flow": "flow1", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
}
其中testkey参数可以是多个ABTest实验的key：abtest1,abtest2。
（2）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1__strategy1__flow1，Nginx将utm_compaign打印到access日志。
（3）客户端在另一个需要获取ABTest策略的地方，通过http接口/get/abtest/{testkey}/{uuid} 获取uuid在ABTest2这个实验下的规则：{
"data": [
{
"name": "abtest2",//实验key，
"strategy": "strategy2", //策略key，客户端根据策略key选择策略方案
"flow": "flow2", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
}
（4）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1_strategy1__flow1___abtest2__strategy2__flow2，实验&策略&流量组采用两个下划线分隔，多个实验间采用三个下划线分隔。
（5）Nginx将URL中的utm_compaign打印到access日志，flume收集Nginx access 日志，同步到Hadoop，最后导入Hive。
（6）PM在报表系统，通过规则维度查询点击、转化报表。
这样导致的问题是url中utm_compaign的F字段过长，当实验到达一定数量的时候会出现，url过长，抓包会发现。实际上，客户端只关心我在某个界面中这次请求（uuid＋ci＋platform）命中的实验及策略，连utm_campaign都懒得拼接。
如URL中有utm_campaign=Fab_homepagewebview0717__b__d___ab_b_food_57_purepoilist_extinfo__a__a___ab_b_selectlist_paidui__a__leftflow___ab_i550poi_ktv__d__leftflow___ab_i_5_9_travelpoidetail__b__a___ab_i550poi_xxyl__d__d___ab_mingdiangexinghua0707__j__j___ab_waimaiwending__b__b___ab_b_travelsearchhot__a__a___ab_ifoodadvert__b__b___ab_pindaoqugexinghua0708__e__e___ab_itriphotpoi__b__leftflow___ab_i_6_0_webview__a__a___ab_b_travelpoilistrank__b__b2___ab_i_group_5_7_search_chunpoi__b__b1___ab_i_group_5_8_spdy__b__b___ab_ihotelqianzhi__b__b___i_group_5_2_deallist_poitype__d__d___ab_i550poi_shfw__d__leftflow___ab_ihotelpoilist__b__b___ab_itravelsearch0814__b__leftflow___ab_i_group_6_0_search_hotword__b__leftflow___ab_sieve_multiple_staticscore__base__base___ab_h_hotel_search_hot__b__b___ab_i_group_5_9_onsite__a__leftflow___ab_i_group_pingjiapush__a__a___ab_b_catesearchreplace__b__b___ab_b_deal_sieve_migrate__b__b___ab_i_group_travelhomepage0630__a__a___ab_i550poi_lr__d__leftflow___ab_b_searchmaiton__c__c___ab_groupcontext__a__a___ab_maidan_distance_first__smartfirst__smartfirst___ab_i_group_5_9notificationtest__a__a___ab_dealzhanshi__a__a1___ab_i_group_5_8_dns__a__leftflow___ab_ihotelbkdetail__a__a___ab_v1_po1_sieve_migrate__search__search
基于这个痛点，我们采用另一种上报方式；
方案二
流程：
（1）（客户端的工作）：app启动或切换城市，会请求abtest服务后台，获得所有的实验的以及命中的策略缓存在app中。
（2）(abtest后台的工作)：abtest接收一个uuid＋ci＋pt的请求，返回给app所有的实验的以及命中的策略，同时将这次请求和结果通过flume_agent收集日志，同步到Hadoop，最后导入Hive。
（3）（客户端的工作）：在第1步的请求中的获得的所有的实验的以及命中的策略缓存在app中。
（4）(客户端的工作) : 进入到一个做ab实验的界面，按照第3步命中的实验的策略＋展示的业务数据处理展示逻辑。
（5）（客户端的工作：）：会把第4步这个界面的信息和埋点信息上传到数据中心的原始日志，异步步少重试的方式上报埋点，按HTTP GET/POST 日志收集方式，MGE，MGP，MPT的信息定义可以。移动页面流跟踪事件，这些事件封装为MPT事件，具体格式如下：</pre><pre name="code" class="javascript">"nm":"MPT",//页面流跟踪事件(PageTrack)
"val":{
"root": //层级前缀
"name": //页面名/组件名/弹窗名
"content": //数据请求URL内容/弹窗内容
"type": //page/alert
}
"nm":"MGE",//Event跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"cid": //页面名 ||||类别 category id
"act": //动作名 ||||动作 action
"lab": //动作描述 ||||注释 label
"val": //页面描述 ||||权值 value
}
"nm":"MGP",//页面跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"root": //层级前缀（非必需）
"name": //页面名/组件名/弹窗名（必须）
"content": //数据请求URL内容/弹窗内容（必须）
"type": //page/alert
} （6）（数据组的工作）：应用系统可以通过flume，将原始日志同步到Hadoop，最后导入Hive表，通过关联的条件将两个hive表关联，同时关联一些点击下单等数据，清洗数据成报表。
方案一和方案二的比较：
（1）方案一的缺点是会添加客户端RD的URL拼接工作，致命的是实验到达一定个数，访问页面过深URL过长导致被截断（sa控制http的url的长度和header大小）
（2）方案一的有点是，数据组RD清洗数据比较方便，只需收集ngixn日志，对url进行清洗即可产生报表，只需要关联点单点击等报表。
（3）方案二的优点是，通过各自打埋点成原始日志到hadoop平台方式，客户端只关心自己命中的策略以及处理的业务逻辑，与业务无关的事情切入较少。
（4）方案二的缺点是，客户打的埋点需要跟abtest后台的表进行关联，关联的逻辑不固定，添加了清洗数据的复杂度。
最后基于系统长期的发展，采取了方案二，前期使用的方案一将在app的新版本中废弃。
（2）服务端实验：
其实服务端的实验跟客户端的实验的是类似的，只需要添加额外的工作：在服务端请求abtest后台，需要知道本次请求以及实验命中的策略，并将结果返回给客户端。
原文地址：http://blog.csdn.net/weiguang_ ... 03239 查看全部
AB测试的概念定义如下：
ABtest一个总的目的和意图是，判断哪种UI或rerank策略更优，通过事实的依据（ CTR或下单率）判断哪种策略更符合用户的习惯和需求。
一、需求驱使
我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。
下面看一个例子：
在展示“格林秀上午酒店”这个poi时有客户端两种UI：
方案A：如左图，评分展示星状图片，消费人数再右边；
方案B：如右图，只展示评分分数，后边添加消费人数；
我们很难知道那种方案比较好，那我们可以做个实验，把a和B方案同时放到线上的生产环境，让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用报表如下图，通过大自然的优胜劣汰法则，我们可以通过CTR或下单率等指标看哪个方案更符合设计目标。
二、系统模型
abtest实验可以分成两种，客户端client实验和服务端server实验，客户端实验一般来说只是UI上的实验，比如上面的例子，纯粹是展示端的策略；而服务端的实验是返回给client数据的内容做实验，比如推荐的策略，订单列表rerank策略等。下面通过client和服务端的实验分别做介绍。
（1）客户端实验：
方案1:
ABTest业务流程描述：
（1）客户端在需要获取ABTest策略的地方，通过RPC接口获取uuid在ABTest1这个实验下的规则：
其中testkey参数可以是多个ABTest实验的key：abtest1,abtest2。
（2）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1__strategy1__flow1，Nginx将utm_compaign打印到access日志。
（3）客户端在另一个需要获取ABTest策略的地方，通过http接口/get/abtest/{testkey}/{uuid} 获取uuid在ABTest2这个实验下的规则：
（4）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1_strategy1__flow1___abtest2__strategy2__flow2，实验&策略&流量组采用两个下划线分隔，多个实验间采用三个下划线分隔。
（5）Nginx将URL中的utm_compaign打印到access日志，flume收集Nginx access 日志，同步到Hadoop，最后导入Hive。
（6）PM在报表系统，通过规则维度查询点击、转化报表。
这样导致的问题是url中utm_compaign的F字段过长，当实验到达一定数量的时候会出现，url过长，抓包会发现。实际上，客户端只关心我在某个界面中这次请求（uuid＋ci＋platform）命中的实验及策略，连utm_campaign都懒得拼接。
如URL中有
基于这个痛点，我们采用另一种上报方式；
方案二
流程：
（1）（客户端的工作）：app启动或切换城市，会请求abtest服务后台，获得所有的实验的以及命中的策略缓存在app中。
（2）(abtest后台的工作)：abtest接收一个uuid＋ci＋pt的请求，返回给app所有的实验的以及命中的策略，同时将这次请求和结果通过flume_agent收集日志，同步到Hadoop，最后导入Hive。
（3）（客户端的工作）：在第1步的请求中的获得的所有的实验的以及命中的策略缓存在app中。
（4）(客户端的工作) : 进入到一个做ab实验的界面，按照第3步命中的实验的策略＋展示的业务数据处理展示逻辑。
（5）（客户端的工作：）：会把第4步这个界面的信息和埋点信息上传到数据中心的原始日志，异步步少重试的方式上报埋点，按HTTP GET/POST 日志收集方式，MGE，MGP，MPT的信息定义可以。移动页面流跟踪事件，这些事件封装为MPT事件，具体格式如下：
方案一和方案二的比较：
（1）方案一的缺点是会添加客户端RD的URL拼接工作，致命的是实验到达一定个数，访问页面过深URL过长导致被截断（sa控制http的url的长度和header大小）
（2）方案一的有点是，数据组RD清洗数据比较方便，只需收集ngixn日志，对url进行清洗即可产生报表，只需要关联点单点击等报表。
（3）方案二的优点是，通过各自打埋点成原始日志到hadoop平台方式，客户端只关心自己命中的策略以及处理的业务逻辑，与业务无关的事情切入较少。
（4）方案二的缺点是，客户打的埋点需要跟abtest后台的表进行关联，关联的逻辑不固定，添加了清洗数据的复杂度。
最后基于系统长期的发展，采取了方案二，前期使用的方案一将在app的新版本中废弃。
（2）服务端实验：
其实服务端的实验跟客户端的实验的是类似的，只需要添加额外的工作：在服务端请求abtest后台，需要知道本次请求以及实验命中的策略，并将结果返回给客户端。
原文地址：http://blog.csdn.net/weiguang_ ... 03239
AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
ABtest一个总的目的和意图是，判断哪种UI或rerank策略更优，通过事实的依据（ CTR或下单率）判断哪种策略更符合用户的习惯和需求。
一、需求驱使
我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。
所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。
下面看一个例子：
在展示“格林秀上午酒店”这个poi时有客户端两种UI：
方案A：如左图，评分展示星状图片，消费人数再右边；
方案B：如右图，只展示评分分数，后边添加消费人数；
我们很难知道那种方案比较好，那我们可以做个实验，把a和B方案同时放到线上的生产环境，让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用报表如下图，通过大自然的优胜劣汰法则，我们可以通过CTR或下单率等指标看哪个方案更符合设计目标。
二、系统模型
abtest实验可以分成两种，客户端client实验和服务端server实验，客户端实验一般来说只是UI上的实验，比如上面的例子，纯粹是展示端的策略；而服务端的实验是返回给client数据的内容做实验，比如推荐的策略，订单列表rerank策略等。下面通过client和服务端的实验分别做介绍。
（1）客户端实验：
方案1:
ABTest业务流程描述：
（1）客户端在需要获取ABTest策略的地方，通过RPC接口获取uuid在ABTest1这个实验下的规则：
{
"data": [
{
"name": "test1",//实验key
"strategy": "strategy1", //策略key，客户端根据策略key选择策略方案
"flow": "flow1", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
} 其中testkey参数可以是多个ABTest实验的key：abtest1,abtest2。
（2）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1__strategy1__flow1，Nginx将utm_compaign打印到access日志。
（3）客户端在另一个需要获取ABTest策略的地方，通过http接口/get/abtest/{testkey}/{uuid} 获取uuid在ABTest2这个实验下的规则：
{
"data": [
{
"name": "abtest2",//实验key，
"strategy": "strategy2", //策略key，客户端根据策略key选择策略方案
"flow": "flow2", //流量组，用于上报。每个流量组只属于一个策略。
"finished": false //标识实验是否终止，如果已经终止，则不再向utm_compaign参数的F字段append该规则，但是不影响规则，原规则依然生效。
}
]
} （4）之后客户端向server发起的全部请求，URL的utm_compaign参数中的F位添加字符串：Fabtest1_strategy1__flow1___abtest2__strategy2__flow2，实验&策略&流量组采用两个下划线分隔，多个实验间采用三个下划线分隔。
（5）Nginx将URL中的utm_compaign打印到access日志，flume收集Nginx access 日志，同步到Hadoop，最后导入Hive。
（6）PM在报表系统，通过规则维度查询点击、转化报表。
这样导致的问题是url中utm_compaign的F字段过长，当实验到达一定数量的时候会出现，url过长，抓包会发现。实际上，客户端只关心我在某个界面中这次请求（uuid＋ci＋platform）命中的实验及策略，连utm_campaign都懒得拼接。
如URL中有
utm_campaign=Fab_homepagewebview0717__b__d___ab_b_food_57_purepoilist_extinfo__a__a___ab_b_selectlist_paidui__a__leftflow___ab_i550poi_ktv__d__leftflow___ab_i_5_9_travelpoidetail__b__a___ab_i550poi_xxyl__d__d___ab_mingdiangexinghua0707__j__j___ab_waimaiwending__b__b___ab_b_travelsearchhot__a__a___ab_ifoodadvert__b__b___ab_pindaoqugexinghua0708__e__e___ab_itriphotpoi__b__leftflow___ab_i_6_0_webview__a__a___ab_b_travelpoilistrank__b__b2___ab_i_group_5_7_search_chunpoi__b__b1___ab_i_group_5_8_spdy__b__b___ab_ihotelqianzhi__b__b___i_group_5_2_deallist_poitype__d__d___ab_i550poi_shfw__d__leftflow___ab_ihotelpoilist__b__b___ab_itravelsearch0814__b__leftflow___ab_i_group_6_0_search_hotword__b__leftflow___ab_sieve_multiple_staticscore__base__base___ab_h_hotel_search_hot__b__b___ab_i_group_5_9_onsite__a__leftflow___ab_i_group_pingjiapush__a__a___ab_b_catesearchreplace__b__b___ab_b_deal_sieve_migrate__b__b___ab_i_group_travelhomepage0630__a__a___ab_i550poi_lr__d__leftflow___ab_b_searchmaiton__c__c___ab_groupcontext__a__a___ab_maidan_distance_first__smartfirst__smartfirst___ab_i_group_5_9notificationtest__a__a___ab_dealzhanshi__a__a1___ab_i_group_5_8_dns__a__leftflow___ab_ihotelbkdetail__a__a___ab_v1_po1_sieve_migrate__search__search
基于这个痛点，我们采用另一种上报方式；
方案二
流程：
（1）（客户端的工作）：app启动或切换城市，会请求abtest服务后台，获得所有的实验的以及命中的策略缓存在app中。
（2）(abtest后台的工作)：abtest接收一个uuid＋ci＋pt的请求，返回给app所有的实验的以及命中的策略，同时将这次请求和结果通过flume_agent收集日志，同步到Hadoop，最后导入Hive。
（3）（客户端的工作）：在第1步的请求中的获得的所有的实验的以及命中的策略缓存在app中。
（4）(客户端的工作) : 进入到一个做ab实验的界面，按照第3步命中的实验的策略＋展示的业务数据处理展示逻辑。
（5）（客户端的工作：）：会把第4步这个界面的信息和埋点信息上传到数据中心的原始日志，异步步少重试的方式上报埋点，按HTTP GET/POST 日志收集方式，MGE，MGP，MPT的信息定义可以。移动页面流跟踪事件，这些事件封装为MPT事件，具体格式如下：
</pre><pre name="code" class="javascript">"nm":"MPT",//页面流跟踪事件(PageTrack)（6）（数据组的工作）：应用系统可以通过flume，将原始日志同步到Hadoop，最后导入Hive表，通过关联的条件将两个hive表关联，同时关联一些点击下单等数据，清洗数据成报表。
"val":{
"root": //层级前缀
"name": //页面名/组件名/弹窗名
"content": //数据请求URL内容/弹窗内容
"type": //page/alert
}
"nm":"MGE",//Event跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"cid": //页面名 ||||类别 category id
"act": //动作名 ||||动作 action
"lab": //动作描述 ||||注释 label
"val": //页面描述 ||||权值 value
}
"nm":"MGP",//页面跟踪，需要客户端手工埋点，用于解决临时统计需求
"val":{
"root": //层级前缀（非必需）
"name": //页面名/组件名/弹窗名（必须）
"content": //数据请求URL内容/弹窗内容（必须）
"type": //page/alert
}
方案一和方案二的比较：
（1）方案一的缺点是会添加客户端RD的URL拼接工作，致命的是实验到达一定个数，访问页面过深URL过长导致被截断（sa控制http的url的长度和header大小）
（2）方案一的有点是，数据组RD清洗数据比较方便，只需收集ngixn日志，对url进行清洗即可产生报表，只需要关联点单点击等报表。
（3）方案二的优点是，通过各自打埋点成原始日志到hadoop平台方式，客户端只关心自己命中的策略以及处理的业务逻辑，与业务无关的事情切入较少。
（4）方案二的缺点是，客户打的埋点需要跟abtest后台的表进行关联，关联的逻辑不固定，添加了清洗数据的复杂度。
最后基于系统长期的发展，采取了方案二，前期使用的方案一将在app的新版本中废弃。
（2）服务端实验：
其实服务端的实验跟客户端的实验的是类似的，只需要添加额外的工作：在服务端请求abtest后台，需要知道本次请求以及实验命中的策略，并将结果返回给客户端。
原文地址：http://blog.csdn.net/weiguang_ ... 03239