消息通信机制:同步和异步

专业名词zkbhj 发表了文章 • 0 个评论 • 1274 次浏览 • 2017-01-03 16:24 • 来自相关话题

消息通信的基本方式有两种:

1、同步方式

两个通信应用服务之间必须要进行同步,两个服务之间必须都是正常运行的。发送程序和接收程序都必须一直处于运行状态,并且随时做好相互通信的准备。

发送程序首先向接收程序发起一个请求,称之为发送消息,发送程序紧接着就会堵塞当前自身的进程,不与其他应用进行任何的通信以及交互,等待接收程序的响应,待发送消息得到接收程序的返回消息之后会继续向下运行,进行下一步的业务处理。

2、异步方式

两个通信应用之间可以不用同时在线等待,任何一方只需各自处理自己的业务,比如发送方发送消息以后不用登录接收方的响应,可以接着处理其他的任务。也就是说发送方和接收方都是相互独立存在的,发送方只管发送,接收方只能接收,无须去等待对方的响应。

Java中JMS就是典型的异步消息处理机制,JMS消息有两种类型:点对点、发布/订阅。
 
参考文章:http://www.cnblogs.com/candle806/archive/2013/02/19/2917155.html
  查看全部
消息通信的基本方式有两种:

1、同步方式

两个通信应用服务之间必须要进行同步,两个服务之间必须都是正常运行的。发送程序和接收程序都必须一直处于运行状态,并且随时做好相互通信的准备。

发送程序首先向接收程序发起一个请求,称之为发送消息,发送程序紧接着就会堵塞当前自身的进程,不与其他应用进行任何的通信以及交互,等待接收程序的响应,待发送消息得到接收程序的返回消息之后会继续向下运行,进行下一步的业务处理。

2、异步方式

两个通信应用之间可以不用同时在线等待,任何一方只需各自处理自己的业务,比如发送方发送消息以后不用登录接收方的响应,可以接着处理其他的任务。也就是说发送方和接收方都是相互独立存在的,发送方只管发送,接收方只能接收,无须去等待对方的响应。

Java中JMS就是典型的异步消息处理机制,JMS消息有两种类型:点对点、发布/订阅。
 
参考文章:http://www.cnblogs.com/candle806/archive/2013/02/19/2917155.html
 

CAP原则学习笔记

专业名词zkbhj 发表了文章 • 0 个评论 • 1929 次浏览 • 2017-01-03 12:26 • 来自相关话题

最近在学习消息中间件的时候,接触到了分布式系统,进而接触到CAP理论,上一次接触还是在年初的时候公司的技术分享会上,有人在介绍项目的时候简单介绍了这个CAP理论,但并没有深入研究。这次,该是时候研究一下这个CAP原则到底是个啥了。
其实,CAP理论在大部分的开发者心里都有一定的位置,在互联网界也有广泛的知名度,稍微经验丰富或者知识广泛的程序员都会把它作为衡量一个系统,尤其是分布式系统的设计准则,也就是我们说的CAP原则。大家都非常清晰的知道:任何的分布式系统,在可用性、一致性和分区容错性方面,是不可兼得的,就像是我们常说的“鱼和熊掌不可兼得”一样,最多值能得其二。所以说,任何一个分布式系统的设计,都是根据各自的实际应用场景和需求,对这三个维度的的不同取舍而已。
 
说了这么多,大家可能还是比较懵逼。到底什么是CAP原则?下面先知道下它的定义:

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。换句话说,就是说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。

 
定义就是定义,一句话,就把上面的一大段废话说的清晰明了!那可能接下来,又来了个“三脸懵逼”,到底啥是一致性、可用性和分区容错性?同样的,上定义:

● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。一致性被称为原子对象,任何的读写都应该看起来是“原子“的,或串行的。(等同于所有节点访问同一份最新的数据副本)
● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

 
现在大家应该对这些基本概念有了一个比较清晰的认识。那我们在深入理解CAP原则之前,先了解下CAP原则的前世今生。
 
为什么会产生这个CAP理论?
 
