Archives

巧用zookeeper实现分布式并行计算

云计算的技术话题中少不了“分布式”，“并行计算” 这些个关键词，我们知道硬件扩展的条件(Scale-up)始终是有限制的，将计算分散到网络中更多机器的CPU上提供更高的计算性能(Scale-out)，并在这基础上能将计算同时进行，那么总体计算瓶颈会减小，计算的性能会显著提高，也就是说将串行计算变为并行计算，将大量的计算在同一时间发生，，将任务分配到每一个处理器上。这里面需要一个重要的角色，分布式计算资源中的协调者。 有这样一个场景：系统中有大约100w的用户，每个用户平均有3个邮箱账号，每隔5分钟，每个邮箱账需要收取100封邮件，最多3亿份邮件需要下载到服务器中(不含附件和正文)。用20台机器划分计算的压力，从多个不同的网路出口进行访问外网，计算的压力得到缓解，那么每台机器的计算压力也不会很大了。 通过我们的讨论和以往的经验判断在这场景中可以实现并行计算，但我们还期望能对并行计算的节点进行动态的添加/删除，做到在线更新并行计算的数目并且不会影响计算单元中的其他计算节点，但是有4个问题需要解决，否则会出现一些严重的问题： 1.20台机器同时工作时，有一台机器down掉了，其他机器怎么进行接管计算任务，否则有些用户的业务不会被处理，造成用户服务终断。 2.随着用户数量增加，添加机器是可以解决计算的瓶颈，但需要重启所有计算节点，如果需要，那么将会造成整个系统的不可用。 3.用户数量增加或者减少，计算节点中的机器会出现有的机器资源使用率繁忙，有的却空闲，因为计算节点不知道彼此的运行负载状态。 4.怎么去通知每个节点彼此的负载状态，怎么保证通知每个计算节点方式的可靠性和实时性。 先不说那么多专业名词，白话来说我们需要的是：1记录状态，2事件通知 ，3可靠稳定的中央调度器，4易上手、管理简单。 采用Zookeeper完全可以解决我们的问题，分布式计算中的协调员，观察者，分布式锁  都可以作为zookeeper的关键词，在系统中利用Zookeeper来处理事件通知,队列,优先队列,锁,共享锁等功能，利用这些特色在分布式计算中发挥重要的作用。 zookeeper的服务器端是采用Java编写，而zookeeper的客户端不仅可以支持java还可以支持C语言的客户端，在zookeeper服务端可以创建一个树状的Key/Vaule 存在着父子节点之间的关系。 Zookeeper允许多个Client对一个或多个ZNode数据进行监控，当ZNode有变化时能够通知到监控这个ZNode的各个Client，所有监听这个节点的成员都会知道了，Zookeeper使用Watcher察觉事件信息,当客户端接收到事件信息,比如连接超时,节点数据改变,子节点改变,可以调用相应的行为来处理业务逻辑。相反，如果zookeeper客户端对服务端的znode不关注，不Watcher，那么发生任何变化zookeeper的客户端都不会收到事件通知。 zookeeper中znode的数据模型 每次zookeeper客户端与服务器端连接后都会创建一个session ID 给客户端，客户端将会定期心跳协议到服务器端验证这个连接的有效性。如果由于某种原因，客户端无法发送心跳到服务器，将导致服务器验证过期的会话，会话ID将变为无效。客户持有的连接/对象将不可用，因此应用程序必须创建一个新的客户对象。如果zookeeper客户端连接到服务器没有任何响应，首先客户端会作抛出的异常并且被捕获，清除当前与Server相关的网络资源和连接会话，然后客户端逐个尝试配置列表中Server的连接地址，选择可用的服务器继续进行工作。 上述Zookeeper客户端和服务器端的关系又是一个典型的“观察者”模式，客户端关注自己关心的对象(znode)，一旦发送变化就立刻通知。在《Head First设计模式》中有这样的一张图来表达 观察者模式的。 如图所示，此系统中的三个部分是气象站(获取实际气象数据的物理装置)、WeatherData对象(追踪来自气象站的数据，并更新布告板)和布告板,再来看看百度百科对“观察者”模式的解释：http://baike.baidu.com/view/1854779.htm 通过对Zookeeper的了解，实现我们系统中需要的Failure detection和Load detection 功能，只需要在每个计算的节点中实现zookeeper客户端程序，计算节点关注zookeeper服务器上znode节点变化。可以在zookeeper服务器的znode上创建一个根节点/clusterA,下面根据计算节点机器名创建对应的子节点，子节点中的value就是这台计算节点的ip地址。 如：/clusterA/node1,/clusterA/node2,/clusterA/nodeN,这些节点都是临时节点(EPHEMERAL)，一旦连接断开，创建的节点自动会被删除，关注/clusterA这个根节点/clusterA的机器都会知道现在哪台机器离开计算单元了，并且获知现在有多少个计算节点在这个计算单元中。 如果有新的计算节点添加，在程序运行的第一步将会到zookeeper服务器上的/clusterA 的znode上创建一个子节点/clusterA/nodeZ，这样关注 /clusterA这个znode的机器都会知道现在多了一个计算节点。 通过zookeeper客户端API中的getChildren()方法对应的数据类型是java.util.List,其返回/clusterA下面的机器列表，这样还能判断出自己在这个列表中排行位置，通过列表中排行位置可以对应用户列表中的数目，这样就知道自己去获得需要计算总数中的几分之分。 例如：有100w用户，20个节点时，每个节点处理5w用户进行同时计算，node3计算节点承载用户总数中10w-15w用户之间的计算压力，有200w用户，20个节点时，每个节点处理10w个用户的业务进行同时计算，node3计算节点承载用户总数中30w-40w用户的计算压力，以此类推。 这样一来无论计算节点的数目发生变化还是，需要计算的数目发生变化，都可以保证计算压力的平均分载。 我的废话： 1.根据节点数对应用户数算出百分比之后进行计算分载，貌似我们通常的分页查询，只不过将每页的分页结果同时显示在N多个显示器上输出，希望这样比喻能让您更好的理解。 2.在计算的中间有新的用户数量增加，将会通知每个计算节点 下次轮询时需要重新统计用户数量，因为用户所有用户的数据分块拿走以后放入本地的静态hashmap(缓存)，没有发生变化就从本地加载，操作数据库发生变化后，通知zookeeper的znode节点 每个计算节点重新从数据库中加载一次。 3.在并行计算中时间同步也是一个需要注意的地方，如果每台机器上的时间不一致会导致潜在的隐患，可以找些工具通过时间服务器同步每台机器上的当前时间和时区。 4.使用zookeeper对计算节点的状态管理只是zookeeper实现的一部分，zookeeper还可以对外提供分组，配置管理，命名空间等服务等，这里只是做了一个抛砖引玉的作用。 对于zookeeper的可靠性和性能而言，有足够的机器那么稳定性就会越高，但是性能会降低，因为ZooKeeper在运行时全部的数据都会加载到内存中，集群中每一台服务器都包含全量的数据，每个节点实时保持数据的同步。因此整个集群中Follower数量越多，整个集群写入的性能越差。后来zookeeper Server为了避免这个问题，可以将ZooKeeper集群中部分服务器指定为Observer。

