nginx的upstream目前支持5种方式的分配
nginx的upstream目前支持5种方式的分配 1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 2、weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 例如： upstream bakend { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; } 3、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 例如： upstream bakend { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; } 4、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。 upstream backend { server server1; server server2; fair; } 5、url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。 例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法 upstream backend { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; } tips: […]
巧用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。
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 […]
四大并行文件系统对比（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 + nginx
download the upstream jvm route from http://code.google.com/p/nginx-upstream-jvm-route/ [root@web1 nginx-1.2.0]# tar -zxf nginx-upstream-jvm-route-0.1.tar.gz [root@web1 nginx-1.2.0]# patch -p0 ./nginx_upstream_jvm_route/jvm_route.patch [root@web1 nginx-1.2.0]# ./configure –sbin-path=/usr/sbin/ –conf-path=/etc/nginx/nginx.conf –with-http_stub_status_module –with-http_ssl_module –add-module=./nginx_upstream_jvm_route edit /etc/nginx/nginx.conf add upstream resin_proxy { server 127.0.0.1:85 srun_id=app-by1 max_fails=2 fail_timeout=10s weight=200; //负载均衡 server web3:85 srun_id=app-by2 max_fails=2 fail_timeout=10s weight=200; //负载均衡 jvm_route $cookie_JSESSIONID|sessionid; } server { listen 80; server_name […]
resin-pro-4.0.23 crack 破解文件下载
resin-pro-4.0.23 破解文件下载pro.jar resin pro 4.0.23 Full Cracked download. 下载pro.jar文件，覆盖原来lib目录的pro.jar文件即可。 仅供学习使用，请在下载后24时间内删除。
resin 3.1.12破解版
resin 3.1.12破解文件license.jar 下载license.jar文件，覆盖原来lib目录的license.jar文件即可。 resin pro 3.1.12 Full Cracked download. 仅供学习使用，请在下载后24时间内删除。
Asterisk
Asterisk是一款实现电话用户交换机（PBX）功能的自由软件、开源软件。Asterisk提供完善PBX功能，可以连接多种不同的电话终端，包括普通电话机，IP电话机，软电话等，支持多种主流的IP电话协议和系统接口。软件名称Asterisk－星号（*），在Unix（包括Linux）和DOS操作系统中是通配符，用来在查找中适配任何字符，寓意该软件广泛的适用性。 Asterisk软件提供很多以前只有昂贵的专业PBX系统才支持的功能，比如：语音信箱，会议电话，交互式语音应答和自动电话转接等。由于该软件开放的性质，用户可以灵活的配置方便的扩展系统的功能，甚至编程开发自己所需功能的模块。Asterisk通常都运行在Linux操作系统下，当然它也可以在其他系统，如BSD，Windows或OS X下编译并安装。 Asterisk服务器不需要任何特殊的硬件即可提供VoIP的服务，只需服务器有网络连接即可。它支持主流VoIP协议，包括会话发起协议（SIP）、H.323，既可作为IP电话服务器也可以作IP电话和PSTN之间的转接。Asterisk系统还设计了一个新协议，IAX，用于在Asterisk服务器之间维护话路通道。如果需要连接普通电话或PSTN中继线，运行Asterisk的服务器则需要安装相应的硬件接口板。许多厂商都生产用于连接普通电话、T1、E1中继线、ISDN等的接口板。 由于是自由软件且具有丰富的系统功能，Asterisk提供给用户一个廉价并功能强大的PBX解决方案。它被越来越多的用于代替传统专用的PBX，或被用于跨国VoIP电话以节省长途费用。一些国家的VoIP电话公司已经开始支持Asterisk，提供IAX2接口或允许用户的Asterisk服务器使用SIP协议连接。 截止2010年10月28日，Asterisk的最新版本是1.8.0版。 由于Asterisk过于专业，所以目前也存在大量的基于Asterisk开发的容易使用的通信系统，比如在欧美比较流行的elastix、trixbox、或以中文为基础的Freeiris等。 Asterisk主页 Asterisk的主要赞助商和开发支持 Asterisk新闻 Asterisk支持文件计划 Asterisk教学 视频TrixBox/FreePBX教学 Asterisk网页界面管理 O’Reilly Media’s — Asterisk：电话的未来 Asterisk – 初学者的第一步 Asterisk Wiki Asterisk VoIP新闻 Asterisk的正式论坛 Asterisk Army Digium Cards Asterisk中文论坛（简体中文） Asterisk 中文天地
varnish,squid,apache,nginx缓存文件比较
一，测试环境 1，硬件是奔腾双核，机子三年前买的。系统是archlinux 2，测试varnish和squid的时候，web服务用的apache 3，测试apache的时候，启动了5个进程，不过随着压力的增加，进程会增加的。 4，测试nginx的时候，启动了十个nginx进程，20个php-cgi进程 5，varnish，squid，nginx用的是反向代理的形势，也就是说访问图片的时候，要先透过缓存工具 二，测试 1，varnish [root@BlackGhost bin]# /usr/local/bin/webbench -c 100 -t 20 http://127.0.0.1:8080/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif Webbench – Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://127.0.0.1:8080/00/01/RwGowEtWvcQAAAAAAAAWHH0Rklg81.gif 100 clients, running 20 sec. Speed=476508 pages/min, 47258114 bytes/sec. Requests: 158836 susceed, 0 failed. 访问了这么次，没有缓存只有一次，效率真的很高。 2，squid [root@BlackGhost bin]# /usr/local/bin/webbench -c […]
初步试用Squid的替代产品──Varnish Cache网站加速器
Varnish是一款高性能的开源HTTP加速器，挪威最大的在线报纸 Verdens Gang (vg.no) 使用3台Varnish代替了原来的12台squid，性能比以前更好。 Varnish的作者Poul-Henning Kamp是FreeBSD的内核开发者之一，他认为现在的计算机比起1975年已经复杂许多。在1975年时，储存媒介只有两种：内存与硬盘。但现在计算机系统的内存除了主存外，还包括了cpu内的L1、L2，甚至有L3快取。硬盘上也有自己的快取装置，因此squid cache自行处理物件替换的架构不可能得知这些情况而做到最佳化，但操作系统可以得知这些情况，所以这部份的工作应该交给操作系统处理，这就是Varnish cache设计架构。 Varnish可以在FreeBSD 6.0和Linux 2.6内核上运行。 1、编译安装varnish HTTP加速器： 引用 wget http://blog.s135.com/soft/linux/varnish/varnish-1.1.1.tar.gz tar zxvf varnish-1.1.1.tar.gz cd varnish-1.1.1 ./configure –prefix=/usr/local/varnish make && make install 2、简单启动varnish守护进程，用本机80端口去反向代理加速127.0.0.1:81上的Apache服务器： 引用 /usr/local/varnish/sbin/varnishd -a :8080 -b 127.0.0.1:81 -p thread_pool_max=1500 -p thread_pools=5 -p listen_depth=512 -p client_http11=on -w 1,10000,120 Varnish官方网站：http://www.varnish-cache.org/ 另有一份PDF文档，说明Varnish原理的：http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=2163384 我测试了一下，在同等配置环境下，Varnish的性能确实要超过Squid，稳定性也不错，值得继续去深入研究。 原文地址:http://blog.s135.com/post/290/