1985年Lynch证明了异步通信中不存在任何一致性的分布式算法(FLP Impossibility)的同时,人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在,但若能找到一些设计因素,并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如,在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足。
2000年,Eric Brewer教授在PODC的研讨会上提出了一个猜想:一致性、可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个!这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征,断言用此三者可以划分所有的分布式系统,并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体,对实际系统的构建也更具有可操作性!Brewer教授当时想象的分布式场景是webservice,一组websevrice后台运行着众多的server,对service的读写会反应到后台的server集群,并对CAP进行了定义,就是上面列出的定义。高可用、数据一致是很多系统设计的目标,但是分区又是不可避免的事情,CAP的出现仿佛是一盏明灯,它揭露了分布式系统的本质,并给出了设计的准则,而这正是1985年以来人们正在寻找的东西!所以CAP在当时的影响力是非常大的!
2002年,Lynch与其他人证明了Brewer猜想,从而把CAP上升为一个定理。
 
这么一帆风顺吗?直至今日,对CAP理论的质疑声不断
 
就在这些理论被踢出来,大家觉得终于对分布式系统设计有了指导原则的时候,有些工程师和研究者就对CAP提出了各种质疑,纷纷有用反例证明着CAP在各种场合不适用性,同时挑战着Lynch的证明结果!你是否看了CAP的概念定义后还是感觉很模糊?如果是,你并不孤独,有很多人都是如此!CAP没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求,而C、A、P在这些不同场景中的含义可能完全不同,这种无视差异化的定义导致了非常大的概念模糊,同时也变成CAP被质疑的源头!其中,这些质疑主要集中在以下几个方面:
概念模糊混乱,废话一堆,不能作为定理不适用于数据库事务架构应该构建不可变模型避免CAP的复杂性分区容错概念有误导
 
其实,搞了半天,我也不是很清晰这些高大上的推论和证明,也不是我们该操心的,因为CAP理论的提出者和证明者也在后续对这些质疑进行了相应的“回击”!
 
回击和解释
 
面对大量的质疑,Brewer和Lynch终于坐不住了,因此两人纷纷出来澄清。Brewer于2012年重申”3个中的2个“这个表述是不准确的,在某些分区极少发生的情况下,三者能顺畅地在一起配合,而且CAP不仅仅是发生在整个系统中,可能是发生在某个子系统或系统的某个阶段。
Lynch也在10年后的2012年重写了论文,缩小CAP适用的定义,消除质疑的场景,展示了CAP在非单一一致性结果下的广阔的研究结果!并顺便暗示CAP定理依旧正确!
 
多么精彩的“撕逼”过程!但是对我们来说,真正有意义的还是CAP理论本身。
 
我们该如何看待CAP理论本身?
 
首先肯定的是,CAP并不适合再作为一个适应任何场景的定理,它的正确性更加适合基于原子读写的NoSQL场景。质疑虽然很多,但很多质疑者只是偷欢概念,并没有解决各个因素之间的取舍问题。而无论如何C、A、P这个三个概念始终存在任何分布式系统,只是不同的模型会对其有不同的呈现,可能某些场景对三者之间的关系敏感,而另一些不敏感。就像Lynch所说,现在分布式系统有很多特性,比如扩展性、优雅降级等,随着时间的发展,或许这些也会被纳入研究范畴,而作为开发者,这都是我们需要考虑的问题,而不仅是CAP三者!
 
对CAP三者的选择
 
当处理CAP的问题时,你会有几个选择。最明显的是:

 
1.(CA)放弃Partition Tolerance:
如果你想避免partition问题发生,你就必须要阻止其发生。一种做法是将所有的东西(与事务相关的)都放到一台机器上。或者放在像rack这类的atomically-failling单元上。无法100%地保证,因为还是有可能部分失败,但你不太可能碰到由partition问题带来的负面效果。当然,这个选择会严重影响scale限制。

2.(CP)放弃Availability:
相对于放弃partition tolerance来说,其反面就是放弃availability。一旦遇到partition 事件,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂,而且恢复的节点需要处理逻辑,以便平滑地返回服务状态。

3.(AP)放弃Consistency:
或者如同Werner Vogels所提倡的,接受事情会变得“最终一致(Eventually Consistent)”(2008年12月更新)。Vogels的文章值得一读。他比我在这里讨论了更多的操作方面的细节。许多的不一致性并不比你想的需要更多的工作(意味着持续的consistency或许并不是我们所需要的)。在购书的例子中,如果一本库存的书,接到了2个订单,第二个就会成为备份订单。只要告知客户这种情况(请记住这是一种罕见的情况),也许每个人都会高兴的。
 

 
总结
 