异常/bin/sh^M: bad interpreter: No such file or directory。

在Linux中执行.sh脚本，异常/bin/sh^M: bad interpreter: No such file or directory。 分析：这是不同系统编码格式引起的：在windows系统中编辑的.sh文件可能有不可见字符，所以在Linux系统下执行会报以上异常信息。 解决：1）在windows下转换： 利用一些编辑器如UltraEdit或EditPlus等工具先将脚本编码转换，再放到Linux中执行。转换方式如下（UltraEdit）：File–>Conversions–>DOS->UNIX即可。 2）也可在Linux中转换： 首先要确保文件有可执行权限 #sh>chmod a+x filename 然后修改文件格式 #sh>vi filename 利用如下命令查看文件格式 :set ff 或 :set fileformat 可以看到如下信息 fileformat=dos 或 fileformat=unix 利用如下命令修改文件格式 :set ff=unix 或 :set fileformat=unix :wq (存盘退出) 最后再执行文件 #sh>./filename

resin-pro-4.0.30 crack 破解文件下载

resin-pro-4.0.30 破解文件下载pro.jar resin pro 4.0.30 Full Cracked download. 下载pro.jar文件，覆盖原来lib目录的pro.jar文件即可。 仅供学习使用，请在下载后24时间内删除。

linux chmod

使用权限 : 所有使用者 使用方式 : chmod [-cfvR] [–help] [–version] mode file… 说明 : Linux/Unix 的档案存取权限分为三级 : 档案拥有者、群组、其他。利用 chmod 可以藉以控制档案如何被他人所存取。 把计 : mode : 权限设定字串，格式如下 : [ugoa…][[+-=][rwxX]…][,…]，其中u 表示该档案的拥有者，g 表示与该档案的拥有者属于同一个群体(group)者，o 表示其他以外的人，a 表示这三者皆是。 + 表示增加权限、- 表示取消权限、= 表示唯一设定权限。 r 表示可读取，w 表示可写入，x 表示可执行，X 表示只有当该档案是个子目录或者该档案已经被设定过为可执行。 -c : 若该档案权限确实已经更改，才显示其更改动作 -f : 若该档案权限无法被更改也不要显示错误讯息 -v : 显示权限变更的详细资料 -R : 对目前目录下的所有档案与子目录进行相同的权限变更(即以递回的方式逐个变更) –help : 显示辅助说明 –version […]

