整体同步并行计算模型(Bulk Synchronous Parallel Computing Model,简称BSP模型),又名大同步模型或BSP模型,由哈佛大学Viliant和牛津大学Bill McColl提出。google Pregel、apapche hama、spark 都基于这个思想.
--2014-08-18 上午
对于阿里的消息中间件系统,大家所广泛了解的是 @ 子柳 在《淘宝技术这十年》中介绍的 Notify ,但是从最近的阿里的开源计划中,我们经常看到 MetaQ / RocketMQ ,在阿里内部 Notify 和 MetaQ 是怎样的关系?我看到早期的 MetaQ 是采用的 Kafaka 的设计思路,那么可能大家就比较好奇 “ 问什么要重复造轮子 ” ,能不能介绍这个方面的考虑以及所做的工作?
沈询: 要讲明白这个问题,就需要从产品的实际需求角度入手开始做个介绍了。Notify作为一个已经存在了5年多的消息产品,被广泛的应用在整个阿里巴巴集团的大部分消息通信领域。它的核心特性是: 提供事务支持、不保证消息顺序、消息可能会重复、推模型。
因为淘宝是个交易类网站,所以事务支持的特性能够非常方便的让用户可以快速的依托于Notify完成他们自己的业务逻辑。
然而,一个产品不可能满足所有的场景,在当时我们就经常收到一些需要保证消息有序的发送和接收的需求,而这样的场景对于上来就定位于无序消息投递的 Notify 来说无异于釜底抽薪。
而正在我们讨论这类需求应该如何被满足的时候,正好赶上 LinkedIn 的 KafKa 队列开源,简单的文件队列,拉模型,保证顺序的特性一下就吸引了我们的目光,在对他的做了整体架构上的Review以后,我们认为这是个非常优雅的模型,因为他足够简单,简单就是最好的~!
然而里面也有一些特性不是我们所需要的,比如我们主要是面向内部用户,因此定期轮询去拉的方式就不适合我们的实际场景需求,并且因为 KafKa 的开发语言是 Scala ,不大利于我们的后续的维护,因此我们借鉴了 Kafka 的核心思路,对其进行了重写并开源,当然我们还是向 LinkedIn 的 KafKa 做了致敬的, MetaQ 其实是 Metamorphosis 的意思,是Kafka的名作。
从上面的发展历程其实也就能够比较清晰的找到两个消息队列产品的不同定位了:
RocketQ(MetaQ) 主要面向消息有序的场景,能够提供更大的消息堆积能力
Notify,主要面向需要更加安全可靠地交易类场景,无序,推模式。
RocketMQ的前身是Metaq,当 Metaq 3.0发布时,产品名称改为RocketMQ
MetaQ2.x版本由于依赖了alibaba公司内部其他系统,对于公司外部用户使用不够友好,推荐使用3.0版本。
--2014-08-18 下午
官网上https://github.com/LMAX-Exchange/disruptor,这样介绍disruptor :High Performance Inter-Thread Messaging Library。 其实disruptor 的定位是单机多核并发框架。而akka 才能做到多机分布式。 回到activemq 在千万级基本就会出现极限问题,rocketmq貌似是不错的选择。
--2014-08-22 上午
akka 的应用
你的需求是自己寫 server cluster 嗎?
①自己寫 server 和 cluster
②自己寫 server,但是不是 cluster
③不自己寫 server 也自己不寫 cluster。
我想第一種需求少的可憐,但這是唯一比較適合 Akka 的系統,第二種則是少數,而且通常都是寫個 socket server 就好了,也沒多大,這樣的需求只需要 JBoss netty,而不是 Akka。第三種應該是最多的,大家都是拿現成的 apache / tomcat / RDBMS / NoSQL / hadoop / rabbitmq / jabber / solr .... 等等來兜,很少有需求需要自己苦幹實幹打造 cluster,尤其現在幾乎是 web 服務的天下,更是如此。
尽管我在用工具方面已经算是有点经验,但是为了今后能看懂更多的代码,我还是觉得学习akka跟disruptor的编程思想,是值得付出时间精力的。因为我对纯粹的业务逻辑编程已经厌烦了。
Cloudy Akka 如何了?
Akka的商业支持早先被叫作Cloudy Akka. 它包括两部分:
Akka的集群支持
监控和管理(早先称为Atmos)
Cloudy Akka已经停止了。集群支持已经被移进了Akka的开源版本中(即将到来的Akka 2.1),而监控和管理(Atmos)现在被重新命名为Typesafe控制台,是Typesafe Stack(详见下文)商业合约的一部分。
--2014-08-24 上午
Akka 发布了 2.2 版本的首个里程碑,该版本最大的变化就是使用 Spray.io 替代之前版本的 Netty。两者都是基于NIO的,性能应该差不多;关键的区别还是在于编程范式;Spary.io利用Scala的优美的语法和闭包等支持,可以写出更加易读和更少的代码实现更多的功能;
--2014-08-24 下午
一般来说,企业如果规模大点,你基本都需要用到3种存储
对象存储、文件存储、块设备存储
这3种存储,有自己特有的应用场景,无法互相取代。到底是3种存储采用3个软件来实现,还是用一个软件来实现3个功能,这个是一直都有争议的。
3种存储,用3个软件,比较符合linux的哲学.不过企业内部维护3套存储软件,有点痛苦.
CEPH,野心是最大的,同时提供3种存储,比gluster还牛,gluster只提供文件存储和对象存储。
简单点说,就是能提供S3(对象存储),EBS(块设备存储),还能把一个目录mount到本地使用(文件存储)。
Swift并不是文件系统或者实时的数据存储系统,它称为对象存储,用于永久类型的静态数据的长期存储,这些数据可以检索、调整,必要时进行更新,称为amazon s3的开源实现。
至于这三种存储的详细介绍,见http://my.oschina.net/liangshao/blog/310335
--2014-09-05 上午
上面提到了swift(对象存储)、ceph(三种类型存储)、glusterfs(三种类型存储),其实这三者都能与openstack集成。 红帽更是推出openstack发行版RDO。
--2014-09-05 上午
Apache Ambari
Apache Mesos
Platform MapReduce
StackIQ Rocks+ Big Data
Zettaset Orchestrator
五个hadoop 顶级监控工具
--2014-09-10 上午
Ansible基于Python;相比之下,Puppet和Chef基于Ruby。
神器saltstack,是四神器Puppet、Chef、Ansible和Salt中最漂亮的。
--2014-10-18 上午
SSL是Netscape开发的专门用户保护Web通讯的,目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。两者差别极小,可以理解为SSL 3.1,它是写入了RFC的。
--2014-10-19 上午
linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的。而对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD(加州大学伯克利分校的伯克利软件发布中心)在进程间通信方面的侧重点有所不同。前者对Unix早期的进程间通信手段进行了系统的改进和扩充,形成了“system V IPC”,通信进程局限在单个计算机内;后者则跳过了该限制,形成了基于套接口(socket)的进程间通信机制。Linux则把两者继承了下来。
--2014-11-22 晚上
有人对比了下vsphere跟openstack的 区别,其实vsphere 集合了ESXi Server、vCenter Server等组件。
ESXi Server可以在裸机上直接安装,俗称服务虚拟化,英文hypervisor。类似的软件还有下面这三种。
1、Citrix XenServer(可以裸机直接安装)
2、Windows Server 2008 Hyper-V(基于宿主机器win server)
3、VMware ESX Server(Vmware 服务器虚拟化第一个产品叫ESX) | ESXI Server(可以裸机直接安装)
此外,还有较为出名的开源的KVM(基于宿主机器linux server)。
而vcenter是管理多个ESXi Server的软件。
而openstack没有自己的一套类似ESXi的东西,但它支持几乎所有的服务器虚拟化技术,当然包括XenServer Hyper-V ESX Server 或者是KVM。
除此之外,openstack还有一套自己的虚拟管理技术,当然这套管理软件远远比所谓的VCenter Server强大,所以 vmware公司又推了一套竞争方案,名为vCloud。VMware vCloud基础架构是基于VMware vSphere、VMware vCenter、VMware vCloud Director 和VMware vShield构建的,它实现了既在企业内部交付又通过由vCloud驱动的服务提供商交付的企业级云计算。
还有一个 叫做vSphere Hypervisor,他其实就是免费的vsphere,只有esxi功能, 没有vcenter功能。
Hypervisor-based跟Containner-based 结合是未来的趋势。
--2014-12-06 晚上