在Consistency, Availability和Partition-tolerance中,你只能保证2点,这是确实的,并且已经被这个星球上最成功的网站证实了。如果对网站是有效的,我看不出在企业环境中,在日常的工作中,不考虑同样的折衷设计的理由。当然,CAP理论也只是对我们的分布式系统设计起到一个指导性的作用,我们在设计系统时,要考虑的方面也绝非只有这三个方面,正如上文所提到的,扩展性、降级等也是我们需要考虑的内容,所有,只有结合实际的业务需求和使用场景,才能设计出更加合适的系统。
 
参考资料:
1、http://blog.csdn.net/chen77716/article/details/30635543
2、http://blog.sina.com.cn/s/blog_493a8455010161hi.html
  查看全部
最近在学习消息中间件的时候,接触到了分布式系统,进而接触到CAP理论,上一次接触还是在年初的时候公司的技术分享会上,有人在介绍项目的时候简单介绍了这个CAP理论,但并没有深入研究。这次,该是时候研究一下这个CAP原则到底是个啥了。
其实,CAP理论在大部分的开发者心里都有一定的位置,在互联网界也有广泛的知名度,稍微经验丰富或者知识广泛的程序员都会把它作为衡量一个系统,尤其是分布式系统的设计准则,也就是我们说的CAP原则。大家都非常清晰的知道:任何的分布式系统,在可用性、一致性和分区容错性方面,是不可兼得的,就像是我们常说的“鱼和熊掌不可兼得”一样,最多值能得其二。所以说,任何一个分布式系统的设计,都是根据各自的实际应用场景和需求,对这三个维度的的不同取舍而已。
 
说了这么多,大家可能还是比较懵逼。到底什么是CAP原则?下面先知道下它的定义:


CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。换句话说,就是说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。


 
定义就是定义,一句话,就把上面的一大段废话说的清晰明了!那可能接下来,又来了个“三脸懵逼”,到底啥是一致性、可用性和分区容错性?同样的,上定义:


● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。一致性被称为原子对象,任何的读写都应该看起来是“原子“的,或串行的。(等同于所有节点访问同一份最新的数据副本)
● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。


 
现在大家应该对这些基本概念有了一个比较清晰的认识。那我们在深入理解CAP原则之前,先了解下CAP原则的前世今生。
 
为什么会产生这个CAP理论?
 
1985年Lynch证明了异步通信中不存在任何一致性的分布式算法(FLP Impossibility)的同时,人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在,但若能找到一些设计因素,并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如,在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足。
2000年,Eric Brewer教授在PODC的研讨会上提出了一个猜想:一致性、可用性和分区容错性三者无法在分布式系统中被同时满足,并且最多只能满足其中两个!这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征,断言用此三者可以划分所有的分布式系统,并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体,对实际系统的构建也更具有可操作性!Brewer教授当时想象的分布式场景是webservice,一组websevrice后台运行着众多的server,对service的读写会反应到后台的server集群,并对CAP进行了定义,就是上面列出的定义。高可用、数据一致是很多系统设计的目标,但是分区又是不可避免的事情,CAP的出现仿佛是一盏明灯,它揭露了分布式系统的本质,并给出了设计的准则,而这正是1985年以来人们正在寻找的东西!所以CAP在当时的影响力是非常大的!
2002年,Lynch与其他人证明了Brewer猜想,从而把CAP上升为一个定理。
 
这么一帆风顺吗?直至今日,对CAP理论的质疑声不断
 
就在这些理论被踢出来,大家觉得终于对分布式系统设计有了指导原则的时候,有些工程师和研究者就对CAP提出了各种质疑,纷纷有用反例证明着CAP在各种场合不适用性,同时挑战着Lynch的证明结果!你是否看了CAP的概念定义后还是感觉很模糊?如果是,你并不孤独,有很多人都是如此!CAP没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求,而C、A、P在这些不同场景中的含义可能完全不同,这种无视差异化的定义导致了非常大的概念模糊,同时也变成CAP被质疑的源头!其中,这些质疑主要集中在以下几个方面:
  • 概念模糊混乱,废话一堆,不能作为定理
  • 不适用于数据库事务架构
  • 应该构建不可变模型避免CAP的复杂性
  • 分区容错概念有误导

 