MOVE 开发模式

MVC模式在编程中的应用，是一个很了不起的主意。“数据模型（Model）”可以封装与应用程序的业务逻辑相关的数据及对数据的处理方法；“视图层（View）”能够实现数据有目的的显示；“控制器（Controller）”能够在不同层面间起到组织作用，对应用程序的流程进行控制。 不过，可能你在使用这种三层架构模式的过程中会逐渐迷惑。因为有很多代码你不知道把它放哪，就只好把它放到控制层，最后发现在控制层中塞了太多的代码。 LinkedIn的软件工程师Conrad Irwin也遇到同样的问题，于是他开始使用另一种模式：MOVE，即Models（模型）、Operations（操作）、Views（视图）、Events（事件）。 近日Conrad Irwin在个人博客上分享了关于这种模式的一些观点。 概述 Irwin结合上图对MOVE模式先作了简单定义： Models，封装该应用程序中知道的一切； Operations，封装该应用程序要做的一切； Views，帮助用户与应用程序完成交互； Events，用于安全地连接所有这些组件。 为了避免意大利面条式的代码，图中标示出了对哪种类型的对象进行操作是允许的。例如，视图允许监听由模型产生的事件；操作允许修改模型，但模型不应涉及视图或操作。 Models（模型） 这里以一个“User”对象为原型，它至少应用有一个Email地址，也可能有用户名和电话号码。 在一个MOVE模式的Models中只包装知识。这意味着除了Get和Set功能，它们可以包含检查用户密码是否正确这样的方法，但不会包含把密码保存到数据库或传递给外部API这样的功能，因为后面这些工作将由Operations来完成。 Operations（操作） 对应用程序来说，一个常见的操作是用户登陆。这实际上是由两个子操作组成：首先从用户那里获得邮件地址和密码，然后从数据库载入“user”模型并检查密码是否匹配。 Operations是MOVE模式中的行动者。它负责修改模型，在正确的时间显示正确的视图，以及响应由用户交互引发的事件。在一个分解良好的应用程序中，每个子操作都可以独立运行。 采用这种方式的操作有一点很令人振奋，即程序启动后，整个应用本身就可以被当作一个Operations。它会根据需要生成尽可能多的子操作，其中每个子操作都并行地运行。当所有子操作都完成时，程序也便退出。 Views（视图） 登陆页面即是一个视图，它负责显示一些文本框给用户。当用户点击“登陆”按钮时，视图将产生一个“loginAttempt”事件，其中包含用户输入的用户名和密码。 用户能够看到的内容，以及能感受到的互动都由视图提供支持。它们会以一种用户能理解的形式呈现应用反馈，同时还能将简单的用户交互转换成有意义的事件。更重要的是视图不会直接改变模型，它们只是向Operations发起事件，然后通过监听等待由模型发起的事件。 Events（事件） 当用户登陆时，视图会发起“loginAttempt”事件。在登陆操作完成后，“currentUser”模型会发起一个事件通知应用登陆状态已改变。 事件监听让MOVE（及MVC）实现控制反转，允许模型更新视图。这是一种强大的抽象技巧，允许组件互不干扰地耦合在一起。 为什么是现在？ 当然，Conrad Irwin并不想被人认为自己是在暗示MVC模式很差，这种大型应用程序架构在过去的几十年里确实非常成功。不过几十年后的今天，新的编程技术已经变得越来越流行，所以你也会在使用过程中逐渐产生一些疑惑。 MVC模式确实很了不起，但它毕竟是几十年前为老的技术而设计。MOVE模式是在其基础上的升级，让你可以更好地利用当前已有的新工具。

monitoring your javaEE application : javamelody

The goal of JavaMelody is to monitor Java or Java EE application servers in QA and production environments. It is not a tool to simulate requests from users, it is a tool to measure and calculate statistics on real operation of an application depending on the usage of the application by users. JavaMelody is opensource […]

Comparing HTML5 Mobile Web Framework

It’s been an exciting year for the mobile Web. Adoption of HTML5 and CSS3, improved performance in mobile browsers, and an explosion of mobile app frameworks mean it’s more feasible than ever to create rich, interactive Web experiences for mobile devices. Using a wrapper like PhoneGap, you can distribute them via the native app stores […]

四大并行文件系统对比（HDFS,KFS,CEPH,PANASAS)