其实,搞了半天,我也不是很清晰这些高大上的推论和证明,也不是我们该操心的,因为CAP理论的提出者和证明者也在后续对这些质疑进行了相应的“回击”!
 
回击和解释
 
面对大量的质疑,Brewer和Lynch终于坐不住了,因此两人纷纷出来澄清。Brewer于2012年重申”3个中的2个“这个表述是不准确的,在某些分区极少发生的情况下,三者能顺畅地在一起配合,而且CAP不仅仅是发生在整个系统中,可能是发生在某个子系统或系统的某个阶段。
Lynch也在10年后的2012年重写了论文,缩小CAP适用的定义,消除质疑的场景,展示了CAP在非单一一致性结果下的广阔的研究结果!并顺便暗示CAP定理依旧正确!
 
多么精彩的“撕逼”过程!但是对我们来说,真正有意义的还是CAP理论本身。
 
我们该如何看待CAP理论本身?
 
首先肯定的是,CAP并不适合作为一个适应任何场景的定理,它的正确性更加适合基于原子读写的NoSQL场景。质疑虽然很多,但很多质疑者只是偷欢概念,并没有解决各个因素之间的取舍问题。而无论如何C、A、P这个三个概念始终存在任何分布式系统,只是不同的模型会对其有不同的呈现,可能某些场景对三者之间的关系敏感,而另一些不敏感。就像Lynch所说,现在分布式系统有很多特性,比如扩展性、优雅降级等,随着时间的发展,或许这些也会被纳入研究范畴,而作为开发者,这都是我们需要考虑的问题,而不仅是CAP三者!
 
对CAP三者的选择
 
当处理CAP的问题时,你会有几个选择。最明显的是:


 
1.(CA)放弃Partition Tolerance:
如果你想避免partition问题发生,你就必须要阻止其发生。一种做法是将所有的东西(与事务相关的)都放到一台机器上。或者放在像rack这类的atomically-failling单元上。无法100%地保证,因为还是有可能部分失败,但你不太可能碰到由partition问题带来的负面效果。当然,这个选择会严重影响scale限制。

2.(CP)放弃Availability:
相对于放弃partition tolerance来说,其反面就是放弃availability。一旦遇到partition 事件,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂,而且恢复的节点需要处理逻辑,以便平滑地返回服务状态。

3.(AP)放弃Consistency:
或者如同Werner Vogels所提倡的,接受事情会变得“最终一致(Eventually Consistent)”(2008年12月更新)。Vogels的文章值得一读。他比我在这里讨论了更多的操作方面的细节。许多的不一致性并不比你想的需要更多的工作(意味着持续的consistency或许并不是我们所需要的)。在购书的例子中,如果一本库存的书,接到了2个订单,第二个就会成为备份订单。只要告知客户这种情况(请记住这是一种罕见的情况),也许每个人都会高兴的。
 


 
总结
 
在Consistency, Availability和Partition-tolerance中,你只能保证2点,这是确实的,并且已经被这个星球上最成功的网站证实了。如果对网站是有效的,我看不出在企业环境中,在日常的工作中,不考虑同样的折衷设计的理由。当然,CAP理论也只是对我们的分布式系统设计起到一个指导性的作用,我们在设计系统时,要考虑的方面也绝非只有这三个方面,正如上文所提到的,扩展性、降级等也是我们需要考虑的内容,所有,只有结合实际的业务需求和使用场景,才能设计出更加合适的系统。
 
参考资料:
1、http://blog.csdn.net/chen77716/article/details/30635543
2、http://blog.sina.com.cn/s/blog_493a8455010161hi.html
 

注销信用卡需要注意哪些事项?

回复

随手记zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 4161 次浏览 • 2016-12-30 16:47 • 来自相关话题

什么是微服务?

回复

专业名词zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 2552 次浏览 • 2016-12-30 16:23 • 来自相关话题

如何在Sublime Text中使用正则替换?

回复

工具软件zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 5143 次浏览 • 2016-12-30 15:16 • 来自相关话题

#原创#如何理解组件、插件和控件的区别?

专业名词zkbhj 发表了文章 • 0 个评论 • 1845 次浏览 • 2016-12-29 14:03 • 来自相关话题

在第一篇文章中分享了什么是消息队列,在和丽姐讨论的时候,被丽姐的几个问题再一次难住了。虽然能够了解大致的含义,但是对于每一个概念的理解并不是很深入,所以,针对丽姐给我提出来的几个“概念模糊”的知识点,又做了一次深入的了解和学习,这里和大家要分享的就是“组件”、“插件”和“控件”之间的区别!

其实,我们在学习或者开发过程中会经常提到这些个词,但我相信会有很多人和我一样,并不一定真正理解和认识他们之间的区别。要知道他们之间的区别,首先我们需要知道他们的定义分别是什么,因为定义是对事物最精炼的概括和描述,也是我们认识他们的最基本内容。

他们的定义:

组件:是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。是软件的一部分,软件的组成部分.

插件:插件(Plug-in,又称addin、add-in、addon或add-on,又译外挂)是一种遵循一定规范的应用程序接口编写出来的程序。插件不能脱离指定的平台单独运行。因为插件需要调用原纯净系统提供的函数库或者数据。例如网页中用到的flash插件,没有它浏览器不能播放flash。

控件:控件是对数据和方法的封装。控件可以有自己的属性和方法。属性是控件数据的简单访问者。方法则是控件的一些简单而可见的功能。简单理解,就是控件是编程中用到的,按钮就算是一个控件,窗口也是等等诸如此类。


 

现在,大家对这三者都有了一个定义级别的认识,那么接下来,我们就看看他们之间有啥区别?

首先,先来看看组件:

范围最广的应该是组件,英文component,提起组件我们不应该把他和具体的技术,什么dll文件,ocx控件,activex等等联系起来,因为组件仅仅是一个概念,如果非要解释的话,那就是凡是在软件开发中用到了软件的复用,被复用的部分都可以称为组件。构件的英文也是component,所以说构件和组件其实是一个意思只是翻译的不同而已。

举个例子的话,我在之前给大家写过一个封装了文件存储平台的文件上传组件,当各个项目需要上传或者读取在存储平台中的文件时,就可以在程序中引入这个组件,并通过组件提供的属性和方法,进行相应的设置或者是上传读取。这就是组件,他可以让我们的程序灵活性更高,只需要简单的复用和拼装,完成一个“复杂”的系统的开发建设,能够提高我们代码的复用性,提高我们的开发效率。

知道了组件,来认识下最有意思的插件:

顾名思义,“插件”是允许我们动态插入的,而不是在编程的时候静态的写入的,这就是与普通的组件的区别,因为普通的组件是在编程的时候引入的。我们可以以硬件为例子,例如USB接口,主机设定了标准的接口,而不必考虑外部接口具体是什么设备只要这种设备实现主机提供的接口,两者就可以通讯。这种插件有个最大的优点就是即插即用,即支持动态的插入。

 个人开发经验中,我觉得使用的最多的是在前端开发中,例如我们在开发前端页面时,可能需要一个比较漂亮的图片展示效果,比如轮播图,我们可能并不需要自己重新编写一个新的,只需要在网上找些开源的JQuery插件,根据它规定的“规则”(如何提供数据,如何调用),拼接到你的程序中,问题就解决了。效果不满意,还可以随便更换。这就是“即插即用”的fell!

插件是组件(构件)的一种,我们可以这样给插件进行定义,那就是凡是在应用程序中已经预留接口的组件就是插件,例如:Java中jdbc技术,jdbc只是一个接口,任何一个插件制造商只要实现这个接口都可以被java平台所使用。我们还可以拿IE插件作为例子,IE中之所以可以嵌入很多的应用程序,那是因为IE允许他们插入,说的明白一点,那就是在IE的源程序中已经为这些应用程序预留了接口,只要把通知浏览器已经加载了什么插件,浏览器就会调用预留的接口调用这些所谓的插件。

最后,就是控件:

当然控件也是组件(构件)的一种,按照网上的说法,控件就是可视化的组件,我也同意这种说法,其实再从普通组件中分解出控件完全是没有必要的,因为对于开发人员来讲,可不可视对于非软件人员来说可能很重要,但是对于软件人员来说又有什么区别呢?

所以,其实在常规的web开发过程中,可能比较不常说控件这种说法。如果非要说有,我觉得表单中的一个按钮、一个input,可以认为是一个控件。


总结一小下:

组件是一个概念级别的词,范围最广,只要在软件开发中可以被“复用”的部分或者模块,都可以称之为“组件”;