什么是Hadoop？ Hadoop是apache下面的一个分布式并行计算框架，是从lunece中抽取出来的一个框架。Hadoop的核心设计思想是：MapReduce和HDFS，MapReduce是Google提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。概念”Map（映射）”和”Reduce（化简）”，和他们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性；HDFS是Hadoop Distributed File System的缩写，即：Hadoop分布式文件系统，为分布式计算存储提供底层支持。注：MapReduce (google mapreduce 论文点击这里)，GFS（Google File System）和bigtable是google的三大核心技术。 HadoopMapReduce介绍 Map(映射)和reduce(化简)是分开处理的，map是将一个任务分解为多个任务执行，reduce是将多个任务汇总起来得到想要的结果。把一个list拆解为多个放到线程池中启动多个线程计算list中值，然后把多个任务返回的结果合并为一个总的结果其实就是一个简单的MapReduce的应用。 在Hadoop官方文档（单击这里）介绍了HadoopMapReduce的三个步骤，map（主要是分解并行的任务），combine（主要是为了提高reduce的效率），reduce（把处理后的结果再汇总起来）     1、HDFS 即Hadoop Distributed File System (Hadoop分布式文件系统) HDFS 具有高容错性，并且可以被部署在低价的硬件设备之上。HDFS很适合那些有大数据集的应用，并且提供了对数据读写的高吞吐率。HDFS是一个 master/slave的结构，就通常的部署来说，在master上只运行一个Namenode，而在每一个slave上运行一个Datanode。 HDFS 支持传统的层次文件组织结构，同现有的一些文件系统在操作上很类似，比如你可以创建和删除一个文件，把一个文件从一个目录移到另一个目录，重命名等等操作。Namenode管理着整个分布式文件系统，对文件系统的操作（如建立、删除文件和文件夹）都是通过Namenode来控制。 下面是HDFS的结构： 从上面的图中可以看 出，Namenode，Datanode，Client之间的通信都是建立在TCP/IP的基础之上的。当Client要执行一个写入的操作的时候，命令 不是马上就发送到Namenode，Client首先在本机上临时文件夹中缓存这些数据，当临时文件夹中的数据块达到了设定的Block的值（默认是 64M）时，Client便会通知Namenode，Namenode便响应Client的RPC请求，将文件名插入文件系统层次中并且在 Datanode中找到一块存放该数据的block，同时将该Datanode及对应的数据块信息告诉Client，Client便这些本地临时文件夹中 的数据块写入指定的数据节点。 HDFS采取了副本策略，其目的是为了提高系统的可靠性，可用性。HDFS的副本放置策略是三个副本， 一个放在本节点上，一个放在同一机架中的另一个节点上，还有一个副本放在另一个不同的机架中的一个节点上。当前版本的hadoop0.12.0中还没有实 现，但是正在进行中，相信不久就可以出来了。 KFS（KOSMOS DISTRIBUTED FILE SYSTEM），一个类似GFS、Hadoop中HDFS 的一个开源的分布式文件系统。   PS: google的三大基石 gfs,bigtable,map-reduce 相对应的开源产品 gfs:kfs(据传google创史人的同窗所创)，hdfs(hadoop的子项目) bigtable:hbase(hadoop的子项目)，Hypertable（从hbase项目组分离出去的，用c++实现） map-reduce:hadoop（apache的项目，java实现，目前创史人在yahoo全力打造，已有2000个以上的节点并行计算的规模）     Google两个共同创始人的两个大学同窗（印度人）Anand Rajaraman和Venky Harinarayan，创立的一个新的搜索引擎Kosmix最近捐献了一个克隆GFS的文件系统KFS项目。Hadoop和Hypertable这两个项目也开始支持KFS来做底层的存储。KFS是用C++写的，但是其client支持C++，Java和Python。那么KFS到底有什么特性呢？   支持存储扩充（添加新的chunckserver,系统自动感知） 有效性（复制机制保证文件有效性） 负载平衡（系统周期地检查chunkservers的磁盘利用，并重新平衡chunkservers的磁盘利用，HDFS现在还没有支持） 数据完整性（当要读取数据时检查数据的完整性，如果检验出错使用另外的备份覆盖当前的数据） 支持FUSE（HDFS也有工具支持FUSE） 使用契约（保证Client缓存的数据和文件系统中的文件保持一致性） HDFS未支持的高级特性：   支持同一文件多次写入和Append，不像HDFS支持一次写入多次读取和不支持Append（最近要增加Append，但是遇到许多问题）。 文件及时有效，当应用程序创建一个文件时,文件名在系统马上有效。不像HDFS文件只当输入流关闭时才在系统中有效，因此，如果应用程序在关闭前出现异常导致没有关闭输入流，数据将会丢失。

resin-pro-4.0.27 crack 破解文件下载

resin-pro-4.0.27 破解文件下载pro.jar resin pro 4.0.27 Full Cracked download. 下载pro.jar文件，覆盖原来lib目录的pro.jar文件即可。 仅供学习使用，请在下载后24时间内删除。