插件是具体化了的组件,只要规定好了“接口”,就可以实现“即插即用”,方便快捷;

控件也是具体化了的组件,不常用,一般来讲是“可视化”的,例如表单中的按钮、文本框等。

 

好啦,关于这三货的学习就到这,你理解了吗?个人理解,肯能有些地方有偏差,望指正~ 查看全部
在第一篇文章中分享了什么是消息队列,在和丽姐讨论的时候,被丽姐的几个问题再一次难住了。虽然能够了解大致的含义,但是对于每一个概念的理解并不是很深入,所以,针对丽姐给我提出来的几个“概念模糊”的知识点,又做了一次深入的了解和学习,这里和大家要分享的就是“组件”、“插件”和“控件”之间的区别!

其实,我们在学习或者开发过程中会经常提到这些个词,但我相信会有很多人和我一样,并不一定真正理解和认识他们之间的区别。要知道他们之间的区别,首先我们需要知道他们的定义分别是什么,因为定义是对事物最精炼的概括和描述,也是我们认识他们的最基本内容。

他们的定义:


组件:是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。是软件的一部分,软件的组成部分.

插件:插件(Plug-in,又称addin、add-in、addon或add-on,又译外挂)是一种遵循一定规范的应用程序接口编写出来的程序。插件不能脱离指定的平台单独运行。因为插件需要调用原纯净系统提供的函数库或者数据。例如网页中用到的flash插件,没有它浏览器不能播放flash。

控件:控件是对数据和方法的封装。控件可以有自己的属性和方法。属性是控件数据的简单访问者。方法则是控件的一些简单而可见的功能。简单理解,就是控件是编程中用到的,按钮就算是一个控件,窗口也是等等诸如此类。



 

现在,大家对这三者都有了一个定义级别的认识,那么接下来,我们就看看他们之间有啥区别?

首先,先来看看组件:

范围最广的应该是组件,英文component,提起组件我们不应该把他和具体的技术,什么dll文件,ocx控件,activex等等联系起来,因为组件仅仅是一个概念,如果非要解释的话,那就是凡是在软件开发中用到了软件的复用,被复用的部分都可以称为组件。构件的英文也是component,所以说构件和组件其实是一个意思只是翻译的不同而已。

举个例子的话,我在之前给大家写过一个封装了文件存储平台的文件上传组件,当各个项目需要上传或者读取在存储平台中的文件时,就可以在程序中引入这个组件,并通过组件提供的属性和方法,进行相应的设置或者是上传读取。这就是组件,他可以让我们的程序灵活性更高,只需要简单的复用和拼装,完成一个“复杂”的系统的开发建设,能够提高我们代码的复用性,提高我们的开发效率。

知道了组件,来认识下最有意思的插件:

顾名思义,“插件”是允许我们动态插入的,而不是在编程的时候静态的写入的,这就是与普通的组件的区别,因为普通的组件是在编程的时候引入的。我们可以以硬件为例子,例如USB接口,主机设定了标准的接口,而不必考虑外部接口具体是什么设备只要这种设备实现主机提供的接口,两者就可以通讯。这种插件有个最大的优点就是即插即用,即支持动态的插入。

 个人开发经验中,我觉得使用的最多的是在前端开发中,例如我们在开发前端页面时,可能需要一个比较漂亮的图片展示效果,比如轮播图,我们可能并不需要自己重新编写一个新的,只需要在网上找些开源的JQuery插件,根据它规定的“规则”(如何提供数据,如何调用),拼接到你的程序中,问题就解决了。效果不满意,还可以随便更换。这就是“即插即用”的fell!

插件是组件(构件)的一种,我们可以这样给插件进行定义,那就是凡是在应用程序中已经预留接口的组件就是插件,例如:Java中jdbc技术,jdbc只是一个接口,任何一个插件制造商只要实现这个接口都可以被java平台所使用。我们还可以拿IE插件作为例子,IE中之所以可以嵌入很多的应用程序,那是因为IE允许他们插入,说的明白一点,那就是在IE的源程序中已经为这些应用程序预留了接口,只要把通知浏览器已经加载了什么插件,浏览器就会调用预留的接口调用这些所谓的插件。

最后,就是控件:

当然控件也是组件(构件)的一种,按照网上的说法,控件就是可视化的组件,我也同意这种说法,其实再从普通组件中分解出控件完全是没有必要的,因为对于开发人员来讲,可不可视对于非软件人员来说可能很重要,但是对于软件人员来说又有什么区别呢?

所以,其实在常规的web开发过程中,可能比较不常说控件这种说法。如果非要说有,我觉得表单中的一个按钮、一个input,可以认为是一个控件。


总结一小下:

组件是一个概念级别的词,范围最广,只要在软件开发中可以被“复用”的部分或者模块,都可以称之为“组件”;

插件是具体化了的组件,只要规定好了“接口”,就可以实现“即插即用”,方便快捷;

控件也是具体化了的组件,不常用,一般来讲是“可视化”的,例如表单中的按钮、文本框等。

 

好啦,关于这三货的学习就到这,你理解了吗?个人理解,肯能有些地方有偏差,望指正~

并行和并发有什么区别?

回复

专业名词zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 2772 次浏览 • 2016-12-28 15:30 • 来自相关话题

组件、插件、控件有什么区别?

回复

专业名词zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 2909 次浏览 • 2016-12-27 18:16 • 来自相关话题

什么是分布式系统?

回复

专业名词zkbhj 回复了问题 • 1 人关注 • 1 个回复 • 2724 次浏览 • 2016-12-27 18:06 • 来自相关话题

进程和线程的区别和联系

专业名词zkbhj 发表了文章 • 0 个评论 • 1475 次浏览 • 2016-12-27 17:51 • 来自相关话题

1.定义

进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.

线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源.

2.关系
 
一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.

相对进程而言,线程是一个更加接近于执行体的概念,它可以与同进程中的其他线程共享数据,但拥有自己的栈空间,拥有独立的执行序列。

3.区别
 
进程和线程的主要差别在于它们是不同的操作系统资源管理方式。进程有独立的地址空间,一个进程崩溃后,在保护模式下不会对其它进程产生影响,而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量,但线程之间没有单独的地址空间,一个线程死掉就等于整个进程死掉,所以多进程的程序要比多线程的程序健壮,但在进程切换时,耗费资源较大,效率要差一些。但对于一些要求同时进行并且又要共享某些变量的并发操作,只能用线程,不能用进程。

1) 简而言之,一个程序至少有一个进程,一个进程至少有一个线程.

2) 线程的划分尺度小于进程,使得多线程程序的并发性高。

3) 另外,进程在执行过程中拥有独立的内存单元,而多个线程共享内存,从而极大地提高了程序的运行效率。

4) 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行,必须依存在应用程序中,由应用程序提供多个线程执行控制。

5) 从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。

 这就是进程和线程的重要区别。

4.优缺点
 
线程和进程在使用上各有优缺点:线程执行开销小,但不利于资源的管理和保护;而进程正相反。同时,线程适合于在SMP机器上运行,而进程则可以跨机器迁移。

5.举例记忆
 
计算机的核心是CPU,它承担了所有的计算任务。它就像一座工厂,时刻在运行。假定工厂的电力有限,一次只能供给一个车间使用。也就是说,一个车间开工的时候,其他车间都必须停工。背后的含义就是,单个CPU一次只能运行一个任务。进程就好比工厂的车间,它代表CPU所能处理的单个任务。任一时刻,CPU总是运行一个进程,其他进程处于非运行状态。一个车间里,可以有很多工人。他们协同完成一个任务。线程就好比车间里的工人。一个进程可以包括多个线程。车间的空间是工人们共享的,比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的,每个线程都可以使用这些共享内存。可是,每间房间的大小不同,有些房间最多只能容纳一个人,比如厕所。里面有人的时候,其他人就不能进去了。这代表一个线程使用某些共享内存时,其他线程必须等它结束,才能使用这一块内存。一个防止他人进入的简单方法,就是门口加一把锁。先到的人锁上门,后到的人看到上锁,就在门口排队,等锁打开再进去。这就叫"互斥锁"(Mutual exclusion,缩写 Mutex),防止多个线程同时读写某一块内存区域。还有些房间,可以同时容纳n个人,比如厨房。也就是说,如果人数大于n,多出来的人只能在外面等着。这好比某些内存区域,只能供给固定数目的线程使用。这时的解决方法,就是在门口挂n把钥匙。进去的人就取一把钥匙,出来时再把钥匙挂回原处。后到的人发现钥匙架空了,就知道必须在门口排队等着了。这种做法叫做"信号量"(Semaphore),用来保证多个线程不会互相冲突。

不难看出,mutex是semaphore的一种特殊情况(n=1时)。也就是说,完全可以用后者替代前者。但是,因为mutex较为简单,且效率高,所以在必须保证资源独占的情况下,还是采用这种设计。
 
操作系统的设计,因此可以归结为三点:

(1)以多进程形式,允许多个任务同时运行;

(2)以多线程形式,允许单个任务分成不同的部分运行;

(3)提供协调机制,一方面防止进程之间和线程之间产生冲突,另一方面允许进程之间和线程之间共享资源。 查看全部
1.定义

进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.

线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源.

2.关系
 
一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.

相对进程而言,线程是一个更加接近于执行体的概念,它可以与同进程中的其他线程共享数据,但拥有自己的栈空间,拥有独立的执行序列。

3.区别
 
进程和线程的主要差别在于它们是不同的操作系统资源管理方式。进程有独立的地址空间,一个进程崩溃后,在保护模式下不会对其它进程产生影响,而线程只是一个进程中的不同执行路径。线程有自己的堆栈和局部变量,但线程之间没有单独的地址空间,一个线程死掉就等于整个进程死掉,所以多进程的程序要比多线程的程序健壮,但在进程切换时,耗费资源较大,效率要差一些。但对于一些要求同时进行并且又要共享某些变量的并发操作,只能用线程,不能用进程。


1) 简而言之,一个程序至少有一个进程,一个进程至少有一个线程.

2) 线程的划分尺度小于进程,使得多线程程序的并发性高。

3) 另外,进程在执行过程中拥有独立的内存单元,而多个线程共享内存,从而极大地提高了程序的运行效率。

4) 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行,必须依存在应用程序中,由应用程序提供多个线程执行控制。

5) 从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。


 这就是进程和线程的重要区别。

4.优缺点
 
线程和进程在使用上各有优缺点:线程执行开销小,但不利于资源的管理和保护;而进程正相反。同时,线程适合于在SMP机器上运行,而进程则可以跨机器迁移。

5.举例记忆
 

计算机的核心是CPU,它承担了所有的计算任务。它就像一座工厂,时刻在运行。假定工厂的电力有限,一次只能供给一个车间使用。也就是说,一个车间开工的时候,其他车间都必须停工。背后的含义就是,单个CPU一次只能运行一个任务。进程就好比工厂的车间,它代表CPU所能处理的单个任务。任一时刻,CPU总是运行一个进程,其他进程处于非运行状态。一个车间里,可以有很多工人。他们协同完成一个任务。线程就好比车间里的工人。一个进程可以包括多个线程。车间的空间是工人们共享的,比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的,每个线程都可以使用这些共享内存。可是,每间房间的大小不同,有些房间最多只能容纳一个人,比如厕所。里面有人的时候,其他人就不能进去了。这代表一个线程使用某些共享内存时,其他线程必须等它结束,才能使用这一块内存。一个防止他人进入的简单方法,就是门口加一把锁。先到的人锁上门,后到的人看到上锁,就在门口排队,等锁打开再进去。这就叫"互斥锁"(Mutual exclusion,缩写 Mutex),防止多个线程同时读写某一块内存区域。还有些房间,可以同时容纳n个人,比如厨房。也就是说,如果人数大于n,多出来的人只能在外面等着。这好比某些内存区域,只能供给固定数目的线程使用。这时的解决方法,就是在门口挂n把钥匙。进去的人就取一把钥匙,出来时再把钥匙挂回原处。后到的人发现钥匙架空了,就知道必须在门口排队等着了。这种做法叫做"信号量"(Semaphore),用来保证多个线程不会互相冲突。

不难看出,mutex是semaphore的一种特殊情况(n=1时)。也就是说,完全可以用后者替代前者。但是,因为mutex较为简单,且效率高,所以在必须保证资源独占的情况下,还是采用这种设计。
 
操作系统的设计,因此可以归结为三点:


(1)以多进程形式,允许多个任务同时运行;

(2)以多线程形式,允许单个任务分成不同的部分运行;

(3)提供协调机制,一方面防止进程之间和线程之间产生冲突,另一方面允许进程之间和线程之间共享资源。